I love my clients. In my 40+-year career in project delivery, I can honestly say that I can count the number of clients for which I would never do another project on the fingers of – well, on one finger.
The clients that I enjoyed working with most were the demanding ones, but who were demanding in a fair way. That is, they expected quality delivery of their business requirements in a technically sound manner, while adhering to their budget and timelines. The challenges they most often posed for my team and me were seemingly universal across all projects; it is as if client organizations take a pledge to test their IT providers with behaviors like:
- Adding new scope to the project while we are still putting major time and energy into developing the baseline Project Management Plan. This is always challenging given that current scope and estimates also need to be reviewed in light of the new scope.
- Requiring the IT delivery team to achieve more with respect to their goals, objectives, and long-term benefits, while providing less money and resources than the team feels are required. This is always a major tension between the business organization and IT.
- Demanding that cost estimates be 100 percent “accurate.” For detailed IT people, that’s an oxymoron. It seems that the only time we can guarantee 100 percent “accurate” estimates is at the end of the project.
In the last several articles in this series on the planning process, I have dissected project planning into its component parts. In these articles, I have considered methods that we as Project Managers can use to incorporate what I call the people aspects of project management/project delivery into our planning efforts.
You may recall from my very first article of 52 Project Management Success Tips (“This is Why So Many IT Projects Fail: A “People First” Companion to the PMBOK”), I postulated that we as an industry have such dismal results in project delivery because we are so unskilled in the people aspects of what we do. We are excellent at the technical aspects. We are well-versed in the process aspects. And we spend significant training dollars to maintain our technology and process skills. However, we continue to give the people aspects short shrift, especially in our planning and execution of our IT projects. I further postulated that when we grasp this idea of putting people first, not only will we deliver better results for our clients, but we will also deliver more profit to our bottom line while protecting our clients’ budgets.
I am now at the point in the 52 Project Management Success Tips where I wish to look at common pitfalls in our cost estimating processes, and how we might incorporate our team members and management (people aspects) to assist us in developing better estimates. The most common issues I have observed are the following:
1. We estimate based on poorly derived project requirements. Project requirements include the clients’ business requirements, functional requirements, end-user usability requirements, and others. Unless we have well defined project requirements, gleaned from perspective and knowledge of our clients’ subject matter experts, we will not be able to develop trustworthy cost estimates. Worse yet, as we execute according to those poorly derived estimates, we drift further and further from the baseline estimates as we realize what it will truly require to complete the project. (Refer also to my articles, “This is Why Project Teams Fail at Requirements Gathering,” and “16 People-Focused Techniques for Better Requirements Definition”).
To counteract this, we need to pull out “the big guns” from our people aspects arsenal:
- we must allocate significant time for requirements definition;
- we must train the end-user representatives on the project in how they can best contribute to requirements definition;
- we must train our team members to dig deep in gaining an understanding of those requirements (I often tell stories of how system analysts on our projects would get to the point of knowing the client’s business as well as the end-users on our project); and
- we must document the requirements in great detail, using a structured method that removes the ambiguity that comes with common English narrative.
With well-constructed requirements we are in a stronger position to develop better cost estimates on which our clients can rely.
2. We are too optimistic. Especially during the early honeymoon phases of the project, when there is less pressure and team members and end-users are on their best behavior, we can fall into the trap of thinking that all will go well as we execute the project. This optimism lulls us into underestimating the effort.
How many times have I observed situations such as a key subject matter expert promoted to a job that takes her off the project? Or a team lead recruited to the competition? Or a change in management that now questions the need for the project? Or a major shift in business requirements from those that were initially presented? Process and technology don’t solve these challenges; but awareness of the people-related issues in project delivery helps prepare us for these types of situations.
True, we can’t anticipate every possible contingency; but nevertheless, situations like these happen to projects all the time. The point is that we need to be aware of the curve balls that can come at us, and prepare our cost estimates with enough flexibility and realism to move forward with the project execution.
3. We fail to consider the project risks. This is somewhat tied to the previous point about being too optimistic. Risk planning goes with cost estimation. Every project has risks, and it is our job as Project Managers to identify them early and determine how they might affect the project. Risk management is a prudent aspect of the planning process, yet so many of the risks we encounter are people-related issues. What if the technical architect is not freed up from her current project in time; how can I replace her with someone with equal or greater skills? What if the client’s staff on the project are poor user acceptance testers; how can I guarantee a reliable acceptance test? What if our equipment vendor agent can’t meet its promise of early delivery; how can I mitigate the potential delay?
Such risks must be considered, weighed as to their likelihood of happening, and factored into the cost estimates. Not all will occur. Some will partially occur, with little repercussion. Some will occur. It’s sensible to be realistic about potential risk and not be caught unprepared down the road.
4. We purposely over-estimate. If there is one caution to involving team members in helping to develop cost estimates, it’s this. When I was a developer, I felt that I was continually being pushed to deliver within impossible timelines. So, whenever I was asked for estimates, I would do what any developer tends to do – pad them. Not only did this push the deadlines out, but it seemed that the work would somehow expand to fit the padded estimates anyway.
The answer I found from my own experience, is to involve the team members in the discussions around assumptions, constraints, methods, and processes. As they felt more included in developing the cost estimates, they felt more comfortable in offering realistic solutions to making the estimates more realistic, and then working to those.
5. We acquiesce to pressure from senior management or the client to reduce the estimates. In deriving the cost estimates, we attempt to be as meticulous and realistic as possible, only to be overridden (or at least attempted to be overridden) by our own management or the client. That’s the nature of our lives as Project Managers – no matter how hard we try, it seems that the estimates we produce are always higher than what management or the client were expecting.
From a delivery perspective, submitting to the pressure of lowering cost estimates or rushing the deadline seldom ends well. The answer is to educate management in how the estimates were derived. In doing so, we enlighten them as to the thoroughness of our cost modelling. At the same time, we remain open to their correcting us in areas where we may have made some bad assumptions. Additionally, if the estimates are too high or the deadline too far out, we can work with management to de-scope the less critical requirements and derive a project budget and timelines that meet their expectations.
Cost estimation is both science and art. The science is based on rigorous process, using tools and techniques to help derive good estimates. The art is based on applying the people aspects of project management to the process, involving our team members, management, and the client in anticipating situations along the way. Approaching cost estimation in this way will cause your management, your team members, and your demanding clients to applaud your pragmatic and realistic results.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.