Issue 3-Underestimating Project Work
This blog is the third in the series “Why Projects Fail” and aptly named “Underestimating Project Work”. Let’s get directly down on managing the risk of underestimating the work.
The consequences of underestimating project work can be evidenced a bit too late in the Planning or Execution phase
At this point there’s not much a project manager can do to save the project, but this blog attempts to provide some work-arounds.
How you, the Project Manager reacts to underestimation can definitely help to ensure project success and minimize customer dissatisfaction. How we present this necessary change in scope goes along way toward goodwill with the customer. What leads to under-estimation? There are a few factors:
1) Sales and the Client
When I began my career as a software engineer for a systems integrator, I was stymied when Account Managers would provide estimates to the client for custom software development when they never wrote a line of code in their life. Often we software engineers would work long hours and weekends to produce the customization on time. We were also PO’d when sales people made statements that the base product has X functionality when, in fact, it did not. We call that vaporware. And, of course it was the development team leader (and sometimes the developers) who had to break the news to the client. Unfortunately the Development Team was never part of the sales or account management process.
As a project manager in the second half of my career, nothing much has changed. Although my situations were usually external client based, the story is same for internally based clients. On most of my projects, the client/executive sponsor already had a timeline in mind regardless of the scope. Of course it’s up to the Project Manager to agree to exactly to what can be done in the given time frame. (See Issue 2 for suggestions for controlling scope). Further, the given estimates are usually based on a one liner scope statement. All I can say at the moment is what a shame when the Project Manager is not involved in determining the initial estimates.
Today as I am running my own business under-estimating how long a project will take you lead one to charge less than you deserve for all the time you put in. This isn’t good for your morale or your bottom line.
The common denominator is that all of these affect the project unfavorably and lengthen the timeline for the project, run over budget and decrease client satisfaction.
I’ve sat in the room with the client at the earliest stages of the project and explained these limitations to the customer. Then I hear “that’s not what Sales/Account Management told us” I scratch my head, but the bottom line is you’ve hit a wall with the client and it’s hard to recover from. They may be frustrated with the Sales or Account Manager initially, but you’re the one who has to fix the situation quickly.
2) Human Nature
Is it a matter of ego? We current or past Software Engineers seem to be hard-wired in our DNA to think that we can accomplish tasks in less time than we actually can.
It’s great to be confident in your abilities, but don’t under-estimate the time you’ll need to do good work on a project. Under-estimating can lead to you not being compensated fairly and your client being annoyed when you miss deadlines.
No rocket science here. Project Managers can counter our natural tendency to under-estimate by keeping a time sheet for each project we’re working on. Keeping track of your time will allow you to see exactly how many hours you’ve put into each project. The final total will probably shock you. If a client asks you to do a similar project in the future, though, you can look back at your notes and figure out how long the project will take based on your past performance rather than on optimistic guesses.
3) Scope Creep
Let’s keep this one simple. You’ve agreed to develop an informational blog/website for your client. The next day, the client emails you and asks if you could edit her biographical statement as well, along with a 100-word sidebar. Your half-hour project is now likely to take at least an hour because its scope had changed.
You can deal with these, “Oh, by the way,” requests by responding proactively. As soon as the clients starts changing the project parameters, estimate the time that the new assignment will take and notify the client that work not described in the original contract will mean additional fees.
4) Technical Difficulties
Technical difficulties encompass everything from new technologies to vendors that won’t call back to fix a known bug.
It’s impossible to plan completely for technical difficulties, so I build them into my estimates. Let’s say I know I can create an information-only website in about three hours. I estimate to allow for Internet down time, emergency phone calls, or other unforeseen complications at no cost to the client.
The Bandaid
Now that you’ve just realized that due to some event or lack thereof early in the project or pre-project process that you have an improperly scoped level of effort. What do you do?
First…be as honest and open with the client on underestimates, regardless of the cause.
Next, meet with the Account Manager to gain a better understanding of how they arrived at the current estimate. Understand what was presented on the customer side in terms of needs. Don’t solely depend on the client side of the story. As my Mom always said “There are always two sides of a story”.
Get yourself geared for damage control. Look for ways in the schedule that you can incorporate activities that were missed while minimizing impacts to the timeline.
If training is needed on the client side, offer a reduced rate to bring proper instructors onsite– this will be cheaper for the client and will take less time than trying to organize customer personnel from multiple locations to fly to your corporate site. I did this with one customer with very satisfying results and it became a new model of training offered to all customers going forward due to it’s success.
Underestimation is Underestimated
Sometimes it seems like we have an underestimation gene embedded really deep in our cognition but for some “obvious” reason (e.g. underestimation!) most manager will rather “fight” overestimation and *not* underestimation.
Disclaimer: I have originally estimated this post will take ~40 minutes but it took me ~120%–additional time. (This is why I prefer to tweet lately)
Tip of the day: Never underestimate intentionally. The penalty for underestimation is greater than severe than the penalty for overestimation. Address concerns about overestimation through control, tracking and *mentoring* but not by bias.
I’m looking forward to your comments!
Thanks for taking the time out of your busy schedule to read this.
Sincerely,
Maria Bodkin
