pmStudent

Recently there has been some heated debate about the value of the MPM Certification.

From time to time I learn about new programs that I've never heard of before.  Sometimes they are valid start-up certifications, and sometimes I find them to be dubious.

Certification Red Flags

• The entry requirements are usually very low (there are so many exclusions on their website, almost anyone with any PM experience or education meets them)
• To get them you just need to fill out some paperwork and send some money in
• Renewal fee in order to ‘maintain’ your credential (every 2 years in the case of MPM)

I think this is more like a club than a credential.

Seriously

In order for me to take a credential seriously, it has to either:

• Test knowledge of a SPECIFIC standard(preferably ISO, IEEE, etc. like PMP, PRINCE2) AND require experience verification.
• Verify and validate competence in practice such as some of the IPMA/asapm credentials.

That is my honest opinion on the matter.  What do you think?

Like this? Share it!

I bet you didn't know it, but Wile E. was a project manager.

A specific breed of project manager.

So what lessons can we learn from our friend Wile E.? What made him so special?

Super Genius

You may remember, he preferred to use fantastic (and usually absurd) contraptions and elaborate plans to pursue his quarry.

His primary supplier was Acme Corporation, from which he procured complicated and usually ludicrous devices in the constant pursuit of success.

Two things usually happened with these devices upon implementation:

• The devices fail in spectacular ways (Kablooie!)
• The devices work, but operator error results in failure (Splat!)

But Why?

Why did our hero continuously end up smashed, blown up, or with a difference of opinion with gravity off a high ledge?

Like the time where Wile E. procured the Dehydrated Boulder, and then it became much larger than expected and crushed him?

Or the time he donned the Bat-Man outfit thinking it would make him fly, and it didn't live up to his expectations?

Teach Us, Mr. Coyote

So what do I mean, he wasn't a project manager, right?

No, not really. But he reminds me of many I know.

Wile E. Coyote relied on gadgets and tools, all of which either:

• Didn't work
• Worked too well
• Didn't fit his needs
• He didn't know how to use
• Introduced unnecessary risks

So thank you Wile E. for being the Tim Allen for my own project management career. You've taught me:

• Simpler is better
• Do only what adds value
• An ounce of execution is worth a pound of whiz-bang software
• No single solution fits all needs
• Risk management is freak'n important

So, what has Wile E. Coyote taught you? Leave a comment and let us know.

Like this? Share it!

I recently reached out to my PM Career Coaching group and asked them:

"What is the 1 thing that if you knew how to do it or do it better, it would make a dramatic impact on your life and project management career?"

Steve's response

"Hi Josh

If I could do one thing better consistently is to learn to delegate more, I find that although I do delegate I still end up doing the lions share of the work, which then has a direct effect on the overall project monitoring.

Delegate Results, Not Tasks

Many times, the failure of delegation comes about as a direct consequence of project managers micromanaging tasks.

• Give them the end goal and some high-level direction
• Get out of the way and let them decide HOW to carry it out

You'll see better results and a more empowered project staff.  Most people are smart and want to do good work.  Demonstrate your trust in them in a tangible manner and you'll be pleasantly surprised by the results in most cases.

Delegate Clearly

When I said ealier to "give them the end goal and some high-level direction" I meant also that you need to be crystal clear about it.  So many of these well-intentioned and hard working people produce results that are other than what you intended.

But it's not their fault.  It's yours most of the time.

People will tend to make assumptions when they aren't completely clear, because they feel asing questions about your direction or end goal might make them look stupid.  It's up to you as the project manager to be crystal clear about what the end result should look like.  Have them articulate it back to you, and on longer tasks check in just to see how they are doing.  Don't micro-manage, but use opportunities for feedback from you to them as a way to course correct along the way.  In this scenario, they are the producers and you are the "customer" of that delegated deliverable, so get a little agile with it.

What advice do you have for Steve and others regarding delegation?

Like this? Share it!

I help new and aspiring project managers with their careers. Part of what I teach is logistics; the tools and techniques involved with project management itself, and building a career for yourself.

There's another very important piece of the puzzle I teach as well.

Mindset

A great career requires ambition. It requires the courage to take educated risks in order to create and take advantage of opportunities. It involves creating opportunities for yourself.

From time to time, students I coach come at me with language such as the following:

• “If only they would”
• “They never let me”
• “I asked but they didn't do anything”

Let's get one thing straight.

No One Owes You Anything

It's up to you to make opportunities happen for yourself. In my experience, the best way to get what you want is to help other people get what they want. Additionally, the reciprocation must not be explicit; they still don't owe you anything.

If you don't want to genuinely help other people get what they want, you won't be very successful in most cases. The stereotype of power-crazy professionals who will step on anyone to get what they want just doesn't work. You may win some short-term battles, but wars are won by people who understand the value of those around them.

When you help people enough that they WANT to help you, you are leading. You are creating the kind of social capital that is the fuel which will drive your career prospects.

So be the spark for people around you. Help them to get what they want, and your own goals will be reinforced from all of the fantastic flames you help around you. Be the one who people remember when it counts, because they genuinely appreciate the effort you expended on their behalf, time and time again.

Be a Fire Starter.

Like this? Share it!

The concept of a Project Management Plan has been defined and implemented in various ways.

For example, I've heard project managers refer to their MS Project file as their "Project Management Plan".  (I'm not even going to go there....if I start on that, I'll go on a rant about how that's so bad, it's not even wrong.)

I have also seen it implemented in such a way that it attempts to capture all of the scope, cost, and schedule and other related artifacts.

It turned out to be a huge pile of paperwork, with lots of effort to compile it, only to never be seen again.

It was useless.  Why?

It Didn't Add Value

The only reason for a document to exist on your project is to add value.  If it's not dynamic enough to be modified quickly by a lean change management process, it's going to die and go to artifact heaven (or hell).

One of the best ways to ensure something doesn't add value is to make it a redundant copy of something else that already exists.  In this case, there were already all of the artifacts outside of this "Project Management Plan" that were the REAL documentation, the real baseline for the project.

So What Should a Project Management Plan Be Then?

I'm glad you asked.

A Project Management Plan should be the defining document for HOW the project will be managed.  No more, no less.

It's the documentation of your project management methodology.  You can hand it to a stakeholder or customer and they will be able to read it and understand how the project is run.  When processes need to change, they should be updated in the plan.  A new employee joins the project?  Reading the Project Mangement Plan will orient them to "how things work around here."  Not WHAT we're doing, but HOW we are going about it.

Here are some critical areas to be sure your Project Management Plan covers:

• How are Changes managed?
• How is Scope planned and managed?
• How is Cost estimated and how are Budgets set?
• How is Schedule set, managed, and reported?
• How are Staffing considerations handled?
• How will Communication be effectively facilitated?
• How will Risks be identified and managed?
• How are Procurements to be handled?

You'll notice these line up pretty well with the PMBOK Knowledge Areas.  I tend to call out change/configuration management as it's own knowledge area, because it's so important and so poorly done on many projects.

So, that's my experience of what a Project Management Plan should be in order to add value to your projects.  I found this article here on Gantthead which agrees with my take on the plan.  Some of you may disagree with my approach.  I'd love to hear your arguments for alternative approaches in the comments.