The Seven Deadly Sins of Project Management
Peter de Jager is a provocative Speaker, Writer and Consultant. His primary focus in on how we manage change, technology and the future.
In addition to speaking at conferences worldwide, he's also writen monthly columns for CIO Magazine and Computerworld Canada.
His goal is always to question what we think is so, and in so doing perhaps open up new opportunities.
If you'd like permission to reprint any of Peter's articles, please contact him directly.
You can contact him at
pdejager@technobility.com
Or sign the Guest Book and he'll get back to you.
Every list which attempts to select the best, or the worst, of anything generates controversy. Why was that included? Why wasn’t this on the list? Why isn’t that ranked higher. Yet lists are useful because they’re an, albeit imperfect, encapsulation of knowledge. So… ignoring the inevitable controversy, why do projects fail?
I’m almost certain that Pope Gregory the Great (6th Century) never worked on an IT project, but he did formalize a useful list of Human failings known as the Seven Deadly Sins. Today we know that short list as; Pride, Envy, Gluttony, Lust, Anger, Greed and Sloth. Should we be surprised to find that this list has some relevance, even if tongue in cheek, to failed projects?
PRIDE:
From the instant a project starts, until it is accepted as either a success or failure, the best hope for successful completion is accurate and timely knowledge of project status. Trying to complete a project on time without knowing where it is, is like trying to fly a plane blindfolded. This is so obviously true that repeating it is almost pointless, yet… project after project fail because people will do
anything to avoid admitting they’re falling behind schedule. The courage to communicate early that we’ve encountered a problem is the best
defense against failure. Of course, creating a work environment where
"Courage" isn't necessary, is another option.
ENVY:
A team is a group of differently skilled people working together to achieve a common goal. Assuming this definition is sufficient (some
argue it isn’t), it points to a common problem. When people do different things to achieve a joint goal, it is
not uncommon for them to receive different rewards and benefits. If these inequities are significant, they
result in people working against each other, to the detriment of success. Why should I work as hard a Bill if my reward is less?
Reward equity is important to people.
GLUTTONY:
We like large projects, they challenge us. There’s also a tremendous amount of Ego and Reputation at risk if we reject a project. All of this is a non issue if we’re good at large projects, but
typically we’re not. We lack experience with them, we’re more familiar with average projects. In reality, sometimes good project management requires that we reject a project.
LUST:
Is there a greater flaw in the IT industry? We LOVE technology and think nothing of starting an important, crucial project using a new
shiny toys, a technology with no proven ability, a technology with which we’ve had zero experience. If this weren’t so prevalent in the industry it would be an insult to every reader to even mention it, but it is a failing of most ITers… and since we’re mostly male, it can be summed up with the female sigh of despair, “Boys and their Toys”.
ANGER:
“Project Management requires people management skills”, that statement should be obviously true. Yet if we consider
the stated reasons why people are promoted to Project Manager, we’re almost forced to believe that Project Management is a technical skill. It isn’t.
It never was. It can't be. Most, not all, new managers have little, if any, people management skills, and seldom receive training in this area. We seem to operate under the belief that if Jim can
plan, track, code, design or test etc., then Jim can manage. Many projects fail because of poor management, sometimes so poor that shouting and tantrums are used as tactics to increase productivity.
GREED:
Want to crash a project? Try to complete it on time with fewer resources than you need to complete it
on time. This is another one of those simplistic statements which should be unnecessary, but based on experience,
it isn’t stated or listened to often enough. The proper tools and resources won’t guarantee success, but they’ll make it unnecessary to constantly demand superhuman effort and personal
sacrifice in the name of profit.
SLOTH:
The most peculiar, and effective PM strategy I’ve come across, is to act as if the deadline six months away is tomorrow’s deadline. We all have a tendency to start in repose and finish in haste. Next month’s deadline tends not to become an issue until we replace ‘month’ with ‘week’, or
even worse with ‘day’. We’re all familiar with the joke that 90% of a project gets completed in the last 10% of the schedule. If we start early, then we’re putting up an impenetrable
defense against Murphy’s hordes.
Summary? While projects do fail due to technical reasons, the vast majority of failures are due to human foibles, and those are as obvious, and as easy to overcome as they were in the 6th Century.
© 2005, Peter de Jager – Guess what? Peter has a passionate, almost
obsessive, fascination with this thing called Change. If you’d like to inject some of his passion
and focus to your organization’s change management process… then contact him at
Pdejager@technobility.com
Here’s what a recent client had to say about his work;
"Peter de Jager's lunchtime keynote presentation at our Professional
Development Day was the highlight of the event. Peter's delightful sense
of humor and approach to change management had the audience captivated
for a full hour as he related every day personal experiences we all have to the
management of change in the workplace. His common sense approach and
ability to make it simple provided the audience with actionable knowledge in
a brief, but very effective presentation. I look forward to having Peter back
to present to the Southwest Ohio PMI Chapter."
Pam Nintrup, PMP, President, Southwest Ohio Chapter, PMI.
May 2005
For
reprint permissions click here.
Resources: