Tag: Project Management

On this cheeky occasion, I would like to offer a midly-amusing comic I saw on LinkedIn recently. Sometimes (read: most of the time) this is exactly what happens during any project lifecycle. It almost feels like April Fool’s day every day, right??

how-projects-work

Til Next Time,

Michael

I am obviously far from an apologist for all things Project Management (the prevalence and blind embrace we give to PMI, PMP, every other acronym known in the project management certification universe, is sometimes rather exhausting). Lately, however, I have been analyzing the difference in mindset between a typical “project manager” and someone more sophisticated – namely a “program manager”.

To me, a project manager is like a line cook. Meticulously dedicated to the ingredients, the recipe, the steps to prepare a perfect dish. The program manager, however, is the one tasked with understanding where the line cook’s dish fits within the overall context of a meal. The project manager, in the face of adversity, will inevitably have tunnel vision. They will be derailed the moment any one thing changes (lack of availability for an ingredient, the absence of a critical cooking surface/tool, etc). The program manager, though, has the foresight and the understanding of how to make it all work, even against all odds. They understand if the patrons are vegetarian, they understand how meals must be coursed rather than served all at once. They embrace customer expectations and adapt their philosophy to fit the needs of a given situation.

Sure, I am giving program managers a little bit too much credit here. Even they can be as blinded by factors external to their tunnel as the project manager. But – the more we can start to make people think like a program manager more often (and – in doing so – understand where they fit in the grand scheme of things), the sooner we will see the macro picture instead of simply having to settle for the micro.

Til Next Time,

Michael

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

Contact

Use this form to submit information!

Name
Email
Message

Yay! Message sent.
Error! Please validate your fields.