Trade Ya!

Image via Wikipedia

Last week, I had the pleasure of having lunch with my fourth-grade daughter.  While it was fun spending time with her, it was in many ways a surreal view of a sort of stock exchange floor, where food items were traded and bartered back and forth.  I lost count of how many times I heard the phrase "trade ya" from the children around me.  Trading, it seems, is a skill we learn early in life... and unfortunately forget when we hit adulthood and projects.

I started a new project this week, and it's a new client, so I'm drinking from the proverbial fire hose of information.  I'm learning about their products and services, about their company culture and about my project.  Even though it is the honeymoon phase, I'm still anticipating great things:  from them, from the project and from myself.

As with every single project, I'm having discussions about the triple constraint.  What is that, you ask?  Fair question... as it has been a long time since I covered it here.  The triple constraint is a core concept of project managers.  Some people describe it as good-fast-cheap-choose-two.  I prefer not to use that, as I think it oversimplifies the concept.

Essentially, think of a project in terms of a triangle.  On one side, you have schedule.  This is the number of calendar days (weeks and months) you have to complete the project.  On side number two, we have resources, which is anything that costs you money.  It includes supplies, software, people (and, no, they're not "free" just because they're employees), knowledge, expertise, et cetera.  The final leg of our triangle is performance, which is a interdependent combination of scope (how much are you going to do) and quality (how well are you going to do it).

Because of the relationship of these three triangle sides, you can't change one side without changing at least one other side.  Here's where the tricky part comes in:  Changes will try to occur, but will you as a project manager let them control you, or will you control them?  I liked how this was worded on the Project Daily blog recently:

If the client decides to change or add to the features list, it's up to the PM to make it clear to all the stakeholders that other things may either have to change or suffer. A lot depends on the initial agreement, the change control process, the relationship with the client, and how much wiggle room was included in the original estimates, but in any project based work, a shift in one piece will likely cause a shift throughout. By letting the client know right away that their request might effect the delivery date, the cost, or the quality, you put any trade-off decisions squarely into their hands, with known consequences.

My discussions this week with my project stakeholders have been simple.  Which constraint can move the least?  Which constraint can move the most?  (There is no one right answer to this question, but there is one big wrong answer:  "None of them can move.")  If you can get your decision-makers to agree on this one concept, you will be light years ahead of many other project managers.