Estimating

Why, What, How?

There is a belief that Project Managers of business solution and IT projects are not very good at estimating, unlike their counterparts in construction projects. There is an error in this belief - according to several construction Project Managers, they are not particularly accurate either.

There are many theories and approaches but no fully reliable way for predicting the time and effort it will take to deliver a business solution. When you bear in mind the complexity of any business solution and the dramatic variance in individual productivity, you can understand why it cannot be an exact science. Some IT developers seem to be able to create systems as fluently as they speak their mother tongue. Others, maybe sitting at the next desk, struggle to deliver. There can be a factor of 10 to 1 in personal productivity between the best and the worst. These are just a few of many factors. We will take a look at several key issues then summarise the drivers of effort.

There are many methods for estimating. If your organisation has adopted standard practices you should probably stick to them - but apply a little of your own understanding to the results. Many approaches are geared to the delivery of a working IT system. Fewer approaches have been formulated to estimate the overall demands of delivering a successful business solution - ie

• the IT system, plus
• the process changes and detailed procedures, plus
• the capability and motivation of the workforce to use it.

Estimating techniques always involve assumptions and guesses. We can, of course, just guess the result. Somehow, though, it seems more scientific to guess the input data then perform some impressive process to generate a mathematical result.

What we keep returning to is the value of past experience. Experienced Project Managers will be able to estimate time and effort on the basis of past experience - both their own and the corporate experience of their colleagues. Some of the more reliable forms of estimation are where this knowledge has been captured and structured so that it can be share and re-used by any Project Manager. To do this successfully you need a way of capturing the factors that affect the effort - we will return to those after examining some concepts and techniques.

Approaches to estimating

In the ePMbook, we will not study any specific techniques in detail - you should go to the appropriate sources if you wish to know more. Here are a few of the concepts that are used:

Approach	Commentary
We did it before	Undoubtedly the most reliable information - provided you have previously undertaken a similar project. Estimates are based on the actual results from a similar previous project. (Make sure you use the actual results and not the original plan.) In some situations it is common to repeat projects, eg roll-out programmes, or working for software vendors who routinely implement the solution for their clients.
Guess (estimation by analogy)	Well, an educated guess based on past experience of the Project Manager, and, hopefully, also based on the collective experience and knowledge of several Project Managers drawn from the results of may specific projects. Here you are looking for analogous experiences from which you can make direct estimates, or from which you can extrapolate an estimate bearing in mind what specific differences there are in your proposed project.
Structured knowledgebase of past experience	This uses the concept of estimation by analogy but builds a structured knowledgebase that is used to accumulate experience from many projects and Project Managers. The key to its success is an intelligent way of classifying and quantifying the many variables that affect the time and effort.
How many lines of code	This is an IT Project Manager's view of the world. Depending on the programming techniques and languages to be used, you can use average productivity rates to calculate how much effort will be required. There are two significant flaws in this approach: How did you estimate the number of lines of code that is the input to the calculation? Delivering a business solution is a much wider challenge than creating a working computer system. It is not valid to extrapolate the other work from the IT development effort. Some systems are easy to build but relatively hard to implement (particularly, for example, package or component-based solutions) and some solutions are complex in development terms but not difficult to introduce into the business. Beware of statements like "testing effort should be 25% of development". Take a look at Putman's SLIM (Software Lifecycle Management) for an example of this logic.
How much functionality	Again, more of an IT perspective, but, this time, giving a more scientific way of identifying the input criteria - ie, how much functionality needs to be delivered. Functionality can be identified from the scope and initial high-level design of the solution. It can be classified and quantified so that tables based on past experience can be used to convert a given set of functionality into realistic estimates. Take a look at Albrecht's Function Point Analysis method to see this at work.
Top Down	A subsidiary technique. Once you have established a good overall estimate for the project, you sub-divide it down through the layers of the work breakdown structure, for example, development will be 50% of the total, testing will be 25% etc; then sub-divide development and testing into their components etc etc etc.
Bottom Up	Each individual piece of work is estimated on its own merit. These are then summed together to find the estimated efforts for the various summary level activities and overall project. One disadvantage with this approach is the tendency for overall effort to grow in line with the amount of detail put into the plan.
Top-down meets bottom-up	An overall estimate is calculated for the project. Individual estimates are then calculated, or drawn from previous plans, to represent the relative weights of the tasks. The overall estimate is then apportioned across the various summary and detailed level tasks using the bottom-up figures as weights.

Factors affecting effort in major business change projects

The effort to develop an IT system is often the easiest part of the project to plan and estimate - particularly for those Project Managers from an IT background. If, however, you are considering the overall success of a business solution there will be many other factors to consider.

Here's one viewpoint that is targeted largely at the effort to gain acceptance of the business requirements and design of the solution.

If you have just one function to deliver, with a mostly pre-defined technical solution and there is only one department affected, that adds up to small x small x small - or small cubed - which is incredibly small. You just sit down with the departmental manager and see which of the few options to pick.

If you have multiple, integrated business processes to re-engineer, using very flexible or loosely defined technical solutions, crossing over several departmental boundaries in many different subsidiaries around the world - that adds up to big x big x big - or big cubed - and that is impossibly big. You will need to discuss a huge amount of issues with a large number of people scattered all over the world. They are unlikely to see things the same way as each other. You will discover no end of irreconcilable differences in their requirements. Best recommendations in one area of the solution will clash with considerations in multiple other areas. You will constantly have to re-visit the issues and the participants to deal with the problems that emerged. Look for a new job now!

The Complexity Factor

Many people believe there is a direct linear relationship between the amount of things you have to achieve and the time it will take to do them - if I do twice as much it will take twice as long. That is a dangerous mistake; the front pages of business newspapers often feature people who thought like that.

Here is something about "things" to think about. We're not going to say what the things are.

• If you have one thing - that is it; there is just the one thing to deal with.
• If you have two things you have the two things, plus you have the way they interact, interfere, overlap, and deal with each other - that is three aspects to deal with.
• If you have three things, you have those three things, you have three different sets of interaction between pairs of the three things, and you have the way all three things combine - that is seven aspects.
• Four things is, er, 15 aspects.
• And nine things is 511.

Granted, effort and duration are also not proportional to the number of aspects in a problem either - but you could argue that:

...or 1023 to be exact - the formula is:

Areas generated = 2ⁿ-1 where n is the number of "things".

So what are these things we have been discussing? Maybe:

• number of systems to be replaced,
• number of integrated components,
• number of business processes to be re-engineered,
• number of departments involved,
• number of locations,
• number of people in a discussion.

Take an easy example: put students in a sub-group to work on a study question.

• One person alone would take a long time to do all the work.
• Two people are faster and produce a better result - but they are not twice as fast as there is a lot of interaction between them.
• Three people are even faster and produce even better results - but, had it been a work assignment, was there enough time saved and sufficient added value to pay for the third person?
• Four people are usually - slower. Adding the extra person has increased the amount of discussion and contention to the extent that the group takes longer than the three-person group.
• Add more people and, clearly, they get even slower. Interestingly, with around six people or more you will usually observe them split into sub-groups - instinct or learnt behaviour?

Balancing effort/cost against benefit/quality and risk

By now, you may have gathered enough ideas and information to form a recommendation about the estimated time and effort for the project, but is your client organisation interested in bartering or gambling?

The effort you put in can be balanced against the benefit you expect and the level of risk you are willing to accept. You would probably put much more effort into defining, building and testing an algorithm to calculate the fuel required for a manned mission to Mars than you would for the fuel required to drive to the next city and back.

Suppose you could deliver 80% of the overall benefit for only 20% of the effort - but with twice the risk of failure. Would your client organisation accept that? This is a particularly important consideration with eProjects where the imperative is to deliver rapid benefits. It is common to address the 80% of normal customer needs that can be met in a simple manner and ignore the 20% of difficult situations that would take much more effort. Often, you might ignore non-standard orders, error handling, cancellations, etc and leave those processes for manual intervention.

The multiple sided "Project Management Triangle"

The Project Management Triangle is a very common observation about planning. You will find several other names for the concept, eg Time/Cost/Quality triangle. It states that if you adjust the time something takes, or the amount of cost it consumes, or the quality that is to be achieved, then you will inevitably affect at least one of the other aspects - eg if you want higher quality it will cost more or take longer to do.

Although that principle is very useful to keep in mind, the full picture is more complex. Many methodologists have added further variables to the balancing forces. So, the Project Management Triangle will be seen with 3, 4, 5 , 6 or more competing pressures, which you will need to balance to obtain optimum benefit from your project.

This is the point in the planning process when people often discover they can't afford the cost, time or resources for the scope they asked for. Usually the best response is to re-examine and simplify the scope. It is easy to dream of building a mansion when all you really need is a house.

Time Boxing

A common response to the competing pressures is "time boxing". Instead of looking at how much time and resource is required to meet the requested scope, we apply the Time/Cost/Quality triangle principles and consider how much scope can be achieved within the time, resource and funding we have available. Estimation is still essential, but the equations are reversed to calculate what we can deliver from the resource we have available.

Time Boxing might be used to re-appraise the optimum scope for the overall project, or it might be applied to set iterative steps or "sprint" stages in an agile approach.

Drivers of effort

There are many other factors that will influence the effort it takes to deliver a successful business solution. Here are many of them:

Super Powers

But, one final thought. You will often benefit greatly or suffer badly from human factors. Hopefully, all team members will be competent at their jobs. Some people turn out to be remarkably skilful and fast at their work. It is particularly the case with computer programming or configuration. Some people will know everything about their speciality and instantly see how to create the output with a high degree of accuracy. Such a person could be ten times faster than normal.

Occasionally, however, you may find team members who struggle with the challenges and deliver poor results, far slower than expected.

As well as allowing for such variances in your estimating, watch out for the risk of basing your estimates on how long a comparable previous project team took to do something similar. They may have been flying or crawling in comparison.

Copyright ©  Simon Wallace, 1999-2016