I remember I read an article a while ago about the difference between Construction Projects and IT Projects. The similarities are obvious: in both projects it starts with a concept, then comes planning followed by design and drawing the blue print (using CAD is construction, UML in IT for example), detailed design, implementation, test and delivery.
But there’s a catch! There’s a fundamental difference between two industries – the best analogy I’ve come across (and I don’t remember where I read it so unable to mention the source here unfortunately) is that Construction is like building using Lego bricks and IT is like shaping a Play Dough.
IT is much more fluid and flexible and comes with it complexity and “uncertainty”. That’s probably why estimation in Construction is much more accurate compared to IT projects. In IT there is a lot of moving parts; these malleable moving parts can be pressed, pinched, rolled and flattened.
So estimating IT projects should be different from estimating construction projects to cater for the very nature of these projects. There have been a number of attempts to formulate the IT estimation and each has its own merits and drawbacks.
After studying and applying many of these methods, I concluded that the best approach to estimate is to “learn from the history” and customise it to your project requirements and assumptions.
So what is “Learn from the history”? There are countless of IT projects which have been implemented around the globe and there’s a good chance your project has similarity with some of them. Chances are other teams have implemented an ERP using Oracle EBS with similar scope to yours. Or there are projects similar to your upcoming “Website Facelift” initiative which have used ASP.Net with C#, WCF and SQL Server 2012 database. Or alternatively the “history” can be sourced from your previous projects with the same specification, as long as there’s one.
By taking the effort spent on adequate number of similar projects and average them out, we have a “ball-park” industry average we can base our project on. Obviously no two project are identical so we should be able to tweak the figures based on our Project Scope (for instance whether the requirements are defined already, types and cycles of testing, number of deployment environments, scope of user training and service introduction, etc.) as well as some Key Assumptions (e.g. size and skillset of the team, overall complexity of the project, onshore vs. off-shore team, etc.).
At ArciFrame we figured out that by following the three steps below and applying the “industry ball-parks” for similar project types on top of that we can get to a point that we have a fairly reliable estimate:
- Define Project Details and Assumptions
- Define Project Type (e.g. SAP Implementation or Android Mobile App)
- Define High Level Work Items
The result is an estimate which plays a key role in making strategic decisions upon the initiation or even during an IT project.
Share your thoughts and experiences here.