The Hard-Nosed Project Manager

A believable plan

As I was catching up on my reading I landed on The Late Finish Strategy by Glen Alleman.  I find that reading his posts usually make me think, sometimes make me smile, and that linking to them make people believe that I’m not that dumb after all…  Often times Glen’s post are about those common sense things that, for some reason, end up being neglected.  Things like knowing what you are trying to deliver or having a believable plan.

In this post he talks about the need for budget and schedule margins.  Most of the time you are not given margins; your team has to fight hard to build them up.  Most of the time you look at your schedule and there is a sea of red tasks; the critical path extends from project beginning to project end with no break.  To state the obvious; if your schedule does not have any slack, it’s not that you MAY get in trouble, you ARE in trouble.

Now, if you are blessed with some slack in your project schedule you are not out of the woods yet.  As the old saying goes: ”How does a project end up late? One day at a time…”  So, however you got that slack, you have to fight tooth and nail to avoid seeing it disappear.  You likely won’t be able to end with all the slack you started with or all the slack you managed to build up but you just can’t give it away or you’ll end up being the meat in a “rock and a hard place” sandwich.  This situation can happen real fast or creep up on you but the result is the same; pain.

I’ll add to Glen’s post that on top of a budget margin and of a schedule margin you also need a personnel margin.  What good are schedule and budget margins if you don’t have the personnel to do the work?  I contend that like for budget and schedule you need a personnel margin.  Why?  Here are a few scenarios were that margin would be useful:

• Your resources are “potentially overcommitted” due to their name or skills being linked to numerous proposals or future projects.  Don’t you love “do not substitute” clauses in contracts?
• You work in a matrix environment, your resources are on “loan”, and the loan is being called.
• Your resources are committed to more than one project and the other project manager (not you of course) dropped the ball, his project is in trouble and he is sucking all available resources.
• Your resources are committed to more than one project, business priorities change and your resources end up overcommitted.  Multitasking and overtime are taking their toll.

Once again, if your schedule does not have any slack, it’s not that you MAY get in trouble, you ARE in trouble.  You must have slack in your schedule, budget, and resources or you plan is not believable and you have to stop lying to yourself and others.

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. 

Kill, kill, kill

No, I’m not angry and no, I’m not going postal.  Anyway, we don’t have weapons up here in Canada.  Do you need a chief killing officer? is the title of an article I read a couple of day ago in The Globe and Mail.

The main premise of the article is that you need to clear out the clutter, the accumulated baggage.  And that applies to products, product features, people, standing (as in regular) meetings, reports, investors (partners), processes, HR practices, and software code.  Give it a little thought and I’m sure you can’t find other things that are in need of a good pruning; for example the project that doesn’t end and for which all hopes of an ROI have long since evaporated.

A couple of anecdote that illustrate the topic:

• In Steve McConnell’s book Code Complete he mentions the case of a lady who cuts the ends of a roast before cooking it.  She does that because he mom did it and mom did it because grandma did it too.  Looks like a best practice to me…  Eventually the lady asks grandma why she used to cut the ends of the roast; grandma’s answer?  Because my roasting pan was not big enough.  As I said, looks like a best practice to me…  

• A couple of years ago I took a couple of courses with Dr. Harold Kerzner.  Let me go in a tangent to say that it feels pretty good when a guy with 40+ years of project management says the things that you think about in your little corner of the world.  Anyway, Dr. Kerzner was advocating periodically weeding out best practices libraries and doing the same with project portfolios.  That sounds like a job for the CKO although the tendency is for project manager to reuse best practices and fight to complete their projects at all cost.  I don’t advocate giving up easy but you don’t want to have your own “Charge of the Light Brigade”; somehow the cry of “For the glory of project management” does nothing for

Now, I’ve always said that I didn’t want to be a CxO; I’d rather be a NOO (that’s a NO O), but I might just change my mind.  Elect me Chief Killing Officer; I promise to be ruthless…

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.

Stick to your guns

Have you ever had a stakeholder that had a knack for getting people on the defensive?  I once took over a project that was in deep trouble because scope concessions had been made without a proper analysis of the impact of the change on the schedule and budget.  That project was now in crisis mode and the stakeholder was using the weekly progress (what progress?) meeting to attack the current project management staff.  That person was so good at getting under people’s skin that the meeting would turn into a shouting match within minutes.  This was amplified by the stakeholder insisting on a set of topics to be discussed and the project management staff not complying.

When I took that project over I decided to do two things and to never move from that decision:

• First thing was to use the same tactic that allows a young soldier to survive a stark raving lunatic maniac aka his drill instructor. What you need to do is have a master interlock that paralyses your mouth while being yelled at. It helps if you have a little voice in your head that yells back at the abusive moron.

• The second thing was to stick to the list of topics that had been requested and agreed upon. Every time the stakeholder would try to move to something that was not on the list I would obstinately resume my briefing from that list.

Eventually the stakeholder from hell got tired of not being able to get under my skin and “delegated” the meeting to someone who truly wanted to work at resolving the project’s problems.  It took time but we got to the end of it.  Moral of the story?  Stick to your guns.

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.

Quotes worth NOT living by

Every organization is perfectly aligned to get the results it gets.

 - Stephen Covey

94% of the problems in organizations are due to bad systems and structures – not bad people.

 - W. Edwards Deming

Insanity is doing the same thing over and over again & expecting different results. 

- Albert Einstein

Any of these ring a bell?  If you end up with a result you did not want or expect you have to seriously question your approach:

• Did you set yourself up for that result?
• Do you blame the person or the process/method that was employed?
• Are you repeatedly getting less than stellar results?

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.

Chaotic numbers

I found a new (for me) project management blog called Scope crêpe by Rich Maltzman and as I was getting caught up with this blog I encountered 2 posts about project success rate.  The first one provides some statistics from an issue of PM Network while the second is about the CHAOS report.

You may recall a post I made on the same subject.  In it I grouped together the CHAOS report’s “failed” and “challenged” numbers.   Interestingly enough the percentage of successful projects according to the CHAOS report is much lower (by about 20%) than in the PMI numbers.  The spread increases for organisations with a high level of project management maturity.

I’m not sure how to interpret this spread between PMI and CHAOS numbers.  If I were to guess (and I am) I’d say that CHAOS has a higher percentage of IT projects and that drives their success numbers down.

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.

Team stress, team morale

Over the last 20+ years I’ve been on a number of high stress projects acting either as a team member, technical lead, or project manager.  The amount of stress varies with your role but how you react to stress depends solely on you.  Just don’t deny that there is stress.

The not so funny thing about stress is that it can propagate and amplify.  It can propagate within the project team, potentially impacting individual and team morale.  It can propagate outside the team to other stakeholders.  If those stakeholders are the family of the team members, stress will ratchet even higher with an almost certain impact on morale.  Deal with the stress deals with the morale.

In one of my early posts I suggested that forming teams and reusing those teams was better than forming a team for the purpose of a project.  This opinion comes from my time in the military where stress is always in the background.  The benefit of a long lived team is that you know each other, your limits, your weaknesses, and your strengths.  This constitutes a great advantage in combating stress and morale problems.  Two anecdotes:

• Teams develop their own brand of humor that can be used to defeat stress. The chief instructor on my basic Combat Engineer course, Sergeant Nickels (nicknamed The Big 5¢), had a saying “If you can’t laugh anymore; then it’s War!” as in War is Hell. Laugh about it repeatedly and it’ll help coping; I’ve done so with clients and colleagues and after saying “But at least we are having fun!” 15,000 times or more pain goes away.

• Remember that the problem is a project problem; don’t make it personal. Sergeant Nickels used to say “If you screw your buddies, then it’s War!” as in now you have a new enemy.  Like you needed that!

Moral of the story; deflect the stress by laughing about it with your team buddies instead of turning them against you.  Teams win.

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.

CHAOS theory

Glen Alleman’s post on the Standish Group CHAOS Reports documents nicely many of the weaknesses of those reports.  Having only three categories doesn’t provide enough granularity, fuzzy definitions for these categories, no access to the base data, small sample sizes, etc. 

You also have to consider that the Standish Group is a commercial concern and that shielding their data and presenting it in a way that is advantageous for them can be expected.  We are not dealing with a not for profit research group subject to peer review.

Just for kicks I built the following chart by grouping all the “failed” and “challenged” together from all the CHAOS report information I could find on the web.  I’m assuming that the CHAOS report methodology has been constant over the years (was it?).  Even with a built in bias you see that both groups flat line over time.

 

My own definition of success is no more that 10% off on cost, no more that 10% off on duration, and no significant scope reduction.  By that definition, and based on my experience, I’d say that the same conclusion holds true; the success rate has flat lined over the years.  Whatever that success rate happens to be.  Why is that so?  Here is my personal CHAOS theory; no butterfly wings required:

• Requirements are fuzzy, often documented out of context and not tied to deliverables. See this previous post. If you don’t know what you are delivering how would you when and for how much?

• All requirements are deemed equal. No consideration is given to a must have/nice to have classification. If a particular requirement addresses a seldom encountered condition or action is it that important? I believe that the Pareto principle applies here and that 20% of requirements cause 80% of the cost. Why not implement only the true essential requirements; saving costs and complexity?

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.

Have you ever been architected? ...

... I have.  (Sung to the tune of Jimi Hendrix's 1967 track "Are you experienced?")

First let me say that this post does not intend to take shots and enterprise architects or business analysts; we are all in this together.  The aim is to comment on a possible cause for typical complaints with software projects: stakeholders do not get what they expected, when they expected it, and for the price agreed upon.  As a corollary, the software services provider does not make the expected profit.  No one is happy. 

Here is how the story unfolds:

• As the bidder, you get to estimate a project based on a Request For Proposal (RFP) package. This package contains all kinds of information about the client, the stakeholders, the bidding rules, and the requirements. Often the package is fairly vague about deliverables; this is the root cause of the problem.
• Whoever put the RFP together spent a lot of time discussing needs with stakeholders and extracting requirements from those needs. During this process a list of deliverables, think WBS, was discussed. Believe it or not, in some industries the WBS is included in the package, becomes the basis for a fixed cost bid, and later, for progress and financial reporting.
• Stakeholders would have legitimate expectations of having their needs met but they will be disappointed; the “What does done looks like?” question about deliverables was asked but the answer was not properly documented and the bidder is in the dark. The bid package has descended into the minutia of requirements disconnected from deliverables. This is equivalent to ordering a bunch of building supplies (the tasks/features/requirements) but expecting delivery of a bungalow (deliverables); how do the parts relate to the whole? What is the likelihood of satisfaction?
• In response to the RFP you come up with a cost estimate and tentative schedule. Because of the missing deliverables a time and material approach may be suggested even if a fixed cost was requested; this will likely be rejected but, if not, there is a high likelihood of recrimination later in the project.
• The bidder may be told that he is too expensive and/or that delivery is too late. A phased approach may be suggested to clarify the deliverables (time and material phase) and refine the schedule and cost estimate; this is also likely be rejected as it will appear to redo work already performed by the client.

There are ways to avoid or mitigate the problem and its impact:

• You get to engage with the client early on and work as a trusted advisor while the RFP is being created. This may mean that you are not allowed to bid to avoid an apparent conflict of interest.
• Strict gates are applied to prevent the project from moving forward without agreeing that what is being developed is what was envisioned.
• Both parties get ready for very strict scope control.

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.