Portfolio Estimation?  A life coach might help!

Portfolio Estimation? A life coach might help!

I recently asked a group of people the question “What are the two largest issues in project estimation?”   The group were all involved in delivering value to clients either as developers, testers, methodologists and consultants.  The respondents experience ran the gamut from Scrum and eXtreme through Scaled Agile Framework (SAFe) and Disciplined Agile Development (DaD) to waterfall.  While not a scientific survey, the responses were illuminating.  While I am still in process of compiling the results and extracting themes, I thought I would share one of the first responses: all resources are not created equal.  The respondent made the point that most estimating exercises, which begin at the portfolio level, don’t take into account the nuances of individual experience and capacity when projects are “plucked” from a prioritized portfolio to begin work.  This problem, at the portfolio level, is based on two issues.  The first is making assumptions are based on assumptions and the second is making decisions based on averages.  At the portfolio level both are very hard to avoid.

Nearly all organizations practice some form of portfolio management.  Portfolio management techniques can be range from naïve (e.g. the squeaky wheel method) to sophisticated (e.g. portfolio-level Kanban).  In most cases the decision process as to when to release a piece of work from the portfolio requires making assumptions about the perceived project size and organizational capabilities required to deliver the project. In order to make the assumptions, a number of assumptions must be made (a bit of foreshadowing, assumptions made based on assumptions are a potential problem).  The most important set of assumptions that are made when a project is released is that the requirements and solution are known.  These assumptions will affect how large the project needs to be and the capabilities required to deliver the project. Many organizations go to great lengths to solve this problem.  Tactics used to address this issue include trying to gather and validate all of the requirements before starting any technical work (waterfall), running a small proof-of-concept project (prototypes) to generating rapid feedback (Agile). Other techniques that are used include creating repositories that link skills to people or teams.  And while these tools are useful for assembling teams in matrix organizations, these are rarely useful at the portfolio level because they are not forecasting tools. In all cases, the path that provides the most benefit revolves around generating information as early as possible and then reacting to the information. 

The second major issue is that estimates and budgets divined at the portfolio level are a reflection of averages.  In many cases, organizations use analogies to generate estimates and initial budget numbers for portfolio-level initiatives.  When using analogies an estimator (or group) will compare the project he or she is trying to estimate to completed projects to determine how alike they are to another. For example, if a you think that a project is about 70% the size of a known project, simple arithmetic can be used to estimate the new project.  Other assumptions and perceptions would be used to temper the precision.  Real project performance will reflect on all of the nuances that the technology, solution and the individual capabilities generate.  These nuances will generate variances from the estimate.  As with the knowledge issue, organizations use many techniques to manage the impact of the variances that will occur.  Two popular methods used include contingencies in the work breakdown schedule (waterfall) and backlog re-planning (Agile). In all cases, the best outcomes are reflective of feedback based on performance of real teams delivering value. 

Estimates by definition are never right (hopefully close). Estimates (different than planning) are based on what the estimator knows very early in the process.  What really needs to be built becomes know later in the process after estimates and budgets are set at the portfolio levels.  Mature organizations recognize that as projects progress new information is gathered which should be quickly used to refine estimates and budgets.