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

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:



We did it before Available as a PowerPoint slide 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 Top-down estimation -click for larger pictureA 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.

Effort is proportional to:





Organisational Complexity

To understand this logic, ask yourself:
  • How many things do I have to do?
  • How many choices do I have available in the proposed solution?
  • With how many people do I have to discuss each choice for each thing I have to do?

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

Complexity grows faster than scope - available as a PowerPoint slide 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.

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

Doing something 10 times as big is 1000 times more complex!

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

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

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

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


Balancing effort/cost against benefit/quality and risk

Effort vs Benefit vs Risk - PowerPoint slide available 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"

Time vs Cost vs Quality Triangle - PowerPoint slide available 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.

Time vs Cost vs Quality Triangle - PowerPoint slide available 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:




  • Strength of sponsorship
  • Availability of good resources for the project team
  • Organisational resistance to change
  • Organisational complexity
  • Organisational culture
  • Morale
  • Local cultures
  • Ease of communication
  • Number of locations involved
  • Number of departments to be restructured
  • Number of staff affected
  • Amount of re-training required
  • Impact on external people or bodies (eg customers, suppliers, regulators)
  • Number and complexity of processes to be re-engineered
  • Extent to which processes are intertwined
  • Extent to which the process is within the control of the Project Sponsor (eg dependence on action from external supplier)
  • Degree of improvement required (eg 10% faster is easy; 90% faster will be more of a challenge)
  • Quality of support for these processes from commercially available software products
  • Availability of best practice knowledge concerning the processes within this industry
  • Functionality of IT system
  • Complexity of the technology to be used
  • Development techniques and languages to be used
  • Use of packaged software or component based technology
  • Amount and complexity of integration and interfacing with legacy systems
  • Familiarity of development staff with the technology to be used
  • Productivity of development staff
  • Desired quality of solution
  • Acceptable risk levels - eg depth of testing required
  • Level of documentation required

Super Powers

Superheroes 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.





ePMbook - click to re-load
Copyright ©  Simon Wallace, 1999-2016