One old quote states “Any project can be estimated accurately (once it’s completed).” Yes…hindsight is always 20-20. The trick is getting it as close to right at the beginning as possible.
In the Beginning
Where I’ve come from recently, the PM involvement in the beginning of the project is scarce at best. That wasn’t the case earlier on with Rockwell Collins – the PM was everything…sales, requirements definition, implementation manager, deployment oversight, follow-on tech support. It was very interesting and challenging wearing every hat. But more recently projects have come to me fully estimated with a shell project plan already in place and also in the hands of the customer. That’s scary from a PM’s perspective.
Why is this scary? Well, the project has been priced without PM input. The PM – and preferably the Business Analyst, too – should review the requirements and SOW and provide input into the pricing of the project and certainly into the timeline and overall project plan before it is ever given to the customer.
What to Do Differently
I’ve said this repeatedly, but the PM must be involved in the estimating process. In order to have a solid estimate and ultimately a solid final price to the customer, the PM and BA need to review the requirements and SOW with the Sales or the Account Manager or whoever is serving at this point as the primary POC for the client. Together, these three entities should arrive at the price that is presented to the client.
These days, we should not have a “sales guy” doing all of the business development for an organization. We are doing the client a disservice by not putting someone incredibly knowledgeable about the product and the technology as the primary contact or at least including them upfront in the sales process.
Include Everything Reasonable
This is where Lessons Learned from other projects comes into play. For example, you may know that the data load for this project looks similar to one on a previous project that ended up taking 3 extra weeks. Well, the sales person doesn’t know that so it’s not priced into the project already if you weren’t part of the sales process. What do you do in a case like that? About the only thing you can do once the deal has been signed is bring it up during Kickoff as a potential risk and then track it till it becomes a reality. Revisit it often so it never becomes a surprise to the customer and even provide them with a ballpark dollar figure on what the added effort will be and have a change order ready to give them if and when it becomes apparent that it is necessary. And definitely pass this knowledge along to sales and management so future issues like this can be avoided when pricing engagements for the potential customer.
Summary
I realize this is a very specific example of an issue that probably should have been priced differently – and as you can probably guess this exact situation happened to me, which is why I was able to call it up so easily. However, this scenario could be applied to just about anything you’ve learned along the way on other projects and then see as a potential risk on a new assigned engagement. It’s just unfortunate that the individuals with this hands-on “in the trenches” knowledge of the potential pitfalls and risks that could and should affect pricing are not usually involved in the sales process at all.