Project Estimates - A Major Root of Project Peril

There are dozens and dozens of opinions about the critical success factors for projects involving technology (PIT).  All of them are correct.  But none of them capture what is, in my humble opinion a major root of the problems encountered downstream with PITs. 

First, let me remind folks that I use the terminology "projects involving technology" because few projects are actually "technology projects" - most projects involving technology are automation efforts in behalf of a business program - so it is not a "technology project" at all.  The distinction is important because the perception of a project as an "IT project" carries a nuclear torpedo. See my previous post on topic for more on this.

To get back to our roots of project perils, we have to go back to the very beginning of the project lifecycle - back to where we have made estimates of the project concept, scope, architecture, and methodology.  All of the these input assumptions drive accuracy of the project's guidance systems. I want to focus on the first two in this post.

The truth is that in the early stages, it is impossible to estimate, yet we do it anyway. Recognizing that we have this challenge, what can we do to improve our estimates so that we avoid the dreaded "F" (failure) word?

What do I mean by estimating a concept?  When we begin thinking about a automating some portion of the business program, we think in terms of the "business case", but often the business case is buried in an "IT justification" that does little more than cloud the waters of project management.  The three most important aspects of a PIT are - business problem, business problem, business problem. 

Are we implementing the project to improve the legacy IT architecture or are we improving the work flow of the business program to improve customer service? Without this clarity, we will have trouble making sure all the business rules are known or identified.  Do we know if we need a business process re-engineering effort?  This should be accounted for in the concept estimate, and frankly, I don't see this accounting as often as I should- what I do see in PITs is surprise that business rules are not articulated and that a process re-engineering is needed.

Our concept estimate drives our scope estimate, and gives us a much better idea of how big the problem(s) we are trying to solve really are.  Are there "use cases" to describe the functionality we need? How many integrations will be needed betwixt and between existing systems?  How many stakeholders are involved and how might they influence the size and shape of the PIT?  

You can begin to see how these very early conversations and musings can have a tremendous impact on the project over time.  If we don't get these two discussions closer to reality, the PIT has no real chance of being managed to scope, schedule and budget. 

Often the project advocates are blind to the probability of poor scope definition emanating from poor concept articulation and the risks that can arise as a result. As a business program executive, your job is to understand and reduce risk for the PIT.  

• Excise all IT justifications from the business case, and to make sure you have fully understood what the (re-engineering) implications are before the PIT estimates are final.  
• Focus on only solving the business problem stated in the concept
• Invite an unbiased view of credible alternatives
• Small is beautiful - the risk of project failure increases four-fold for large PITs. The bigger the project, the more complexity you introduce and the more chances you give yourself to find a new job.

The value of good estimates is self-evident.  But sometimes we forget the downstream impacts that the early estimates have. I once worked with an absolutely stellar project office manager who frequently reminded the team that we go slow in the beginning so that we can go fast later in the project. Paying attention to the estimates early in the project helps maintain momentum later.