Oh, Great, Another "Why Projects Fail" Article
CIO recently published another one of those “why projects fail” articles. This one is called 15 Ways to Screw Up an IT Project.
It’s the usual list — failure to define requirements, scope creep, not securing management buy-in — it’s the usual litany that we all know and love.
As a project manager I recognize all the problems mentioned here. It’s tiresome. Yet it continues to hold truth, no matter how certified, trained, or book-learned we become about this black art called “project management.”
So why haven’t we learned? I’m not completely sure. I don’t think it’s a problem that is unique to IT projects. While most of the projects I’ve been involved with have had a strong technology, software, or database management component, they’ve always had a strong business process focus as well.
One thing I’ve noticed is that — and I don’t know if this is typical or not — the more a technology-focused project becomes involved with the business side of things, the less control an IT-oriented project manager has over the unified set of actions and outcomes that need to be orchestrated.
Management techniques that more tightly integrate the IT with non-IT staff in the delivery and review of smaller value-generating deliverables is one approach to overcoming the possibility of having things spin out of control. Unfortunately, this “divide and conquer” approach may not work on larger or more complex projects where a mix of both creative and repetitive tasks need to be controlled using different management approaches. Plus, some one in senior management is always going to be breathing down your neck for status updates about those good old standby performance criteria: cost, budget, and progress against schedule. It’s the real world.
It’s always easy to focus on “failure to define requirements and expectations” as reasons for project failure. Even if you adhere to budget and schedule and deliver on time a thing that’s not wanted or expected, you lose. It also pays to assume that things will evolve and change as you work your way through the schedule. That means you need to maintain flexibility and ongoing involvement and honesty with decisionmakers and stakeholders.
That’s good in theory but I have occasionally experienced pushback from clients who thought my projects required too much management involvement. “We hired you to manage this thing so stop bothering me and go manage it!”
Again, nothing new here. You have to assume that (a) things will change, (b) not everyone is going to have the same level of involvement and understanding as you and your core staff, and (c) problems are going to crop up along the way that require thoughtful consideration by stakeholders whether they want to be involved or not.
Welcome to project management!
Copyright (c) 2013 by Dennis D. McDonald
