Defining the Word “Project”

Sometimes, we need to go back to the very basics. While facilitating a class on project management, I always take the opportunity to spend a few minutes defining some basic concepts, since as Plato said, “All knowledge begins with the definition of terms.” Of course, for a project management course, the first term would be project.

What is a project?

According to the Project Management Institute (PMI) a project is “a temporary endeavor undertaken to create a unique product, service, or result.”

In my experience, further refining two words in this definition provides tremendous insight into the topic of project management. They are: temporary and unique.

To understand a project as temporary is to understand that it must have a clearly defined end. Too many projects are allowed to continue on seemingly ad infinitum. More often, professionals struggle to obtain sign off from a customer to clearly end the project. These two situations are caused by a lack of, or poorly defined, project objectives. One metaphor that has helped me over the years is to think of a project as a temporary company—one that comes into existence for the sole purpose of obtaining the objectives of the project and then goes out of business.

To comprehend a project as unique is to know that while you have participated in many similar projects, each one in truly different. There is no such thing as the “plain vanilla” or standard project, especially in professional knowledge firms. Each project has a different set of goals, objectives, constraints, and of course, personalities. Customers who ask you for the “plain vanilla” project are ignorant of these facts. (Note that the same customer who asks for the “plain vanilla” project will likely state, often times only five minutes later, that their company does this “very differently” from others you many have encountered).

The Difference Between Goals and Objectives

There is clearly a difference, in good project management, between goals and objectives. Goals are what we hope to attain by undertaking the project; however, they are not always attained by project end because there may be other external influences that factor into their achievement or lack thereof. Objectives are, well, objective, in that they can clearly be checked off as having been attained by project end.

For example, “increase sales by 10 percent” would be a goal of the project not an objective. An objective would be the “installation of the new accounting system.” The acid test question to distinguish one versus the other is, “Can this (goal or objective) be clearly accomplished when we consider the project to be completed?”

I am not saying that we should not continue to track project goals, post completion; I am just noting that they need not be accomplished in order for us (and the customer) to consider the project done.

Lastly, if a customer wants you to guarantee the attainment of goals than I would have you consider contingency pricing. For example, if they do increase sales by 10 percent, you should be paid at least 30 percent of that number. In a sense, a customer asking you to guarantee goals, is like that customer asking a lawyer to guarantee winning a case and therefore subject to a contingency arrangement. I would, however, guarantee meeting all objectives.

Now that we have defined some basics of project management, let us put it all together into the Triangle of Truth.

The Triangle of Truth

One of the basic principles of project management is what is known as the triple constraint. Some call this the scope, resource, time triangle. I call it the Triangle of Truth.

The concept is simple. A project consists of three interrelated variables: scope, resource (some say cost), and time. These variables are like the angles of a triangle. If you recall from geometry class in high school, in order for a polygon (shape) to be considered a triangle the three angles must add to 180 degrees—i.e., Angle A (Scope) + Angle B (Resource/cost) + Angle C (Time) = 180. If these do not add to 180 you do not have a triangle. So, if you make a change to the value of one of the angles, one of the other two or both must also change to compensate or else the figure is broken.

The big problem with most professionals is that they are lousy and lazy about scope development. They prefer to concentrate on the second two elements, cost and time. In some cases, the professional feels pressure from the customer or prospect to give answers to the cost and time questions first. To me, this would be the equivalent of purchasing the lumber for a new house before going to an architect for plans; or a doctor writing a prescription before performing a diagnosis. Remember: prescription before diagnosis equals malpractice!

Why do we need a balanced triangle? If we go back to the analogy and take it one step farther, let us draw a circle inside this triangle, the size of the circle represents the quality of the work performed. The largest perfect circle can be drawn inside a triangle that is equilateral—that is, all sides the same—and, therefore all angles equal to 60 degrees.

This is an important point, because for a professional knowledge firm (PKF), quality is defined exclusively by the customer, not the professional. The professional cannot say that they do quality work. Rather, their customers say that about them.

Great Moments in Value Pricing History - Ed Kless

What happens in most firms is that scope is often poorly or not-at-all defined. I am sent an email a week from someone asking me to assist them with scope creep on a project. My first response is to ask them to send me a copy of their scope document. In almost all cases, I am sent back a proposal with a range of hours. In replying to this I tell the poor sap that I have some good news and some bad news. “The good news is you do not have scope creep; the bad news is you are over budget.” What I mean is that since they never defined scope to begin with they are not outside of scope. This leads us to the scope document.

Elements of a Scope Document

I submit the following as the required elements (consultants call them inclusions) of a scope document.

Scope statement
Objectives
Constraints
Project structure
Roles definition
Project team definition
Assumptions
Deliverables
Scope details or functional requirements
Project change control
Future projects list
Approval

Elements of a Change Request

In almost all of the small and medium business information technology projects that I have been associated with there have been usually dozens of change requests. In fact, I cannot think of a single project, however small, that there were none. I believe it would be Twilight Zone weird that any project would have no change requests. Any project worth scoping will be, by definition, one that lends itself to changes. If a customer expects that a project will not have any change requests, he is probably not a good customer to have. No one can predict the future.

Please note that the language that I use for these is change request, not Cchange Oorder. They are, by definition, requests and may be accepted or rejected by the project sponsor (steering committee, on a larger project). A change request is simply an acknowledgment that something that affects the Triangle of Truth needs to be adjusted. In some cases there may not be any budgetary or price change. For example, during an implementation of software the controller may leave the company. The resolution for this may be to push the “go-live” date of the project out, rather than adjust the financial resources. Even if there is no change to the budget, this is still a change request and needs to be approved by the project sponsor. Let us look at the elements of a change request with some commentary.

Project name
Change number
Project manager name
Requestor name—In my view on small projects anyone on the project (customer or consultant) can request a change. In many cases the project manager would assist in the creation of the change request document and would most certainly review it before presenting it to the executive sponsor.
Requested date
Resolution requested by date—“ASAP” is not an allowed date. ASAP means different things to the sender and receiver. To the sender it means now, emphasis on the word soon. To the receiver it means whenever, emphasis on the word possible.
Description of change
Business reason for change—This section must describe the economic benefit that the change will create. In short, if the economic benefit does not exceed the cost section below, it is unlikely the change will be accepted.
Impact on scope—In a sense a change request is a mini scope document. Please remember that when scope changes there must be a change to cost and/or time in the Triangle of Truth.
Impact on price—This would detail the pricing change needed to perform the change.
Impact on time
Impact on quality—Remember if quality is affected, all three of the other elements (scope, cost and time) must also be affected.
Change accepted or rejected
Reason for rejection, if rejected
Signatures and dates
Lastly, change requests should be listed in a separate change request log if the changes are great in number.

Customers do not care about the amount of time spent on their work—or effort. They do, however, care about the duration of that work. Duration is the number of days or weeks that a project will take to complete. It is the window of time in which the result must be achieved.

Effort is the actual amount of work, usually expressed in resource hours. A task can have a duration of 8 hours; however the effort could only be 15 minutes. Alternatively, a task with duration of 8 hours could also have 24 hours of effort. Project management is more concerned about duration than effort.

Turnaround time would emphasize when a project or case will be done, not how many hours will go into its completion. It is similar to FedEx guaranteeing the package will arrive on your doorstep by 8:30 a.m. It is the result that counts. Hence, turnaround time is an example of a Key Predictive Indicator that measures what customers care about.