Five Questions to Ask Before You Reset Your Project Baseline
In traditional project management, teams go through a process of estimating the costs and the timing of activities. They create a baseline, against which the project is then measured. Experts continue to argue about whether projects should be re-estimated when appropriate. Should we allow teams to change estimates, with or without the consent of clients and/or management, when it becomes clear that the estimate is seriously flawed? Does it matter whether the estimate is flawed due to estimation errors or a change in the project?
The decision on whether to change the baseline can seem complex but it doesn’t need to be hard. You need to have a solid change management procedure and know what you want to achieve in your post project reviews. If you don’t know how to create a change management procedure, read this. In this blog, I outline some questions that you should consider before you make the decision about whether to reset the baseline.
What do you want to achieve in your post project reviews?
I always like to start with the end in sight. What is the purpose of the post project review? Are you attempting to compare the end results with the beginning projections, to see what your journey was? Or, are you trying to compare the actual results for the scope of work that was done with the projected results for the same work? Does the evolution of the project matter in this context? Are there some projects where it does matter, and some projects where it doesn’t?
We are living in an era of increasing change. That’s not going to stop. It’s only going to get worse. Technology is moving faster and faster and the need to adapt in order to stay competitive is only going to become stronger.
Is the organization planning to use comparisons between the baseline and final results to measure team or individual performance?
Some organizations seem determined to use the post project review as a sledgehammer to beat up on teams and individuals. If you are using the comparisons between actual results and baseline data to reward teams or individuals for project success, why wouldn’t you want the baseline to be a projection on what was actually done? It hardly seems fair to unnecessarily punish a team because the scope was increased by the client, or necessitated by a technology change in the industry.
Is a scope change being made, and if so, why?
When a client, or your management team, initiates a change to the project, it is a very clear indication that scope may change for a good reason. Sometimes project teams become aware of a change that makes a project change proposal smart (the change is often an industry or technology evolution). It might be as simple as the introduction of a new kitchen counter material that wasn’t available when an apartment complex renovation was planned. Suddenly, there is the opportunity to save money by using a new and better material.
One critical part of this discussion is ensuring that you effectively use a documented project change process. This ensures that changes to the baseline are made for valid reasons, and not simply as a way to make the project look more successful than it is or was.
Was the estimate flawed because of human errors or lack of clarity on the requirements?
Estimating is not an exact science. There will be times when you find that your estimates are flawed. There is some learning that can occur here when organizations make the most of tracking these data and understanding the situation.
When the estimate was flawed because of a lack of clarity on the requirements, the question is why. Sometimes, clients simply don’t know what they want. Other times, project teams don’t spend the time to identify the requirements. Was this a deliberate decision to create a very Agile structure, or was this laziness? You need to be honest about what was going on.
If the team understood the requirements, and the estimate was flawed, you might ask if you need to improve your estimating process. Is the team doing the estimate, or did you have one person, who wasn’t going to do the work, perform the estimate? Many organizations use a professional estimator, which is thought to add a level of expertise to the estimate. I particularly see this in construction projects and legal matters. I’ve seen it work both ways.
When your teams are using their creative intellects to accomplish the work, you need some team commitment to the budget that you shared with the client. If the individual hasn’t been part of that process, he/she may simply reject that idea. Yet, there can be some value in having some expertise involved in your estimating process. Ideally, your creative teams include someone with that expertise.
When an organization wants to be Agile, it’s important to understand the client’s price sensitivity. When a client is price sensitive, it is incredibly important that project requirements are understood. If you are working on a technology project, you can certainly work in sprints, and not try to plan out the entire job too far in advance. But, you need a plan that works for your client.
Do these ideas make sense? Let me know. Reach out to me to chat.
Originally published at www.smartprojex.com on July 24, 2017.
