Project Planning II: Effort

Project Planning I: The Work Breakdown Structure

Introduction

All plans are wrong. Nevertheless people take water with them when they start a journey. So the question is: how much is enough and how much is too much?

Any project consumes effort e.g. measured in working hours or working days. But at least the organisation (represented by the project sponsor) which pays for the project and gains the benefits has to know the effort in advance. First, because the resources carrying out the work have to be provided, and second, because a usual project only makes sense (e.g. profit, savings), if the returns are larger than the effort/cost.

Therefore we need to know the effort of a project in advance, although we know, that our plan will only more or less correspond to reality.

Background

We started with the fundamentals of planning in part I, and our basic project organisation is a structure like this:

We have a core team with some core team members (TM) and a project leader (PL) reporting to the project sponsor (SP). In addition to that we have a basic work breakdown structure which was produced by this core team:

Now we share the responsibility among the members of the core team:

Share Responsiblity

Our specific core team consists of John, Susan, Lydia, and Mike. Each work package gets exactly one person responsible for managing it - despite of, who and how many people will work on it:

Now let us start with the crucial part of effort planning. Is is based on selecting the most effective method of estimating depending on the type of each work package.

The following considerations are made by the responsible persons for their work packages.

Obvious Effort

Let us say in our project in our working context

• the work package "4.3 Install IDE" will - according to Lydia - obviously need 4 hours net effort of one person in order to be done (with sufficient quality),
• "8.1 Turn on new system" will - according to John - obviously need 1 hour,
• "8.2 Turn off old system" will - according to John - obviously need 4 hours,
• "1.1 Plan project" will - according to John - obviously need 4 hours of 4 people in the core team (= 16 hours),
• "1.3 Close down project" will - according to John - obviously need 2 hours of 4 people in the core team (= 8 hours), and
• "4.2 Purchase IDE" will - according to Susan - obviously need 2 hours.

Formula

Let us say we can find a formula for some work packages in our project in our working context, again according to the responsible core team member per work package:

• "6.3 Perform trainings" will need 4 hours for each group of 10 users plus 1 trainer and we have 40 users to be trained. So we end up with 10*4*4 + 1*4*4 = 176 hours.
• "7.1 Define test cases" will need 0,5 hours per testcase, and we estimate that we will have around 300 test cases. So it will be 150 hours.
• "7.3 Perform tests" will need 1 hour per testcase, and 10 percent will need retesting. So we have 300 hours plus 30 hours plus 3 hours = 333 hours.
• "1.2 Control project" will need 2 hours of 4 people in the core team in 7 project controlling meetings and 8 hours of the project leader per controlling cycle. The sum is 112 hours,

Experience

Let us say experience helps us in the case of some more work packages in our project in our working context:

• "2.1 Analyse processes" will need 4 hours per business process and we will need to analyse 20 processes (or use cases). So - according to Mike - this work will need 80h.
• "3.1 Define classes" will take 2 hours per class for 20 classes: 40 hours.
• "3.3 Define user interface" will take 6 hours per screen for 10 screens: 60 hours.
• "6.2 Produce training material" will take 5 hours per 1 training hour in class. The training which we repeat for each user group will last 4 hours, so this work package will take 20 hours.
• A system of this size produces 100 requests in the first month, and we will need an average of 2 hours per request to handle it. So "8.3 Handle problems" will need 200 hours.

Acceptance

In some cases we may simply ask the person(s) carrying out he work for the limit in effort they can accept:

• Concerning "3.2 Design database" Lydia says that she can accept 40 hours when we talk about a system with 20 classes.
• Concerning "5.2 Produce UI" Lydia says that she can accept 80 hours when we talk about a system with 10 screens.
• Concerning "7.2 Automate tests" Susan says that she can accept 100 hours for a system with this size.

Work Consists of Work

In the case of "5.1 Code classes and methods" all our approaches so far may fail. So we remember that "work consists of work". Therefore we can break down this work package into smaller work packages:

Now we should not forget to assign responsible persons from the core team to the new sub work packages instead of their parent work package 5.1. Afterwards we can apply any of the method above including the current one (break them down again into even smaller work packages).

Let us say that we finally get 5 * 16 hours, 5 * 40 hours, and 10 * 80 hours (= 80 hours, 200 hours and 800 hours for the work packages 5.1.1, 5.1.2, and 5.1.3.

Top Down

Now we look at the result so far:

It is clear now, that we have an effort so far of at least 2,500 hours in our project.

If this total effort so far is more than everybody expected, we have to switch from project planning to project management, i.e. negotiating and conflict solving. And of course our effort calculation so far should be a very good basis for any negotiation between the project leader and the project sponsor. But this is a different article.

If this total effort so far is less than expected, let us say there is a budget of 3,000 hours, we can distribute the remainder of around 500 hours among the remaining work packages. Maybe that works and gives us a good result. Should we see that some work packages cannot live with their budget of effort (hours), we have to start negotiating in this case, too.

Here is the result:

Points of Interest

When we document all assumptions, we will be able to react to any new developments in the project. E.g. may the result of "3.1 Define classes" be, that 30 instead of 20 classes are necessary. Then we can easily adapt the plan and perform proper project controlling to reach effective project decisions (which again is a different article).

We should also not forget that effort and quality are linked, but only in a limited bandwidth. More effort will increase the quality, but much more effort may not increase quality anymore. Less effort on the other hand will decrease the quality, but too little effort will finally produce no result.

Besides that all calcuations here include only "internal hours" which is work performed by employees of the organisation performing the project. The work of sub-contractors or freelancers is part of all "external cost" (again discussed in a separate article).

History

26th of November, 2015 - Published