Estimating Projects

We often get asked by clients as well as partners “How do you estimate custom application projects with any level of accuracy?” I would like to be able to tell them that we have an estimation tool that you just provide a couple of parameters and a high level idea and it will produce an a perfect estimate, work plan and budget. But this is not the case. Estimating is as much ART as SCIENCE.

Over the past 10 years, Catapult Systems has been able to hone an estimation tool that provides a solid foundation for producing estimates. Here are the basic ideas behind how we estimate projects and utilize our tool. First, and most importantly, we MUST talk with the client. What is the problem they are trying to solve, what toolset are we going to use, what are the requirements of the solution? Through several conversations, we are able to derive a high level solution – not really a technical architecture – that comes later on during the Designing phase, but a summary level understanding of the technological parameters.

Once we understand what it is we need to build, we begin to break down the solution into components. These components may be items such as Web Pages, Stored Procedures, Business Objects, Integration Points or whatever we really need to do for the solution. The idea is simple – decompose the solution into small enough pieces that we can get our head around it and figure out how much work it will be to BUILD it. Do this for every piece of the solution puzzle.

So, now we have all the small pieces of the puzzle and how much effort it will take to construct the pieces. This is where the estimation tool really begins to help. Over the years of performing post mortem analysis on projects and how well the original estimates hit the target, we have been able to define a few formulas that will help fill in the effort for all the other MSF phases of the work. At a very high level, we know that the Developing phase of a typical project should comprise roughly 1/3 of the total effort – after all, we must have Envisioning, Planning, Stabilizing and Deploying phases as well.

This is where some of the “Art” comes in to play. Not every project is the same, not every client has the same expectations. Some projects will require more or less effort during each phase as well as different deliverables. This is where it becomes necessary to truly understand your client and their needs. By changing the standard distribution of the Percentages by Phase parameters in the estimation tool – we can effectively allocate more or less effort to each phase. Obviously this will only provide the total effort for the phase and a basic breakdown of those hours across a default list of tasks. These tasks are items such as performing workshops for design, writing the technical design specifications, data modeling, integration testing, conducting training sessions, creating the work plan, etc.

Once we have the basic effort breakdown (usually captured as man-hours) we need to begin to understand how the work-breakdown-structure (WBS) will look like. This is a high level plan of how many resources the project may have at any given time in the project. The WBS indicates how many resources and what type should be working on the effort at any given time.

Don’t Over Engineer Your Solution

I was meeting with a potential client a few days ago and over the course of our discussions they began to relate their frustrations with a previous consulting firm they were dealing with. The analogy was “I would tell the consultant I would like for him to take this apple from my hand and take it to the kitchen. The consultant would then begin over engineering the solution. Which path to the kitchen should I take? Which door should I go through? Do I need to take more apples in case somebody else wants one? Should I bring some other fruit in case they don’t like apples?”

In our line of consulting we are often engaged by clients who have a vision of a product or application they need to perform their day to day tasks. Oftentimes this application is replacing tedious manual tasks the employee must do on a regular basis. They know exactly how to do it every time since this painful ordeal is performed ad nausea. In this case, they know the business process to a T. But what they usually do not know or understand is how to create an application (be it a Web Application, Mobile Phone App, or any other technology). After we are engaged and understand their needs and the business steps, we must begin to develop a solution to help them ease the pain. During this step, it is very tempting to over engineer our solution – after all, that is what we have been taught to do and strive for – creating a highly scalable, highly available solution. But this is not always the need for the client. Do we need a doubly redundant server cluster hosting SOA architecture for a team of users that only has 10 people and is not processing high volumes of data? Not really. We must all find the right fit for our solutions based not only on the business requirements, but on the overall vision the client has for their technology.

Engineer a solution that fits what the client is really asking for – we don’t have to build a mansion if they are really just looking for a shed for their lawnmower.