The A-Z of Project Management Survivial » P

P is for… Procrastination

MorFF — Sun, 04 Jan 2009 23:00:00 +0000

There is a school of thought that is rife amongst the more timid of the lesser spotted Project Manager, and that is that if you ignore something for long enough, it will go away.

While this may be true for such things as his acne and his girlfriend, it is generally never true about software projects. If you ignore a small thing long enough, it will become a big thing and when it becomes a big thing, you are more likely to feel the pain.

Of course, if you know what you’re doing you will be aware of even the small things on your project and will make a conscious decision on whether you should do something about it sharpish or you can safely let it ride for a while.

What you do about it will, of course, depend on the issue and your own personal style but be sure you do something and don’t just defer the decision till tomorrow. Tomorrow will have enough challenges of its own.

P is for… People (part 1)

MorFF — Mon, 06 Aug 2007 20:24:00 +0000

Now we’re getting to the meat.

Cobb’s Paradox:

“We know why projects fail, we know how to prevent their failure
-so why do they still fail?”

Martin Cobb Treasury Board of Canada Secretariat

Since 1994 the Standish Group have been producing their Chaos Report. This project “ exposes the overwhelming failure of IT application development projects in today’s MIS environment”

From the 1994 report we can see the core reasons for failure: The factors that cause projects to be challenged were:

Project Challenged Factors	% of Responses
1. Lack of User Input	12.8%
2. Incomplete Requirements & Specifications	12.3%
3. Changing Requirements & Specifications	11.8%
4. Lack of Executive Support	7.5%
5. Technology Incompetence	7.0%
6. Lack of Resources	6.4%
7. Unrealistic Expectations	5.9%
8. Unclear Objectives	5.3%
9. Unrealistic Time Frames	4.3%
10. New Technology	3.7%
Other	23.0%

So, what conclusions can be drawn from these many years of research? One broad message is that, despite all the years of innovation and experience that have passed, as Cobb’s paradox suggests, nothing much has changed. What was problem a decade ago is still a problem now. Despite tools, techniques methodologies aplenty, projects still fail and for the same broad set of reasons.

This research clearly points at the major issues in project failure and with consistent results over so many projects over so many years it would seem entirely incontrovertible. There is a common thread in all the results that is concealed behind the detail. At the heart of all project failure is the people. This may seem obvious, after all, projects are conceived by, designed by, built by and used by people. It is clear that this human factor can never be removed from projects but, by understanding the nature of the influence of people on a project, certain key failure points can be targeted and improvements made. At least in part, this is perhaps at least part of the answer to the paradoxical question ‘so why do they still fail?’.

All the great processes and tools cannot make up for the fact that people are at the core of everything we try to do, and if the people aren’t up to it then there isn’t an awful lot you can do about it. Except to look for a saviour.

What this all points at is that there is only one thing you need to get right. Get the right people on your project. You do this by either getting your recruitment right or, within the existing resource pool, making sure you grab the good ones.

The quality of the people at the start of the project sets the upper limit of how well everything can go before all the usual stuff starts to go wrong.

Everything, EVERYTHING you try to do is based on and reliant on people. Get good ones, make sure they are happy, give them space and let them do their thing.

P is for… Pragmatism

MorFF — Mon, 16 Jul 2007 15:02:00 +0000

As discussed previously, one of the most useful tools in the armoury of the Project Manager is common sense. This, coupled with a healthy dose of pragmatism will help you deliver projects that work.

Take a look at your project. No, not your Microsoft Project Plan, that’s not your project, that’s your plan. Take a look at the project, the objectives, the requirements, the timeline, the resources, the environment, the dependencies, the risks, the issues, the external factors, the team structure, all of these things. Now, ask yourself some questions: “is this the best way to do this?”, “is this the right way to do this?”, and the most important one, “will my project deliver?”

Just because the manual or somebody else in your organisation says you should to do it a certain way does not mean that is the right way for your project. Take the pragmatic view, do what needs to be done to deliver the project.