When I was growing up in the farm, I would help Mom package eggs for her customers in town. Mrs. Woodward liked eggs with pale yellow yolks; so I gathered her eggs from the grain-fed chickens. Mrs. Heiman liked the rich orange yolks of eggs from the chickens that foraged for their own food in the barnyard – grubs, seeds, whatever they would scratch up. I would carefully wash the eggs, put them in baskets, and anticipate the 25-cent reward I would receive for meeting their exact wants.
Perhaps it was these early experiences with customer satisfaction that compelled me to go above and beyond what the contract required in my early years as a systems analyst. I wanted to satisfy my client. Perhaps I was secretly hoping that if I did, my company would reward me.
But what I did not appreciate was that anything I did above and beyond the contracted requirements would endanger my own deadlines (and by extension, the project deadlines), or would require me to work late into the evenings and on weekends to satisfy my own sense of what I believed the customer wanted.
I remember a particularly uncomfortable, but ultimately rewarding, conversation with my Project Manager:
“But, Susan,” I said, “these changes will make it so much easier for the end-user to use that new functionality.”
“Is it in the requirements?” she asked.
“Well, not exactly, but then not everything is in the requirements.”
“Well if it’s not in the requirements, and the customer is not expecting it, and you’re doing it just because you think it will improve the system, that is not a good reason to spend the extra hours and days making the changes. Besides, you’d be putting our deadline at risk.”
With that she began to instruct me on the process of fixed-price bidding, and what it meant to deliver according to the fixed price. It soon all made sense to me, and I took it to heart. Mostly.
“But Susan, hang on. I heard you say that we got a $2 million contract amendment to add the new functionality. There are only 12 of us working on it, so surely there’s lots of money within that $2 million for these improvements that I’d like to make.”
To her credit, she took me through a line of questioning, with extensive patience, that caused me to think it through and gain a better understanding for myself.
She began: “So, just where did you get the impression that there are excess monies to add this new functionality?”
“Well, I have a pretty good idea as to our salaries; and when I add them up over the project timeline to add this new functionality, we don’t come near spending that kind of money.” I responded.
“So, given that were taking on extra risk to add this new functionality, how much profit do you think we deserve for our additional effort and for bearing that additional risk?”
“I don’t know. Maybe 20%? 30%?”
“Fair enough. Now factor this in. Who pays your health insurance? Who contributes to your 401k? Who pays you while you’re on vacation or off sick?”
“Hmm,” I said, “but even at that, it seems that we still have excess profit.”
“Well then, how much was your project leadership training last month?”
“Really?” She went on. “So who paid for your airfare to get there, your hotel room, your restaurant bills, the lost opportunity cost while you were not billing, the support staff that arranged your accommodations? What about your desk, chair, computer, office, heat, lights, janitorial staff…?”
Ding! Ding! Ding! The bells were ringing and the light bulbs were going on all over the place.
She then took out a large folder called “Basis of Estimates”
She painstakingly walked me through the cost estimation process arriving at how the contract amendment had been priced. I saw the detailed list of assumptions that went into the estimates. I reviewed the known constraints (such as the project deadline I was now putting into jeopardy). She explained the contingency reserve. She showed me a small management reserve, reminding me that our client had been less than decisive over the life of the project, and had caused additional time and effort for our team as we strove to meet the deadlines.
And voila, the profit margin was in the 20 to 30% range! I remembered thinking, “$2 million doesn’t go as far as I thought it would!”
That experience was eye-opening for me. I carried it to my own projects as I progressed in my career.
Some of you may be thinking that it is not always appropriate to show staff everything that goes into estimating project costs. You may feel that uninitiated staff does not understand the process used to estimate project costs, and therefore it is not worth the additional time to explain it.
However, there is another side to this. There is an important people aspect of project management that must not be lost here.
When my Project Manager took the time to explain the project budget and how the cost estimates were derived, I reconsidered my supposed altruistic actions to give our client “free” changes. I took her counsel to heart – then, and for future projects. She taught me that the best way to give customer value is to stay within the confines of the contract agreement and meet the customer’s deadlines.
Indeed, had I jeopardized the task deadline with my changes, I might have jeopardized the entire project deadline. That would have put the client at risk with its own project sponsors. My attempt to “improve” the new functionality would not have made a whit of difference if the project deadline was missed.
In many ways, this article on cost estimating is an extension of my previous article, “Why You Should Educate Management on Estimating Activity Durations.” In the prior article I described an approach to estimating activity durations, which provides the basis for estimating project costs. I won’t repeat the premise of that article here; however, the valuable take-away is in the consideration of the people aspects of project management as we estimate costs. This is where building the team and instilling the responsibility for project delivery come into play, especially when dealing with more junior staff who have not yet been trained to think in these ways. If we show them how the project cost estimates are derived, we will build a team committed to staying within those costs.
Just as my Project Manager took the time with me, it is important that we explain to staff that there is a limited budget for the project. Even if considering a time-and-materials perspective rather than the fixed-price world, there is still a limited budget. Someone is watching the numbers. If the team understands the concept of limited budget, it is easier for them to understand that every hour, every action, and every interaction count towards delivering the project.
As one of my managers once told me, “You don’t wake up one day and find that the project is three months behind. The project has been slipping one hour and one day at a time.”
Additionally, an explanation of cost estimation and limited budget can develop strong teamwork among the staff. For example, suppose you have a “superstar” developer who completes her tasks more quickly than the other developers. She can be encouraged to assist her coworkers in completing their tasks so that through such teamwork the whole project benefits. To not do so willingly is akin to sitting in the back of a boat that is taking on water, shouting to the person in the front of the boat that his end of the boat is sinking.
Imagine how your team would approach their work if they understood the assumptions that went into developing the cost estimates, or the project constraints that were likewise considered. Staff can then be challenged to prove the negative assumptions wrong and to improve upon positive assumptions. Similarly, with constraints. A constraint may not even be directly project-related, but one that the client faces with its own constituents. If the team wants to make the client look good, they can assist in overcoming such constraints (within the boundaries of the project).
There are perfectionists on every project (I know; I was one). Similarly, there are staff that are not as concerned about quality. In explaining the cost estimates to your team, the perfectionists need to understand that there is a huge cost to their perfectionism. If their extra effort to add perfection puts the project deadline in jeopardy, what cost is there to perfection? Likewise it is important to help the team understand that there is a cost to quality, but more so to poor quality.
Finally, as staff understand these cost estimation factors, they are more likely to recognize when something is not going according to plan and alert their Project Manager. To do so, they must understand the plan and the components of the cost estimation so that they can make a judgment call to bring the issue to management. After all, they are on the front lines.
Take the time to educate your project staff on cost estimating, assumptions, constraints and their responsibilities to the client. This is a valuable technique to help them help you to deliver projects successfully.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.