The Hard-Nosed Project Manager

Integration of Earned Value and Risk Management webinar

Today I finally listened to the recording of the PMI Risk Management CoP webinar called Integration of Earned Value and Risk Management.

Glen Alleman issued his own comments previously, here are mine.

I am in a situation that is somewhat different from the one discussed in the webinar.  I typically don't work on fixed cost projects so I do my own risk management activities.  My clients do theirs; I do communicate my risk assessment to clients.  The Management Reserve (MR) is invisible to me until a risk turns into an issue that requires funds to mitigate.  The size of the MR is actually unknown to me.  Same goes with any slack they built in after the deadlines they communicate to me.

Given that, if a risk does not materialize or if it is mitigated using the existing budget (with or without drawing on the MR), what is left is returned to the pot for use at a later date (or not).  Same goes with any slack in the schedule.

I would add a Work Package (WP) to the schedule only if the risk, now an issue, involved a missing deliverable.  Otherwise, tasks would be added to an existing work package and to the schedule.  In either case the MR might get drawn down and Earned Value (EV) affected.  If I deliver more value to the project, as opposed to fixing an unforeseen issue, more value is being delivered and that offsets the potential change is cost.

Although it does not happen in my projects; if a risk does not occur, I don't see how leaving the associated funds (or slack) in the PMB would improve performance.  If I read Glen's comments accurately, we are on the same page.  No deliverable equals no value and keeping the extra funds in the calculation would mess up EV.  Same with any extra slack; no issues does not mean you get free slack.

I liked the answer on the use of Monte Carlo simulation in risk management.  Limiting the Monte Carlo simulation to the tasks on the critical path is dangerous in my opinion.  You could have significant changes in the critical path of a schedule depending on the varying work durations during the simulation.

I would also not say that the MR is for "unknowns unknowns" in the schedule.  A bit too Donald Rumsfeld for my taste and also a bit too restrictive in my opinion.

Overall it was an interesting webinar because it gives some insight on how grown ups manage projects.  If a risk become an issue you keep on using good project management practices instead of watching the wheels fall off the cart.  I also liked that there was not too much material for the hour and that the presenter did not have to race through the presentation.

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.

Does Risk Management have a place in an Agile Lifecycle webinar

Today I listened to the PMI Agile CoP webinar called Does Risk Management have a place in an Agile Lifecycle.

 They introduced agile risk management as an alternative to "traditional" risk management.  They reviewed the "traditional" approach and then the Agile approach. 

Traditional approach:

• Identify the risks
• Estimate the Impact
• Estimate the likelihood
• Calculate the risk rating = impact * likelihood
• Categorize
• Decide on how to react to the risk
• Done once in a project.  Really?  Look at their slide 17 for more pearls like this one.

The Agile approach:

• Same beginning.
• Do life risk management throughout the project.  Now that is new!
• Be collaborative. Newer!!
• Involve the client.  Newest!!!

The lady presenter backtracked a little when she said that there is bad and good "traditional" but then continued without saying there can be good and bad Agile too.  Is Agile perfect?  There are no crappy Agile risk management.  I say BS.

The guy presenter go to taking about percent complete and risk.  Agile is a binary thing; done or not.  None of that 99% done and the 1% takes forever.  Who works like that in "traditional" project management and gets results?  I do % complete on a macro level; for example, my project is 53% done, at 50% of its budget.  Clients love that while they usually don't care about individual tasks (nor should they).

The guy presenter then goes on to say that you should do "traditional" risk management when there are big upfront risks because the project is very innovative, experimental, or you're out of your comfort zone.  I don't know, but I don't start a project for making chocolate chip cookies.  My clients do not hire me to do what they could do themselves with their eyes closed and their hands tied behind their backs.

I'm an old ape.  When someone states the obvious and what a good project manager would do on projects and tells me its new, I think they think I am a fool.  Maybe I should rename this blog "The Agile Hard-nosed Project Manager".  Same old, same old but it would appear to be new and shiny.  As a plus I'd get to make even more borderline pronouncements...

Good thing that the webinar format used did not allow live interactions.  There would have been a hell of a shouting match I think.  The webinar finished 7 minutes early.  Thank God!

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.

PMI Project Risk Management CoP webinar 12/19 - Integrating Earned Value with Risk Management

There will be a PMI Project Risk Management CoP webinar titled “Integrating Earn Value with Risk Management" on  12/19at 12h00 Eastern.  This subject is very interesting and was the subject of a post by Glen Alleman.

I won’t be able to attend due to other commitments but will review the recording when it becomes available.

Focus on the Management of Uncertainty and Risk webinar

Today I listened to the PMI Risk CoP webinar on Focus on the Management of Uncertainty and Risk.

The presenter covered the worst offenders in risk management, in particular not looking far enough (being too conservative), not looking at opportunities (having only dark glasses), and making risk management a once a project activity.

As a corollary, some takeaways are that:

• You also need to look at the bright side of risk management and at opportunities.
• You need to look deep for risks.  The tsunami in Japan proved this as three mitigation strategies (at least) failed in Fukushima.  If you use a checklist for risk management, it should be only a starting point, not the end of the effort.  If a risk cannot be mitigated, transferred, etc. it still need to be on the register or you will be blindsided.
• Be disciplined; review risk management at each team meeting without fault.

On other topic that was discussed is the confusion that often happens between risks and decision that have already been taken.  Nothing that has already been decided in a project is a risk, it may not happen; it HAS happened.  Many manager keep on monitoring their projects for things that have already happened.  That is a waste of time and the item should be moved off the risk registry.

Another way of getting in trouble is devoting the same effort to a risk with a low impact as to a risk with a high impact.  A bet the company risk should get much more of your attention.

Of course the webinar did not limit itself to these so I encourage you to listen to the recording.

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.

 

Thinking about risk

We are all aware of what is in the news this week.  Most of us can also remember previous industrial or technological disasters.  On top of that I’ve been listening to podcasts and webinars related to risk assessment and risk management.  Seems like a good topic for today.

I will not go into the current events and the rumors that are circulating in the media because part of their business model is based on sensationalism and because I am not an expert in the nuclear industry or in risk assessment and management.  In fact, in my line of work, redundant systems are few and far between.  Risk assessment revolves around business continuity and regulatory compliance and most of the risk management is procedural. 

This is very different from what takes place in large industrial systems or complex technologies.  Some examples of incidents from the past:

• The crash of a jetliner potentially caused by the failure of multiple speed sensors.  This would have sent wrong  information to the pilots and to the auto-pilot system
• The crash of a jetliner caused by the failure of multiple attitude (artificial horizon) sensors.  This caused both pilot to fight each other while trying to level the airplane.
• Shutdown of a large scale data center following loss of main power, depletion of the primary backup (UPS batteries),  and failure of the secondary backup (water in the generator’s fuel)

In all these case we are talking about failure of the primary system, its backup, and of the secondary backup.  Another aspect that gets factored in is experience (hindsight); this was very nicely presented by a NASA risk management expert that was discussing the safety history of the space shuttle program.  What she stated was that it is now clear that the risk had been underestimated.  Note that she did not state that risk assessment and management had been shoddy but that, knowing what they know now, they had underestimated risk.

The people who determine how many backup systems are needed and of what type do so based on their years of experience and on best practices derived from previous incidents.  Typically incidents do not repeat themselves exactly and future problems hit another part of the system. 

If any of the readers of this post care to explain the thought process that guides those in charge of risk assessment and management of complex industrial or technological system I would be grateful to them.  I would also like if someone could point out reference material (books, articles, websites) on the subject.

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.

Risk management; no rose colored glasses please

We are all sadly aware of the situation with the oil leak in the Gulf of Mexico.  I am certain that after the leak is plugged, the cleanup is completed, and the finger pointing is over, we’ll find out that proper risk management would have minimized the damage.  Maybe we can even learn from this although I doubt it.

I am not an oil platform expert but listening to a Chevron representative talk about their new 2600 meter deep well (that’s 1000 meter more than the one in the Gulf) east of Newfoundland I thought I was having a nightmare.  Think about what would happen if there was a leak there and it got picked up by ocean currents. 

Why would the Chevron guy say that they have thought it through, that they have a better blowout preventer (a new design by the way), that they don’t need relief wells to be drilled now, etc.? I think Chevron thinks they are better than BP.  I’m pretty sure the BP guys thought that they were better than their peers too.

Risk management and rose colored glasses do not go together.  Risk management and ego do not go together.  Brushing away a risk because of a low likelihood is not good enough; you have to have low impact too.

Looks to me like history may end up repeating itself; let’s hope not.  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.

Risk management quote

A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty.

- Winston Churchill

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.

The Leadership Thing; be Like John Wayne

I hesitated a good long time before writing this post; hopefully I don’t come out as too pompous and it is a long one…

To me, a good project manager has to be both a leader and a manager.  Those two roles are not the same contrary to what some people might think.  Here is my take on the leadership thing.

A leader typically has a large number of duties but few rewards.  To be a good leader you have to (not an absolute list):

• Take the time to listen and the time to state clearly what is required. You have to seek your team member’s opinions and consider them when you take decisions. This does not mean that the decision will please everyone.
• Take the time to state clearly what is required. You have to communicate decisions unequivocally; the army talks about a “lawfully given order” which means that it is stated in a clear manner. That means no “I’d like you to…”, “Would you…”, etc.; this may sound harsh but it is important to be clear if you want team members to understand that they are responsible for an outcome.
• Show some drive. Leaders get their marching order and then get on with their mission. Your team members will not follow you if you have to always ask someone else for directions or for permission.
• Have a backbone. To be a leader you have to be able to take the heat. Stuff will happen. Sometimes terribly bad stuff will happen and as I like to say “When panic appears to be the right thing to do, don’t!”. I know this sounds weird but it means that when things go wrong, it’s time to be like John Wayne and drive through the obstacle.
• Have a second helping of backbone. Team members are responsible for the outcome of the tasks they’ve been given; the leader is accountable for the results. The leader can’t run away from his responsibility; ever.
• Recognize the good work of others. Things get done because team members take their responsibilities and do their work. They are making you look good; acknowledge it.
• Have a third helping of backbone. Be willing to take some risks; you are most likely working on something that has never been done or that has some aspect that calls for going out on a limb. Do it! By the way that doesn’t mean being reckless; if you are not willing to take risks you are not a leader, if you take every risk you are a fool.
• Be trustworthy. You will never convince anyone to team with you if they don’t trust you. Try leading them if they don’t believe you are part of the team.
• Acknowledge your limitations, work on improving yourself, and be willing to receive criticism. No one is perfect. No one believes that you are; don’t even try to hide your limitations. You team will cope with your shortcomings if you acknowledge them, even if the criticism is hard to take, and make an effort to improve.
• Roll with the punches. You have a goal but there is more than one path to this goal. When you hit a problem you can keep on hitting it head first or adapt and workaround the issue. A leader is determined not stubborn.

As I stated before there are few rewards in leadership but the value of those rewards is amazing; a few of my experiences:

• An artillery warrant officer I trained years ago told me in front of a gathering of NCOs of my old unit that he would go to war with me as he trusted me to bring everyone back. Tall order but receiving that level of trust makes you want to move mountains.
• Another member of my old unit, who is also an Afghanistan veteran, recently told me that he wishes I had been there with them as they needed guys like me. This is a variation of the previous point and touched me deeply as I have been out of the services for close to 20 years.
• A colleague told me that, in his opinion, we managed to close a very tough, much challenged project because I inspired the team by refusing to abandon.
• Another colleague, after being let go due to the economic situation, thanked me for giving him the opportunity to grow and develop new skills; something no one else had gone on a limb for him.

I don’t know about you but moments like these make it all worthwhile.

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.

Risk management is a day 0 activity

This morning I was participating in a Mentisor seminar/roundtable activity on Risk Management and Scope Management.  Both subjects are basic project management topics that often don’t receive the attention they deserve given the mayhem that neglect may cause.  This got me to reflect on a conversation I had a few months ago with a client that got badly burned.

In my line of work system validation is mandatory and very expensive compared with hardware/software/programming costs.  The numbers vary and each of my clients has its own pet number but it is typical to add 170%, 200%, or even 220% to the purchase cost just to account for validation.  In hard numbers this means that a $1M system will cost $2.7M to $3.2M by the time it is validated and rolled out.  If the system is more expensive; you do the math.  It can get scary pretty fast

A side effect of this multiplier is that clients understandably fight scope change tooth and nail.  We do the same; no one wants to be the donkey in a game this pricey.  The title of this post being “Risk management is a day 0 activity”, you are probably wondering where I am going with this?  Well, the wait is over; some best practices related to Risk Management and Scope Management should avoid a lot of wasted money:

• Risks are built in the project approach; a project or product is not a repeat activity and some of this innovation is likely to have unrecognized risks. Recognize this from day 0.

• Avoid Swiss army knife software; there is no software package that does everything well and all those marginal features will still need to be tested and validated ($$$). What is the likelihood that some of these features are putting you project budget or schedule at risk?

• Avoid stakeholder’s pet feature for the same reason as above. I’ve had requests for reports that have the same content but packaged differently; keep only one variant and let the people adapt. There has to be a positive aspect to that Evolution thing.

• If you can’t avoid the two previous points, identify those features that are risky, track their triggers diligently, and the minute those triggers engage let the project sponsor know. You may be able to jettison them before they really hurt the project or at least to minimize their impact.

• Remind your stakeholders that featuritis is costly to implement, to validate, and to live with over the live of the product or system. Remember COBOL, FORTRAN, etc? Systems written in those languages still need to be “fed” years after rollout by old guy like me who will retire eventually.

Don’t tell me that these points don’t ring true and that they don’t represent situation that repeat themselves, with predictable outcomes.  Recognizing and managing risks from day 0 will save you a lot of aggravation and costs.

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.