Things to note when doing an Estimation for an Enterprise level Project at presale stage

Estimation is one of the key thing in an organization, why i’m saying this is — it will directly impact the culture of the organization and also the work-life balance of the employee. Also it will have the impact on the client trust as well. If you give an unrealistic estimate and not able to deliver it properly then the client also will get frustrated. Due to this, it is very important that to give a better focus during the estimation phase of the presale activity and properly communicate the complexities and the facts that lead to the specific estimation to the client.

When it comes estimations, usually we mainly focus on the techniques available that suits our need and then just apply that to our use case. When it comes to available techniques ( As we all moving to Agile we will focus here the Agile projects estimation techniques ):

• Three-point estimate
• Planning poker
• Affinity grouping
• Random distribution
• T-shirt sizes (Estimation units)
• Buckets
• Large, small, uncertain
• Dot voting

All the above has been well explained with the use in here and I’m not going to explain them here. But based on my experience, when it comes to presale what i can suggest is we can go ahead with the “Three-point estimate”. Why I’m suggesting is at the presale stage we get into a situation like:

1. We don’t know well detailed scope of the project
2. We know or can plan what are the technologies involved, but there can be doubts in the complexity on each where a Proof of Concept is required
3. There can be resources issues on the technology stack, sometimes experts will be available sometimes not in the company
4. Client may expect kind of a estimate that they can convert that into cost and see at what range this project will cost, in this case we need to estimate for all the features, which should avoid long gap with the actual implementation
5. Even though we may done a similar setup, there can version upgrades and fixes may introduced to the products, there can be question how to estimate it

When considering all the above we need a estimation technique where it should cater both experienced persons involvement and also a new beginners involvement during the implementation stage. This leads to accept the estimation technique of “Three-point estimate”.

Three-point estimate or PERT ( Project Evaluation and Review Technique )

Yes when we look into the Three-point estimate then the similar PERT also comes into picture. Then we will come to a point where which one to use. The main difference between these two is that the PERT introduces a weighted average where the most likely effort will be multiplied by 4 and the average will be calculated between all three ( most optimistic estimate (O), most likely estimate (M) and pessimistic estimate (least likely estimate (L) ). As the most likely is weighted in an enterprise project we may have more uncertainties and R&D works will be expected, so this kind of weighting will give an estimation closer to the actual implementation effort.

You can refer Three-point estimate and PERT articles to get more on the equations to be used and can create an excel with the equations to make it easier while doing work break down estimation.

Highlights during estimation at presale stage

• Better to maintain a separate team for presale activities with domain and technical expertise.
• Make sure the presale team involve in development or implementation activities during each quarter or rotational based. This will provide better / accurate estimation for Most Likely part.
• Do not confuse with “We have done it before” during the estimation process, this can go wrong in the below scenarios. When doing the platform implementations there can be product version upgrades, Operating system level upgrades and technology wise syntax updates, so these needs be taken into consider and proper estimation needs to be made.
• When doing environment wise implementations the second environment will take less time than the first, but when doing new projects first environment always consider it as fresh, unless you are doing the exact same deployment.
• Always make sure to add buffer to resources, because at resource level the estimation can change based on the expertise. There is no guarantee that the same presale team will do the work.
• As a common approach try to make sure that you are taking the 95% confidence level.
• If you have doubts always do a quick possible POC before sharing the estimation. This will help to get the confidence that this can be done.

Resource Loading

When resource loading make sure that the platform is ready by the Devops team before loading your development and QA teams to the project. As a practice you can load the QA team at the verification stage of the platform and the development team once you have the initial Detailed Designs are ready. If its sprint based loading then make sure at-least 2–3 sprints designs were finalized and also you have an overall design plan with dependent features.

One option is like the platform and the detailed design phase can be parallel and once the detailed design is over then can load the development team. This will help to manage the cost and also make sure the parallel tasks are identified at-least at possible level during the presale activity. If you failed to do this, then will impact the project timelines and also can cause idle of the resources due to dependency tasks.

That’s it…, thought to share this based on my experience which can help someone who starts on the presale and estimation…

Appreciate any feedback as well.