PEOPLE S OTHER COMMITMENTS

PEOPLE'S OTHER COMMITMENTS

We once turned around a software development project that was meant to last a year and ended up lasting nearly four years . When we looked back over its history to try to understand what had happened , here's what we discovered .

The original estimates of effort were out by about 50 percent, which in my experience of software projects is not too bad at all. Quite creditable actually. But then, we discovered that the project manager had made a kind of unconscious assumption that everyone would be available to the project full-time . When we checked back over timesheets and other data, we discovered that people had actually worked on the project on average between 1.5 and 2 days per week. Now, I have a degree in applied maths, but you don't need a degree in anything to figure out that a project like this is probably going to run about three years late, which is exactly what happened. Needless to add, the original assumption about staffing levels “ unconscious or otherwise “ was lost along the way, and all that everyone saw was a project that was years behind schedule.

The point here is that we have to take people's other commitments into account. PC-based project planning tools have facilities for doing this where you can allocate people to projects a certain percentage of the time, but at its most simple, all you have to do is make a list for each person that looks, for example, like this:

Reggie

¢ The other project	2 days per week
¢ Personal development	2 hours (0.25 day) per week
¢ ISO 9001/Quality	0.5 days per week
¢ Therefore, available to my project	2.25 days per week .

Note, in particular, that annual leave, public holidays and sickness are all commitments that have to be allowed for.

This is the supply side of a supply/demand equation where the demand has been generated by the list of jobs and associated dependencies and effort derived from Step 2. Step 2 identifies the pile that has to be moved; Step 4 shows how it will be moved.

Note that this business also applies to yourself as project leader. Often, especially in software projects, project management is what the project leader does when he has any time left over from doing technical work. A rule of thumb that we offer is that you should reckon on 6 “8 percent of total project effort for project management: 6 percent would apply to smaller projects “ say, 6 people or less “ while 8 percent would be for larger ones “ say, above 12 people.

This figure is intended to cover work by any member of the project team on:

• project planning activities including scheduling, estimating and updating of PC-based tool files

• project meetings to record progress or set targets

• project reporting

• day-to-day work assignment

• all project team "people" issues including staff appraisals and reviews

• day-to-day problem solving and troubleshooting

• liaison with any suppliers, both internal and external

• liaison with management

• liaison with the customer

• liaison with related /dependent projects

• normal ongoing recruitment

• quality

• quality plan/configuration management plan.

Though work by any member of the team is allowed for here, in reality a large proportion of this work (75 “80 percent or even more) will be done by the project manager and/or team leaders .

Using this rule of thumb it is possible to work out the total amount of project management effort required in, say, man-days or man-months.

By averaging this figure out over the life of a project it is possible to see what daily and weekly levels of project management are required “ measured now in hours per day or days per week.

The three examples below should illustrate this.

EXAMPLE 1

A project lasting 6 months and with a total effort of 22 man-months. (Average number of people on the project is 3.7.)

Assuming 6 percent project management overhead based on total effort, this gives 1.32 man-months = 26.4 man-days ( assuming 20 man-days = 1 man-month).

Thus, over the 120 elapsed days (assuming 20 working days in a working month) of the project, the project management overhead = 26.4/120 = 0.22 days (= 1.76 hours for an 8-hour day) per day. So, in an 8- hour day, the project manager can reckon on this many hours per day being taken up with project management work.

EXAMPLE 2

A project lasting 12 months and with a total effort of 170 man-months. (Average number of people on the project is 14.2.)

Assuming 8 percent project management overhead based on total effort, this gives 13.6 man-months.

Thus, over the 12 elapsed months of the project, the project management overhead = 13.6/12 = 1.1 months per month. So, in this scenario, a project manager is likely to be busy pretty much full-time doing nothing but project management.

If you don't allow yourself this much time and effort then you are not doing the job properly, and you are actually in breach of Step 3: while the project may have a nominal project manager, in reality, nobody is doing the job.

The previous examples assume a flat team structure. In that case, a project manager carries the majority of the project management responsibility. An alternative to this is to set up some kind of team structure. This will have the effect of spreading the project management load across the project manager and the team leaders.

The example which follows takes Example 2 and does exactly this, breaking the single monolithic project team down into three groups, where each group takes responsibility for one-third of the overall project effort.

EXAMPLE 3

For each team the total project management overhead is 8 percent of the total effort of 56.7 man-months = 4.5 man-months, which over the life of the project is 0.38 months per month, that is about 3 hours per day.

For the project manager who now has a team of three people, the overhead is 3 people for 1 year = 36 man-months by 8 percent, which gives approximately 3 man-months (2.88) or a quarter of his time over the year.

Note

This calculation assumes that all three team leaders are 100 percent as effective as the project manager and that there is no overhead involved in maintaining this hierarchy. In reality the project manager would increase his project management overhead in dealing with the team leaders.

Examples 2 and 3 both illustrate valid ways in which this project could be managed. In both cases, you should always try to keep team sizes as small as possible. Then, in choosing between flat and hierarchical structures, there are advantages and disadvantages of each. (There is no better or worse here “ ultimately it is the project manager's choice.)