|
In this issue…
Why Projects Fail
If you are a writer, then one of the things you dream about is that your book will still be in print ten, fifteen, twenty years after publication. Two writers that are; two of the most influential and long-standing writers on the software process have been Fred Brooks (author of The Mythical Man-Month [Addison-Wesley 1975], the classic of software project management), and Barry Boehm (author of, amongst many other things, Software Engineering Economics [Prentice Hall 1981]) Both men are in agreement on the issue of software project management:
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. 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. SummaryImproving 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:
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
|
LISA Business Data Forum Summaries and Presentations LISA Globalization Consulting Network Webinars and TouchPoint Advisory Calls LISA Forum USA LISA@Chinasoft Fair LISA Forum Asia LISA Forum Europe LISA Forum India Open Standards • TBX • TMX |
||