The Hard-Nosed Project Manager

The PMP designation and PM competency

I never believed that holding a PMP designation was proof of a project manager’s competency but I must say I am growing disenchanted with what I see these days on various PM related web sites, LinkedIn groups, and in my professional life.  A few examples:

• PM sticks tasks into his schedules based on duration only.  No attempt at setting the level of effort of individual resources for those tasks.  Wonders why he can’t level his schedule.
• PM does not know what WBS means.
• PM can’t read a schedule.  What is a predecessor or successor, what is started, etc.

We are not talking here of a lack of familiarity with specific tools but rather with basic project management concepts.  These shortcomings could be excused and even understood in the case of an accidental PM but not in the case of someone who, prior to getting tested for the PMP, had to document “Minimum three years/36 months unique non-overlapping professional project management experience during which at least 4,500 hours were spent leading and directing project tasks”.  Even worse; the examples listed above do not relate to a single individual.

Something is seriously wrong here…

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Agile; still not convinced

Today I was listening in on a PMI Agile CoP webinar entitled "Beyond Scope, Schedule, and Cost: Rethinking Performance".  I do try to broaden my horizons...

I must say that I am still not convinced that Agile is that different from other iterative approaches.  Actually, at some point, the speaker adopted RUP terminology and if you had just joined in you'd have been confused. 

Much of the argumentation was anecdotal; for example:

• Claiming that Agile yielded an 89% improvement (decrease) in the number of defects over the "traditional" approach is great but when you mention that the organization was apparently 4 times over the average for its industry you could say that the problem lied somewhere outside of the methodology.
• Claiming that a Gantt chart is not as good as a Parking Lot chart is not comparing apples to apples if when the deliverables are not the same.  Comparing a crappy Gantt to a good Parking Lot is a weak argument.
• The fact that some projects fail due to feature bloat is not news.  Using Agile (or RUP, or something else) does not by itself fix that issue.  The "traditional" approach did not cause that problem either.

Making claims from a position of authority does not win debates, it speaks mostly to those who are already believers and it may create in others the perception that the claims cannot stand on their own.  

Using a different vocabulary to talk about the same or equivalent concepts is not enough to create buy in for Agile.  For example, Story Points vs. $ is at some level similar to $ vs. Euros; all we are talking about here is currency conversion.  What if, from now, all projects Agile or not used goats as their currency?  Would that make Agile better or worse than the "traditional" approach?

I'm still open minded about this subject but still not convinced.  What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Run, don’t walk (or crawl)!

Yeah, I know, it should be the other way around; but often it is not.  Why people or companies try to start any endeavour directly at the top instead of progressing from their current level evades me.  In project management you often see this with PMOs or Enterprise Project Management (EPM).

Enterprises get into a mad rush to create one or many PMOs when, up to that moment, they had never thought of actually managing projects or of having any type of processes however simple.  Suddenly an Encyclopaedia Britannica sized manual lands on your desk and every newly christened PM must abide by all of its teachings.  The reality is that typically these new processes are ill formed, ill fitting, and bypassed as much as possible.  Of course processes evolve on a weekly basis. 

The PMO craze has been going on for years now and in many organizations is in its Nth incarnation.  PMOs are not useless unless you design them to be that way.

EPM is the newer craze but in many regards follow the same path as PMOs.  I know of an organization where, up to very recently, no schedules where ever prepared yet they have gone whole hog on EPM.  You have to prepare a schedule, upload it, and maintain it.  Simple, no?  Maybe, maybe not:

• You are told not to put too many tasks in your schedule (nothing below deliverables).  When you contradict that edict with a whopping 700 tasks for a 6 month, 10 person project you find out why; the poor server can barely load, save, and publish something that size.  Forget resource levelling; my laptop is more powerful.
• In total contradiction with the prior directive, schedules are treated like a collection of post it notes.  Everything that comes to mind is now required to go into the schedule.
• In total contradiction with the prior directive everything that your sponsor does not want to explain must be taken out of the schedule even if doing so deletes predecessors or successors.  You can always add them later!
• You must stick to the original end date regardless of delays, scope changes, resource shortages, or whatever else happens.
• When you ask for the WBS field to be part of the enterprise template you are asked by the EPM administrator if you mean Work Breakdown Structure.  What else the freaking hell could I mean?  You are then told that you have to wait for a meeting of the steering committee to find out if adding your field will be allowed.  Something tells me that no one on that committee has ever run a project.
• You are told that you need to update a traffic light status based on earned value metrics but promptly find out that none of the EV related fields are visible.  I guess I’m supposed to go to that steering committee for that too.  By the way I found out that the traffic lights are not linked to EV anyway; they are set by hands and there are no guidelines for setting them.  All green anyone?

I guess that, if you insist on jumping off a plainly visible cliff, you may as well run and be out of your misery sooner instead of inching up to it.

What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Leading by setting stretch goals

One of the points I should have made in my previous post on leadership was that you grow your replacements by setting stretch goals for them.  Setting stretch goals does not apply only to leadership roles but also to all project team members. 

Planning and estimating are activities that many would love to offload onto the PM; the problem becomes how do you train the next PM?  Here are a few examples of stretch goals around planning and estimating:

• When a new Request for Proposal (RFP) is received; distribute it to a few potential or new technical leaders or project managers. Give them a reasonable but not generous amount of time to individually derive a list of deliverables and a WBS.

• Convene everyone to compare, organize, and harmonize the results of the WBS round. Give everyone a reasonable amount of time to individually derive a list of tasks and efforts related to the deliverables identified in the harmonized WBS.

• Convene everyone to compare, organize, and harmonize the results of the task and effort round. Give everyone a reasonable amount of time to individually set constraints and dependencies for the tasks identified in the harmonized task list.

As you go through the exercise observe every participant’s behaviour.  Look for signs that individual participants appear to be lost, uninterested, or not participating in meeting.  Address issues as they come along, offering help and encouragement as needed.  Do not allow participant to give up on the exercise.

You can expect wildly different outputs from each individual at each step of the exercise.  You may reveal hidden talents and you are almost certain to foster a feeling of commitment in all participants.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Do we need accurate estimates?

You bet your life you do and you should involve as many people as possible developing one.  If you do get that accurate estimate you will enjoy, in no particular order, the following benefits:

• Focus on the deliverables; hopefully you started with a WBS. Are the task in the estimate directly related to the deliverables or are we gold plating?

• Buy-in from your team members and management. It is not YOUR estimate anymore, it is EVERYONE’s estimate.

• You can run a Monte Carlo simulation to figure out the realistic end date instead of the optimistic one. It is pretty amazing how both values may differ.

• You’ll have identified the training and staffing needs you’ll have if this project becomes part of your portfolio.

• A strong basis for contractual negotiations. Now your sales force knows how much you think this will cost and why.

• If the client says you are too high by X your sales people can ask what can be dropped from scope.

• If your company wants the project to satisfy both its Balanced Score Card financial and customer objectives we now know how many hours we may agree to give away to gain a new client or keep an old one. Remember; do not drop the rate, give hours away instead.

• Faster response time when revising your estimate following scope changes. You already have figures out where you can cut. If the client doesn’t volunteer potential areas of scope reduction you probably have identified them already.

• You’ll have a good starting point for the next time a similar project crops up.

Of course you’ll only know how accurate you were after you get the project and you deliver on it…

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.