Both men are in agreement on the issue of software project management:

• Poor management can increase software costs more than any other factor {Boehm}
• Poor management can decrease software productivity more rapidly than any other factor {Boehm}
• The single most important factor in the success of a software project is the talent of its project manager {Brooks}
• Today's major problems are not technical problems, but management problems {Brooks}

Given that, irrespective of what source you turn to, the success rate for software projects seems to be a single digit number [Wall Street Journal January 1994 - 1%; Software Woes [Addison Wesley] - 2%, these words seem - if anything - more relevant today than ever before.

One of the most pervasive myths in the software industry is that the failure of software projects is due to the technical nature of these projects. The myth would have it that pretty much every software project is a research project, where we are boldly going where no man has gone before. I have to say that in the twenty or so years that I have been involved in software, I have never seen a project fail for technical reasons. Neither do I know anybody who has ever seen such a thing.

Projects fail or go awry because some basic issues aren't taken care of. And if you'd like to know what these issues are, then here are the Top Ten of them, with the first four certainly being the biggest offenders, and the top one the biggest project killer of all.

1. The goal of the project isn't defined properly
2. The goal of the project is defined properly, but then changes to it aren't controlled
3. The project is planned properly but then it isn't resourced as was planned
4. The project is planned such that it has no contingency
5. The project isn't planned properly
6. The project isn't led properly
7. The expectations of project participants aren't managed
8. The project is planned properly but then progress against the plan is not monitored and controlled properly
9. Project reporting is inadequate or non-existent
10. When projects get in to trouble, people believe the problem can be solved by some simple action e.g. work harder, extend the deadline, add more resources

(1) The goal of the project isn't defined properly.

This has been said so many times, beginning right back in Ancient Rome ('If you don't know what port you're sailing to, then any wind is a fair wind' - Pliny), that it has become a platitude, but it is as true now as it ever was. Look at the Taurus project in the London Stock Exchange a couple of years ago. The day after its collapse, the Chairman of the Stock Exchange said in the Financial Times, 'we were testing parts of the system while other parts hadn't been designed or built.'

(2) The goal of the project is defined properly, but then changes to it aren't controlled

The moving goalposts syndrome and the bane of localisers' lives. The famous software project management phrase is 'we've absorbed that into the schedule'. Nothing can be absorbed into the schedule. If your plan has some contingency in it, then you can appear to do that, but what you are actually doing is spending a part of your contingency. If your plan has no contingency in it, then all you are really doing is joining the 'it'll be alright on the day' school of project management.

(3) The project is planned properly but then it isn't resourced as was planned

I've seen projects which were meant to last a year last four years because of this. It's a dangerous one because the slip is so gradual. Sloppy monitoring of the plan [see (8)] will make it even more difficult to track. You must allow for people's other commitments when you build your plan around them.

(4) The project is planned such that it has no contingency

If you plan your plan without any contingency, then the only logical conclusion one can come to is that you believe it will turn out exactly like you said. Now, of all the things that might happen, this has to be the least likely. Yet, in putting no contingency into the plan, we're saying that this is precisely the thing we expect to happen.

(5) The project isn't planned properly

Project planning is the act of chaining together all the myriad little jobs that go to make up the project. A proper plan attempts to do this chaining together as early in the project as possible. If this isn't done, then there are only two other ways the chaining together can happen. The first is that it is done in real time - this is the firefighting project manager, where everything is unexpected, a surprise, a crisis. The second is that it is not done at all - this is the go-with-the-flow, it'll be alright on the day approach. We've all seen too often the effects of the last two approaches.

(6) The project isn't led properly

For the project to be successful, all the jobs identified in (5) need to be done. One person - hopefully, the Project Manager - has to make sure that this happens. Note, in particular, that this includes jobs which aren't necessarily being done by 'our' people i.e. those jobs being done by management, the customer, other departments, suppliers, subcontractors, vendors and so on.

(7) The expectations of project participants aren't managed

People often say 'in our company deadlines are imposed on us'. They say this as though they had somehow been victims of a mugging - they were walking quietly down the corridor and then suddenly somebody imposed a deadline on them. Now, it seems to me that if I, as the Project Manager, accept something you as management or customer pass to me - irrespective of how much pressure you put on me to accept it - then it's not so much a mugging. It's more like a conspiracy to commit a felony. You thought up something and I told you it could be done. What's more, I agreed to do it for you. Who's at fault here? You for thinking up the crime or me for accepting it?

Not all projects - as they are offered to us - are possible. We need to make very clear, up front and over the life of the project, what the project participants - in particular, the customer and the management - can expect from the project.

(8) The project is planned properly but then progress against the plan is not monitored and controlled properly

The detailed chaining together of jobs described in (5) is our chart through the shoals of the project. To develop the plan, only to throw it away or disregard it, particularly when pressure comes on, is lunacy for which we truly deserve to suffer.

(9) Project reporting is inadequate or non-existent

Most status reports are packed full of incident, but manage to conceal utterly any useful information, like whether the project is on target or not, or what the current big issues are. Lack of project reporting on its own isn't enough to sink the project, but it certainly doesn't help.

(10) When projects get in to trouble, people believe the problem can be solved by some simple action e.g. work harder, extend the deadline, add more resources

In general, it can't. If the project gets into trouble it's because somebody got the planning wrong. If this happens to you, then what you need to do is to go back and plan it all over again.

Summary

Improving the project management part of your process will bring bigger returns than any other single thing you can do.

To improve it, all you have to do is to have an approach which:

1. Provides the ability to clearly define the project goal
2. Provides a change control system
3. Provides a way of ensuring that planned resourcing is achieved, and when it is not that everybody is aware of the consequences [(2), (4), (7), (8) and (9) will do this for you]
4. Provides a way of including contingency in the plan
5. Enables the upfront production of project plans which predict a possible chaining together of all the jobs in the project
6. Makes it clear that project managers are accountable for projects
7. Ensures that the expectations of project participants aren't confined to a footnote in the plan but are a crucial element of the project planning, progression and eventual success
8. Provides simple and effective monitoring and control methods
9. Project simple and effective reporting mechanisms
10. Allows that when projects get into trouble the source of the problem is looked for in the correct place.

If you have such an approach, or can modify yours to include such things, then - at the risk of stating the obvious (but I'll state it any way) - all you have to do is DO WHAT THE APPROACH SAYS.

---

Fergus O'Connell, ETP
Moatstown House, Athy
Co. Kildare, Ireland
Tel +353 507 31989
Fax +353 507 31092
Email etp@indigo.ie