Saturday, March 24, 2012

Seema Sonkiya: Project Estimation Important Notes:

This article is based on PMBOK4 estimation approaches.

1.       Project estimation is done through progressive elaboration process as accuracy of estimation is highly dependent upon availability and quality of information.
2.       Whenever we need to do estimation, strategy and approach is influenced by the fact that where we are in project life cycle.
3.       Approach should be communicated to appropriate and relevant stakeholders. During early stages accuracy is normally ROM which is +-50%, during planning accuracy goes normally +-10% and during execution it can increased to -5 to +10%. All these estimates should be appropriately supported by documented assumptions and recorded for later review; this review is part of risk analysis. In Risk identification process risk are uncovered to identify consequences if assumptions go wrong.
4.       If project in not initiated and if it is asked to provide estimates that will be included in proposal which will serve as official offering from the company to the customer. In most of cases this estimation is done based on the historical information and expert judgment.
a.      High level risks are considered to make estimates as realistic as possible. Risks are considered high level because at this stage we can use only limited resources and information is normally less defined.
b.       Analogous estimation is well known approach in this scenario, which is based on historical information and expert judgment.  Using this approach values of parameters (scope, cost, budget and duration) or measures of scale (size, complexity) for the current or proposed project are determined from previous similar projects.
c.      We need good expertise to estimate projects both in project selection process (when estimates included in project proposal) and in initiation due to less defined information. We need to do estimates based on available information. Yes it is true that normally we given a chance to clarify information from the customer or project sponsor in case of internal project but it is also well known truth that as we move towards execution accuracy becomes high due to availability of greater level of details.
d.      Function point analysis is good candidate in early stages as it is possible to identify input screens, external interfaces, simple reports, derived and complex reports as well as other factors like transaction rates, online updates, distribution environment, performance, response time etc with the help of provided SOW. If function point technique is used it should be compared with analogous estimation as a sanity check. One reason of this check is that analogous estimation provides a basis of management expectation. So it gives an opportunity to reconcile differences before using company resources.
5.       When project is selected and initiated and project budget is included in project charter and we started project planning, in planning project estimates are refined and bottom up estimation is recommended approach. WBS gives a consistent framework for cost planning, estimating and control of cost.
a.       If we are in planning then project schedule is important input because project budget is time phase spending plan, and company expects from a project manager to provide information that serve as a basis to identify how much money is required during which period. In addition project schedule provides information which is time sensitive (like purchase of equipment could be less costly after some time period) and can affect the project cost. In this case project schedule may be updated – Planning is iterative.
b.      My recommendation is to use case point’s parametric approach along with bottom up to accurately estimate project cost.
c.      Accuracy of Use Case point’s estimation depends upon how much standardization is present to define use cases in the company. Structure of use cases vary from company to company and even in project to project. A consistent approach should be defined for each project and communicated appropriate team members.
d.      We need to define atomic transactions in use cases to clearly identify number of transactions and complexity of use cases. Consistent review is required.
6.        Estimates are refined in execution as more is known about the project.
7.        During planning and execution project team should be involved for estimation, and project team members should be educated about the difference between padding and contingency reserves. Establishing reserves is professional responsibility of Project Manager. Project Manager must make sure that pads are not included. Pads are added by project team due to uncertainty and based on guess. But in reserves, estimation uncertainties are translated in identified opportunities and threats.
8.       Estimates cannot be finalized without risk analysis; Estimates are both input and output of identify risk process.
9.       Estimates should be in range depending upon when we are doing- in initiating, planning or in execution. One point estimates generally leads to team member working against the project manager to protect themselves and encourage them to add pads instead of doing open communication about project risk to identify contingency reserves which is calculated for the risk remaining after risk mitigation. As project progresses these reserves are used, reduced or eliminated.
10.   In mature project companies, project team generally takes the services of centralized estimating team. This central team provides services based on lesson learned from prior similar projects. The lessons learned are:
a.      Make sure concurrently implement a standard, centralized risk scoring and risk mitigation approach including tools and templates that allow us to establish appropriate contingency reserves.
b.      Make sure regular review of all projects through the PMO to measure CPI and SPI actual against baselines and recommend actions if deviation outside the established control limits.
c.      An effective change control system should be in place to control estimates to re-baseline as risk evolve or changes occur.
d.      Set up a separate charge code for approved activities that can be capitalized based on company guidelines for capital accounting.
11.   Whenever estimates are revised, revised project budget should be reflected in project charter using change control processes and project sponsor is responsible to do that.
If our estimates will be realistic and there is buy-in from all the relevant stakeholders including team that the estimates are realistic then it serves a basis to control the project cost and a project manager is comfortably identify corrective action when project deviate from project planned estimates. If estimates are not realistic and not supported by risk processes then it will be impossible effort to identify when to take corrective action in execution as there is absence of realistic basis to control processes.
Seema Sonkiya

14 comments:

  1. Project estimation is a process of Software Engineering and in several cases I have noticed that proper emphasis has not been given here. I appreciate to write articles on Project estimation and making into the notice. So, people can understand the involvement.

    Thanks for writing this enlightening article.

    ReplyDelete
  2. It's very useful article please keep sharing information.

    ReplyDelete
  3. It's very useful blog for project estimation. i really appreciate.

    ReplyDelete
  4. I appreciate…It was concise but still very informative. Hope to see many such articles in the time to come.

    ReplyDelete
  5. I received following comment through mail; don’t know why this is not showing here. So I am pasting it here:

    David Pederson noreply-comment@blogger.com
    Mar 30 (1 day ago)

    to me
    David Pederson has left a new comment on your post "Project Estimation: Important Notes:":

    Seema,
    I just wanted to let you know that I found this useful. I would like to hear your comments on applying this to a Lean or Scrum oriented project though.

    Also, I think you are correct in your focus on the use cases and making atomic estimates for the moving parts within them but I am curious to know how you catalog those estimates once they are done and how you share that information across projects. I see it as metadata but am not yet sure how I will really store it without adding hours of effort to include it.

    Posted by David Pederson to Seema Sonkiya PMP at March 30, 2012 8:21 AM
    ----------
    David you are asking in detail Use Case Point parametric estimation. I will write separate article for it soon. Thanks for your nice comments.

    ReplyDelete
  6. I have re-read the article and would like to thank you again for this enlightening article.

    ReplyDelete
  7. Thank you for the info. It sounds pretty user friendly. I guess I’ll pick one up for fun. thank u.

    ISTQB Training Institute in Chennai

    ReplyDelete

I appreciate your active participation, so please never forget to click on "subscribe by email" while commenting. Thanks for your comments.
Kindly recommended this page by clicking on g+1