One of the most difficult things to do in the tech world is provide a high level of accuracy in the project estimation process. In this post, I’ll explore 5 areas that are often overlooked. I’ll also introduce a Risk Assessment Tool that I’ve used to help me better manage things.
Estimating is Difficult
Less experienced developers tend to look at the surface of a task and produce low estimates. They tend not to have the knowledge of which questions to ask to get to the details. They could be trying to prove themselves, many times by being the fastest.
More experienced developers have been through the pitfalls for software development. They know that things won’t work as planned. That stakeholders will change their mind. And that they will get something wrong. Project estimation in this case tends to be on the higher side to account for everything they have learned may go wrong.
Let’s face it. Estimating a human endeavor is tough work. And it requires an efficient feedback loop to get better at the process.
I once had a colleague whose responsibility was to provide that feedback. She used to joke that “everyone had a coefficient” (except it wasn’t a joke). To learn someone’s coefficient means estimates tracking estimates and comparing to actuals. It helps everyone learn how to drive their coefficient towards the ideal: a multiplier of 1.
But even people that produce great estimates often get it wrong. And it’s usually due to overlooking risk areas.
Why Project Estimation Often Fails
To approach the ideal estimate, the estimator must examine holistic risk . This includes obvious factors such as project scope, teams size, skills, and complexity. The fact that these are obvious factors doesn’t make them easy to estimate. But they’re usually not completely ignored in the process.
Less obvious factors can turn a project sideways faster than a race car on oil slick. Yet, they are often completely ignored.
The Five Commonly Ignored Risk Areas
- Phase of Work
- Project Management Ownership
- Extent of Business Change Required
- Customer / Team experience level
- Level of Project Sponsor
Phase of Work
This reason this matters is simple. Risk heightens in later project phases because you are closer to go-live. Any change in project scope or delivery quality creates extra work with less time to recover.
That’s not to say an early phase may not have higher risk. It depends on the project. For example, a Design phase with an aggressive schedule may put a design deliverable at risk. It will also introduce higher risk for developing against an incomplete design. It’s important to remember that project estimation for an early phase can have downstream impact.
Project Management Ownership
The relationship of the project manager to the team is critical. If the project manager view the development team as an external resource pool , a level of trust isn’t likely to develop between the two. Project managers must be part of the team. They must be accountable for the team’s delivery.
In the consulting world, this comes down whether the project manager works for the consulting company or the client. This matters due to how it aligns accountability. If the project manager works for the client, knowledge of the business increases along with risk for responsibility shifting. If the project manager works for the consulting company, there is alignment of responsibility and accountability, with less internal business process knowledge. In an ideal world, both roles exists.
Extent of Business Change Required
An eight-week effort to refactor existing code for performance gains usually won’t require the business to change.
A year-long project that completely changes a business process will be frought with challenges. Users will resist the change out of basic human nature. They will need training, in some cases near complete re-education on how the process works. And some will see new systems as a threat to their job and fight the effort tooth-and-nail.
Overlooking this risk area can find the most seasoned project manager focusing on advocacy to a larger extent than necessary.
Customer & Team Experience Level
If your stakeholders have done this before, they likely know what to expect. If not, the difficulties associated with development will surprise them.
Lack of experience with a development project can cause some participants to grow weary of questions needed to gain clarity. This may lead to a perception that developers are too slow to understand the problem or develop the solution.
Level of Project Sponsor
If the sponsor of the work is a C-level executive or VP, there have been leadership team discussions about the work and there should be a higher degree of alignment across departments. Most executives have been through this type of thing before and know there will be bumps in the road. And they also know how to spot sideways movement before it has a chance to have a large effect on project outcome.
But they usually won’t be dialed into all the project details due to the nature of their job. The key for success here is communication. Frequent, accurate, honest communication about where things stand.
If the project sponsor is a mid-level manager, there’s a higher likelihood that they haven’t experienced as many projects. They may not have experience aligning leaders across the business. They’ll be more attentive to the details in most cases but they may not understand the impact of all the details.
The key for success here is both education and coaching. Communicate details with a confirmed mutual understanding of their impact. Coach them on how to communicate impact to leadership and the odds of success will increase.
Accounting for the Not-So-Obvious
So great — what do you do with this info when you’re putting together an estimate?
I use a simple Risk Assessment tool that informs the project estimation process and suggests a period for check-ins. These check-ins are a time for thorough review and risk re-assessment. This helps ensure things are on track.
Risk Assessment Tool
A screen shot of my Risk Assessment tool is below.
Taking various details into account, it provides four key outputs:
- Inherent Risk: Risk for project estimation errors based on factors driven by project details and participants.
- Overall Risk: Inherent Risk + additional risk to future business should the project estimation be incorrect.
- Recommended Review Time: A time period, based on person-hours of project time, in which the project should be reviewed and risk re-evaluated.
- Recommended Contingency: An amount to consider adding to estimates delivered by the team. How you apply it is up to you: whole project, task-level, or on more complex tasks only.
Make sure to apply contingency for fixed-fee and time-and-materials projects. Why contingency on T&M projects? Because underestimating carries greater risk to the client.
I’ve seen project managers approach T&M projects with much less care, when more should be the rule. Make no mistake, your customer keeps close tabs on T&M projects, usually watching with more detail than fixed fee.
A Complete View
Managing risk is an ongoing part of any project and requires a proactive approach. Understanding the complete project risk better positions the team to manage the project.
If you’re interested in receiving access to the Risk Assessment tool and other CTO Tools as they become available, click here to sign up for the newsletter or follow me on LinkedIn!
Leave a Reply