Making project commitments - Setting the realistic timeline at a very early stage

Have you ever had a fear of making commitments for things which can only been seen after months or years? Have you ever fallen in the situation that you and your team have to work hard for weeks or months to meet the deadlines? Have you ever been failed in meeting the deadlines?
These questions are actually something happening daily to the Project Manager (PM) and without the right method a lot of the answers “YES” could be found for these questions.

1.       Introduction

To overcome the above fears, we need to have the right method for making commitments which I’m going to present in this article. Besides, we also need the right tool to make sure we will meet what we committed which I presented in the recent post Earned Value.

One more thing, the method which I present here is one of my practices which I have applied for several years on many projects. I hope it could work for most of you.

OK, let’s see how it looks like.

2.       Background

One of the very first steps PM has to do is Estimation. PM has to estimate the total effort or total cost after he finalizes the Project Scope. So, after having the number of man-days (or man-months or whatever unit) what’s next? It’s the milestones! Or it’s the commitments! This is the most important thing client wants to know.  Basically, my practice will be based on two tools, the Historical Database and the High Level Schedule.

Picture 1: Method of making commitments

3.       The case study

This case study assumes that we estimated one project and arrived at the total effort of 90 man-days. I used Microsoft Project (MSP) as a tool to do high level scheduling. So, it is expected that the reader should know how to use MSP at a basic level.

3.1.    Historical Database

Using organizational historical database: to break down the effort distribution and to know how much effort it will take for each high level work package of the project. With the given 90 man-days, the distribution would look like:

High level work package	Distribution	man-day
Requirement	8.00%	7.2
Design	16.00%	14.4
Coding & Unit test	43.00%	38.7
Test	16.00%	14.4
Deployment	2.00%	1.8
Customer Support	4.00%	3.6
Project Management	10.00%	9
Configuration Management	1.00%	0.9

Table 1: Effort breakdown by high level work packages.

Using bench marking from the industry: with the effort of 90 man-days there is a minimum, maximum and optimum duration for it.

Max duration (calendar-month)	5.29
Optimum duration (calendar-month)	3.67
Minimum duration (calendar-month)	1.47

Table 2: Minimum, maximum and optimum duration.

There are some sources below which tell us how to arrive at these numbers. If you feel difficult with manipulating these sources, email me and I’ll give you my defined template.

·         http://www.spr.com

·         http://www.qsm.com/FPGearing.html

·         http://www.ifpug.org/discus/messages/1778/7498.html?1135791269

·         http://www.ifpug.org/discus/messages/1778/7498.html?1135791269

·         http://www.ifpug.org/webforum/discus/discus.cgi?pg=prev&topic=1751&page=4745

3.2.    High level schedule

Using high level schedule will give us an overall picture of how the project timeline will be. Moreover, MSP (or any similar tool) can automatically calculate the timeline from the input effort which give us more visibility to make the commitments realistically. 

Step 1: Bringing the breakdown work packages (from table 1) into MSP with some notes:

·         Creating corresponding milestones for the work pages which have deliverables.

·         Entering Work in day (MSP uses hour by default)

·         NOT caring the time yet, it will be considered in step 2

·         Doing something with layout to have the convenient view as below:

 

Picture 2: MSP with high level work packages

Step 2: Resourcing.

With each kind of work package, we should know which kind of resource we’ll need together with the quantity. However, two important factors below must be considered when assigning resource at this stage.

Resource availability: with a month of 22 working days, not all resources will work enough 22 working-days (they may have vacation plan, they may be sick when doing the project, or they may take some hours off for doing interview in one another company J ).

Putting a reasonable number of resources: 9 women can't make a baby in a month. Similarly, sometimes, putting more resources to a work package won’t reduce the duration.

OK, so let’s get back to our case study and I’ll assign resources basing on my expert judgment as below:

High level work package	Resource	Quantity	Availability
Requirement	BA	2	80%
Design	TA	1	80%
	Dev	3	80%
Coding & Unit test	Dev	5	80%
Test	Tester	2	80%
Deployment	Dev	2	100%
Customer Support	Dev	2	50%
Project Management	PM	1	30%
Configuration Management	CMO	1	20%

Table 3: Resource availability

Step 3: Assigning resource to the high level schedule.

We put the numbers from table 3 into the MSP got from picture 1. As the result, MPS will automatically calculate the duration for all work packages. Moreover, it will also calculate the linked milestones to each work package.

Picture 3: The complete high level schedule

Step 4: Making commitments

From this point, we can know when to deliver what basing on the milestones. However, be careful before making commitments. Depending on the risk assessment on each work package, we should add an amount of time buffer correspondingly. In MSP, we can do this by adding lag time to the milestones or using Deadline value for each milestone.

4.       Points of discussion

I have presented this method a few times and most of the times I received questions relating to some common topics as below. So, I’d better list them out here.

About using resource availability: please be noted that there is no change on the total estimated effort at all. The point here is to exclude the time which people plan not to work on the project such as vacation, sickness, etc. So, it is to make our high level schedule or our commitments to be more realistic. In case, you don’t know who will be assigned to the project, I hope you have an organization rate to apply for all resources. Otherwise, my recommendation is using 80%~85%.

Assigning a developer with 400% workload: This is just for utilizing MSP to calculate the duration from the input effort. In the case study, we have 5 developers with 80% availability so in total we have 400% availability. Alternatively, we can assign 5 developers and each has 80% availability.

Using resource availability and time buffer at the project level: when running the project, there will be no buffer at all for particular tasks and the resource availability for doing particular tasks should always be 100%. We apply these techniques at project level to mitigate the risks, not at the task level.

5.       In summary

Using the Historical Database will help to know which high level work packages we need to do on the project and the size of each.

Using MSP to create a high level schedule will help to arrive at the milestones and then the commitments.

Using the industry benchmarking will help to double check whether our commitments have potential risks in term of effort and delivery time.

Completing the high level schedule will also answer how many resources and what kind of resource we need in each period of times. This is also called a staffing plan.