Putting risk register and project plan together

---

David Hulett has a presentation on his website, projectrisk.com, entitled "Schedule Risk Analysis using the Risk Driver Method and Monte Carlo Simulation".  In this presentation, he develops an interesting operating idea: first, shift the Monte Carlo method to the higher level of events on the risk register, and then use those results as drivers on the schedule.

His idea he explains this way:

"Applying first principles requires that the risk to the project schedule be clearly and directly driven by identified and quantified risks. In the Risk Driver Method the risks from the Risk Register drive the simulation.

The Risk Driver Method differs from older, more traditional approaches in which the activity durations and costs are given a 3-point estimate which results from the influence of, potentially, several risks which therefore cannot be individually distinguished and kept track of.

Also, since some risks will affect several activities, we cannot capture the entire influence of a risk using traditional 3-point estimates of impact on specific activities.

Here are the steps:

1. Assign risk distributions to the events on the risk register.  This is more than just a simple PxI calculation.  It means do a three point estimate on each risk event; the real world distribution, likely unknown, can be modeled as a Triangular distribution for simulation purposes.

2. Also evaluate whether or not the risk event, if it occurred, would actually effect every task on the schedule, or just some tasks, and--here's a twist--evaluate whether or not a true event would actually effect the schedule/cost plan. 

That is, if for example labor rate escalation is a risk event, and it actually occurs, does the escalation really get applied or not?  Perhaps there are reasons that the escalation, even though authorized, would not be applied in every case; only be applied in some cases.  Hulett recommends that the latter assessment be on a continuous scale of 0 to 1. 

With this evaluation, you now have two probabilities associated with a risk event: will it occur, and if it occurs, does it have an effect?

3. Now run a Monte Carlo on the schedule; then, run a Monte Carlo on the risk register; then create an intersection between them, in effect identifying correlations between schedule and risk drivers.

What do you get?  You get a simulation result that integrates the probabilistic characteristics of the risk events on the risk register with the probabilistic characteristics of the schedule/resource plan. 

Of course, this is method is all but impossible without a tool to model both the three point estimates and the correlations. That's more or less the secret sauce behind the curtain, but nonetheless the idea of the risk driver method is first rate.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Project networks the hub and spoke way

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and as an EE, I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? 
After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Managing the change to Agile

---

I once asked my Agile class what they would do vis a vis change management to prepare the organization to take on Agile methods, if only a pilot to start.

One student replied this way. I thought it was pretty decent list, so I present it unabridged:

"In order to gain acceptance I would use the following change management techniques:
- Vision–Clearly articulate the vision and needs
- Phased Implementation–Start out slow and progressively implement Agile practices in a prioritized order
- Create a Communications Plan–Ensure all affected parties understand your vision and realize the benefits of Agile. You need to explore how Agile practices will impact the customer, the organization, various departments and the employees who will be involved.
- Educate Stakeholders–Education of stakeholders is imperative. Everyone on your communication plan needs to understand why Agile is being implemented, and the benefits and practices involved.
- Prepare for Change Resistance–I would use my communication plant to communicate my vision to the sponsor and key stakeholders/customers, accept that there may be resistance to the change. I would need to continually stress the benefits for the nuclear utility and how Agile could be beneficial to them on future projects.

Once the customer agreed to use the Agile methodology to implement the Plant Computer System as a pilot project for Agile, I would transition to the Agile Project t Methodology as follows:

- Business Value–Specify how Agile will help resolve any current problems, and how it supports the business objectives.
- Create Implementation Plan–Create and execute a communications plan to share key messages and listen to sponsors , employees and other stakeholders. Continuously communicate progress, objectives and changes. Solicit feedback to ensure support for the transition.
- Create Communication Plan–Create and execute a communications plan to share key messages and listen to sponsors, employees and other stakeholders. Continuously communicate progress, objectives and changes. Solicit feedback to ensure support for the transition.
- Create Training Plan–Create and execute a training plan. Provide the team with sufficient training and continued support. Many Agile implementations have failed after team members were sent to training and afterwards told to implement new approaches without further support or guidance."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile 103

---

Did you miss this? My presentation to the Central Florida Chapter of PMI with a presentation entitled: "Agile 103 -- THE THREE BIG QUESTIONS". You can get it at slideshare.net/jgoodpas.

• Agile 103?  Because it covers material not in your usual Agile 101 course
• The Three Big Questions? After working with hundreds of students who go through PMI's Agile Project Management course, of which I am one of the instructors, I put the most common questions together in this presentation

Now, I've addressed these questions here and there in Musings, but this presentation puts them all together.

---

Bookmark this on Delicious

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

A Turning Point for Humanity

---

Ordinarily, we here at Musings don't go into for a lot of hyperbole, but when no less an eminence than the National Institute of Standards and Technology (NIST) shouts out:

 "A Turning Point for Humanity: 

Redefining the World's Measurement System"

we have to sit up and take notice

And so what are we talking about here? Does this mean that all the PMOs have to turn in their sliderules and yardsticks? And, gasp!, try something new?

Not exactly

This November, in Versailles, France, representatives from 57 countries are expected to make history.  They will vote to dramatically transform the international system that underpins global science and trade. This single action will finally realize scientists’ 150-year dream of a measurement system based entirely on fundamental properties of nature.

The International System of Units, informally known as the metric system—the way in which the world measures everything from coffee to the cosmos—will change in a way that is more profound than anything since its establishment following the French Revolution. 

It will be a turning point for humanity

And, here it is:

 The revised [standard] will redefine the kilogram using a fixed value for the Planck constant
and using the definition of the meter and second, which are already based on constants.

This single change to the definition of the kilogram will democratize precision measurement by making it possible to do more accurate and precise measurement science anywhere in the world (and even the universe), without needing calibration to a specific artifact.

Application (In the PMO we are all about application)
From NIST: "With this system, should E.T. or Alf come knocking, we would be able to communicate the base units to residents of other planets in other galaxies, who could use them with the same accuracy as we do."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Getting timely

---

And so this headline pops up: "Time split to the nanosecond ... ".

It's only a foot
Per se, nanoseconds are not particularly new and unique to projects, and most in a PMO know its a pretty short time, about the time required for light to travel a foot (11.8" at sea level, but let's not be too picky on this one)

However, we now learn that worldwide computer networks need to be time synchronized to a nanosecond of accuracy.  That is actually a tall order, given network latency, media differences in propagation, and so forth.

Did mention requirements?
And where did this requirement come from? (Being PMO types, we always ask for the requirement first. If there is just smoke and mirrors, we can write this one off and go onto the next big thing)

No less than Wall Street (Actually, Time Square in NYC where the NASDAQ is).
Shocking -- shocking! -- as it seems: It's all about the money!

It's a scheduling problem
And, it's about schedule (something we understand) and specifically sequencing tasks within schedules, setting up the right dependencies (Hey! this stuff is right down town for PMOs)

When you're responsible for executing financial trades, timed to the nanosecond, in the correct order -- and order counts when you are looking a market volatility at nanosecond rates -- you had better get it right. Or else!

So, break out your critical path analysis, you PDM charts, and to work on the NASDAQ. There's money to be made!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

If you only know one thing about Risk Management .....

---

If you only know one thing about Risk Management, know this:

Schedule slack is your most powerful tool

Poorly developed instincts and skills in the use of this most powerful tool are leading causes of poor risk management

If you are a Systems person --- a strategic thinker; an integrator; a "it all has to work" person -- you'll translate schedule slack into to "loose coupling"

Loose coupling is your most powerful tool

This all sounds like schedule, but the side effects are profound (slack is like a nail; it works everywhere):

• Time is lost to effect design, manufacturing, or delivery mitigation
• Pressures mount to "do something"
• Short-cuts are taken
• The thing may not work at the end (oops, that's career limiting)

And, the list of slack misuse is relatively short, so everyone should be able to keep these bullets in mind:

•  It shall be: All schedules require slack; a schedule without slack is but a hope, and is risky all the way
  
• At the end: Slack is always sequenced after a risky event is to occur. NEVER put the slack first, hoping it will all go away
• Don't add risk unwittingly: Unnecessary coupling (to wit: bundling) just adds risk where there was none. Decouple everything; don't purposely couple anything. 

If you bundle (tightly couple) the statistics are against you:

• If two independent events have a 9-in-10 chance of success, then when tightly coupled and no slack between them, success of the pair is only 8-in-10, a loss of 10 points
• It gets worse fast: a pair with 7-in-10 chance of success degrades to less than 1-in-2. A loss of 20 points.  Good grief!

The effect of slack? NO loss of points .... a cheap way to fight  

 

 

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog