The Case Against: Traditional Project Management

In the interest of full disclosure, I do not have a PMP certification – so you may not think I’m the right guy to talk about this topic.  For that matter, I have no classical training in Project Management.  Sure, I have learned the ropes by living in a project management driven world since my beginnings back in college as a part-time custom software developer testing manager.  But I don’t have any certifications, degrees, or really any preferred methodology to tackle “project management”.

That being said, I have been around it enough to know that there is something about traditional project management that really bugs me.  Additionally, the concept that PMP certifications make someone a “better project manager” is farcical at best in my experiences.  Let me explain why.

Traditional project management, at its core, is not a bad thing.  It’s absolutely necessary, and delivering projects would be impossible without some form of ground rules or marching orders.  Effectively, the concept of project management is pretty simple and I believe very sound in its guiding principles (I’m taking some creative licensing with my concept of these principles, so don’t nail me if I’m overstating or miss a few):

  • Projects should have defined scope, schedule, and budget that the manager should monitor and report against
  • Projects should have a detailed work breakdown structure or project plan
  • Project plans should have clearly identified dependencies and the ability to discern critical path for project completion
  • Project managers should proactively and continually identify and mitigate risks according to a defined target date
  • Projects should engage all appropriate stakeholders (on internal teams as well as from boundary partners) and include them on project execution dialogue
  • Project managers should alert stakeholders of issues and organize the necessary parties to resolve any issues (i.e. risks that miss mitigation by deadlines)
  • Project reporting and communications should occur at defined intervals
  • Projects should have an executive steering committee and some form of governance to quickly and rationally work through any major decisions during the project lifecycle

And this all sounds great.  I don’t have an issue with it.  Where my proverbial beef comes in is when you dig a bit deeper into some of these principles.  The major risks (no pun intended) I see with these guidelines is that they can very easily lead to poor execution based upon the “hiccups” that happen.  For instance, just a few of the speed bumps that projects run into which are extremely difficult to navigate because traditional project management ignorantly expects only sunny day scenarios:

  • Scope, schedule, and budget are all forecasted at some point in time with only a minor portion of the information available; hence, it should be expected that these “forecasts” will prove wrong in at least one of the areas at some point in the project – and that shouldn’t be a bad thing (but too often is a major indictment to the manager or the whole team)
  • Dependencies are a beast and should never be reduced simply to a line in a project plan; as much as you plan for them – the fact is you are handcuffed to someone else, an external process, or something totally out of your control
  • Project plans, when managed diligently, leave project managers with no capacity to think about the “bigger picture”; the inability to step back and look at the plan from the outside often leads teams to continue towards “the plan” when in reality – the plan may very well need to change because of several factors (new business direction, corporate strategy differences, or updated market/financial dynamics)
  • Along the lines of scope/schedule/budget/status/project plans – people resent status monkeys; when you reduce the project manager to being a status monkey that is responsible for organizing a whole team’s worth of updates on individual project line items, you are not using that manager to their full potential (and are turning them into an administrator for electronic information aggregation – something these computers we have do quite well already without a human behind the keys)
  • Project reporting and communications get stale and people become numb to them; the real challenge is to define a cadence where everyone gets timely and pertinent information for them – the right people get the right information at the right time to act upon it
  • Most executive steering committees are not engaged in the right situations to earn their keep; executive steering is one of the most important components for any major project because at least once, you should expect to have to engage them for a very important decision (e.g. delaying a launch, limiting scope, requesting more budget)
  • Change Management is almost always afterthought for the “project team” (even in the projects where it is assumed/expected that Change Management will be executed by project personnel); the inability to proactively manage change implications and promote awareness across the whole corporation for major changes is an area where I see projects turn South far too often because the critical change functions are simply a line item in a thousand-line project plan
  • ^Speaking of, thousand-line project plans make projects too black-and-white; if everything is just a check box, how easy is it to just go off into a dark room and check the box?  (answer: way too easy, and the results usually reflect the quality you’d expect by someone doing something just to check a box)

I’ll put it a different way…  You’ve probably heard it before: everything that can go wrong will go wrong.  I’m not trying to keep this post overly pessimistic, but it amazes me when I so often see managers encounter a road block and get paralyzed by their inability to react to the situation.  It’s almost as if they didn’t see it coming.

Maybe I’m jaded.  Maybe I have been on too many projects that weren’t set up for success from the start.  There’s one thing I have observed over time though – great managers aren’t great managers because they deliver in good times.  When the going’s good, everyone’s an all star.  Rather, they’re good managers because they manage the hell out of difficult times.  And, if you don’t expect that some things can (and will) go wrong, you are less likely to be able to course correct, employ contingency plans, or dig out of the ditch.

I don’t have anything empirically against the PMP types and traditional project management.  I just feel like they are touted a bit too much as being some form of end-all be-all.  It’s about time we revisited project management excellence and realized that we should probably develop a specialized construct for each situation (given the corporate landscape, project complexity, amount of time/energy available from resources) in order to prepare for project delivery success.  I have always hated trying to put a “one size fits all” approach on to any situation*.  It’s not fair to anyone involved and is blatantly ignorant to the uniqueness and intricacies that will always be present from project to project.  We are living in a digital/social age.  People will tell you immediately what they had for lunch on Facebook.  Why can’t we turn that active engagement into something useful to help with project delivery?  Maybe it’s better collaboration tools, maybe it’s gamification of project delivery – I don’t know.  But we need to make a change.

*On that note, I promise a “Case Against” post soon for stock methodologies, generic templates, and “reusable” processes.  I’m sure you can guess my opinion.

Til Next Time,

Michael