Thinking, Fast and Slow (in a very fast economic environment)

At a recent Agile Day Chicago, one of the mini sessions I joined was to talk about this book “Thinking, Fast and Slow” (by Daniel Kahneman, admittedly it is on my wish list on Amazon). One of the arguments of the book, is that as humans, we instinctively decide on an easier solution (i.e., mentally, physiologically, etc.). The example used is that when walking through a forest, the tendency is a flight decision when we hear a growl. Thus, we do not process in our mind, that the growl may be a cry for help. In short, we decide on a solution framed by looking at validations for our decision or solution. Normally, we do not look for arguments, artifacts, discussions, justifications that do NOT validate our decision. (Another thought is that we are interested in a particular car, all of a sudden we start noticing similar car models on the road or parking lot –which we never noticed before. It is a validation process for our decision.)

This has implication on solutioning for technical issues, be it product development or solving for a particular issue in software development. I believe personally (and team-wise), there has to be an awareness of this tendency (a bias if you will) in framing a solution. Coming out of a recent Six Sigma Training by Chicago Deming Association, I could not help but remember the Ishikawa Diagram, in root cause analysis. It would do the team well, by asking the question “why” five times. This can be a way to mitigate the tendency to bias a solution from Kahneman’s argument. Not only can this process be effective in root cause analysis, I believe it has implication as well when attempting to solve complex problems, be it product development or software development.

Retrospectives – Lessons Learned Process

Most often than not, program and project managers have no time to devote to the principle of Lessons Learned. The latter is actually a principle, part and parcel of the Agile Manifesto. I had a great time learning about different tools and techniques on how to do Retrospectives. Brainstorming and plotting an emotional histogram was one. Futures-pectives was another brain storming idea.

As a team, everyone shares their fears, emotions both positive and negative, positive future outlook, positive and negative expectations- based on a past and future projects. It’s a refreshing approach to do risk analysis and risk management. Non Agile project managers can easily apply these tools to other industries’ project management.

Notes from Agile meet up

Agile meet up- Solstice consulting
David Babicz facilitator

At regular internals – retrospectives :
Went well
Not well.
What should we do about getting better?

We understand and truly believe that everyone did Their best job they could, given what they knew at the time , their skills and abilities ..

5 anti patterns
1. Griping session- have actions and volunteer ownership instead.
2. Pointless- assigning actions without follow through.
3. Stressful- only looking back when something failed.
4. Embarrassing – do not use information to embarrass it blame.
5. Urgent crowding out the important.

Getting started:
1. I will contribute to the conversation.
2. I will likely participate
3. I will participate in some topics
4. I may respond when questioned
5. I will smile and nod with the rest of the group.

Further reading: “Agile retrospectives.”

distributed teams tools:
“Idea boardz”. What went well, what did not quite well, what will do about it.
Card meeting – can be used real time.
“cacoo” – to map out process . Great for small groups.
“Edit storm ”
“Twiddla ”
Innovation games
Mind meister
Check out innovation games on the web.

March Madness

I am not one to join a pool for the NCAA Basketball Tournament, nor predict who will win the national championship. You probably are wondering what March Madness has to do with Project Management. It is this: the process of predicting who will make it to Final Four and win the national championship is about as much science (and art) as predicting Risks and coming up with a Risk Management Plan in Project Management.

I don’t exactly know what input variables predictors use, but I would imagine the following (with how little I know about basketball):

• Schedule strength, who the team’s opponents are in the bracket, as they move on from one round to another,
• Production per player and as a team statistics, e.g., Field Goal percentage, Free Throw percentage, blocks per game, turnovers per game, assists per game, points off turnovers, etc.
• Compare team production and statistics versus the opponent,
• Regular season AP or some other analyst or analysts ranking. I am confident there are other key statistics that pundits will consider, but these primarily come to my mind.

Similar to predicting who’ll be in the Round of 32, Sweet 16, Elite 8, Final 4, and ultimately who’ll win the national Championship—there is as much science as predicting varied risks to a project or program.

There is a lot that goes on to identify Risks:

• Brainstorming
• Delphi technique
  

  PMP logo.

• Checklist technique via historical information and prior knowledge base
• Assumption Analysis
• Diagramming techniques such as Cause and Effect Diagrams, System or Process flow charts, Influence Diagrams
• SWOT analysis
• Expert Judgment.

At the conclusion of Risk Register, this information is a basis for a Probability and Impact matrix—as the risks impact scope or quality, time and schedule, i.e., perform a Qualitative Risk Analysis along with a Quantitative Risk Analysis. Quantitative Risk Analysis can be complex, as laid out in PmBOK (4th Edition):

1. Data Gathering and Presentation Techniques

• Interviewing
• Probability Distributions (beta or triangular distribution)

2. Quantitative Risk Analysis and Modeling techniques

• Sensitivity Analysis
• Expected monetary value analysis (EVM)
• Modeling and Simulation

3. Expert Judgment I won’t discuss the outputs from the Qualitative and Quantitative Risks Analysis. Suffice to say that there is a lot of science and statistics that can be applied to predict the impact of Risks, along with predicting the NCAA 2012 champion.

There are however (pardon the cliché in sports) intangibles that may surprise the batter, as a curve ball is pitched. In sports:

• We do not know what goes on at a half-time break, or what the coach says.
• What the team captain says to the team,
• What personally motivates each player, during substitutions,
• What coaching occurs during time outs, and finally
• What fires up a team when they are 20 points behind at the half time break.

Within a project, a lot of unknowns are taken into account, or at least attempted to be accounted for. However, it is impossible to predict and account for all key project inputs—along with external parameters that can potentially impact the project or program, e.g.,

• Volatility in Gas price or jet fuel price,
• Local or Governmental policies,
• Inclement weather,
• Weather-related disaster,
• Downturn in the European Union economies, and
• Consumers being spooked by a failing European economy.

In project management, Risk Analysis and Risk Management is a must to mitigate scope, time and financial impact. In the NCAA Championship prediction, the same analytical approach can be utilized. Experts who do this continually can sharpen their prediction skills, and predict with more accuracy. However, there are still intangibles that can come from a blind corner. However, this should not preclude anyone from following a certain process or analysis–be it predicting who’ll win it all or coming up with a Risk Management Plan.

Risk Management Plan with Dollars and Cents

Here are excerpts from an answer to a question posed on a Webinar hosted by Paul Burek of Solutions Cube Group LLC related to Risk Management.

“Bobby, you asked this question during the Solutions Cube Group webinar Minimize Project Threats / Exploit Project Opportunities webinar.

Q: Have you seen risk management plans with definite $ amount as financial impact within risk register?[Bobby Taruc]

Answer: Incorporating definite $ amounts as the financial impact (cost objective) in a risk register is certainly a viable way to communicate and quantify the cost impact.  As part of calculating the risk score (probability x impact), I have seen project team’s multiply the probability percentage (of the risk occurring) by the perceived financial dollar amount impact to derive the potential dollar impact. They then use this dollar amount when assigning an impact value to the risk – based on the ranges they have predetermined for high, medium and low $ impacts. This is a great way to remove the subjectivity from the impact scoring for a risk and we discuss this concept in our upcoming in depth webinar series on Risk Management.”

I believe the Project or Business Sponsor becomes a captive audience when the project manager or program manager includes and assigns dollar amounts to the Risk Management Plan. Risks and Risks Mitigation plans become alive and become more visible when this is done. At this point, the Project Plan and Risk Management Plan, both have input to the business’ P and L. In today’s brutal and exacting economy, it is critical that all identified risks have the proper risk mitigation plan and risk response plan.

Project Status Reporting, A Lesson We Can Learn from Costa Concordia Report

Photo Credit: Vincenzo Pinto / AFP - Getty Images

As more information unravels from the tragedy (today 1/19/2012), I am very surprised and appalled that Captain Schettino was not the one communicating with the Italian Coast Guard but a member of the crew reporting that the ship had a “black out.” As the Italian Coast Guard presses for more information, the crew member repeated that a “black out” occurred, and that they “are checking conditions.”

As a Project and Program Manager, it is incumbent upon the project manager not to sugar coat nor hide any project issues (or information) to the Project Sponsor, nor to any stakeholders for that matter. It is human nature to fear repercussions when an issue or issues surface. Hiding any issue or information, big or small, or have the potential to be a huge issue—has no place in any program or project. As project managers, it will do us well to remember this reality.

The end of Kodak moments

I heard about the declaration of bankruptcy by Kodak today. Saddening to learn about such an iconic American company that invented the camera and printing of photographs—that capture specific points or way points in our lives. I did not even know that Kodak invented the digital camera. For the executives to not have pursued the digital camera wave, for fear of cannibalizing the film portion of their business—was short sighted. This reminds me of other technology innovators in my lifetime, e.g., Palm (brought us the Palm Pilot PDAs or even the Apple Newton), tapes replaced by CDs and now MP3s, AOL (ISP regardless that it was 56K, at its peak bought by Time Warner), Wang, Compaq (now owned by HP), well, you get the idea.

It is difficult to compare Kodak’s predicament to a movie franchise’ (1^st, 2^nd, or 3^rd sequel such as Star Wars), or a successful TV series’ demise (such as “Friends” or “Seinfield”). Most if not all (well, maybe with the exception of “the Oprah Show”) TV shows or sequel movies “jump the shark.” The story line or the characters (I would guess due to scriptwriters attempt to extend the show’s success) becomes unexciting, inane, does not make sense, feels old, lame, or plain boring. Sometimes, the actors or actresses depart from the show, asking for astronomic pay raise. Sometimes, for just unforeseen or inexplicable reason, the viewership dwindles and falls irreversibly.

To me, Kodak’s downfall is due to failure to innovate regardless that the marketplace was changing. There is a lesson to be learned here. Technology and product lines now change in weeks and months, not a year or 2. From a career perspective, our personal “brand” has to change with the needs of the marketplace as well. To continue to rest on past successes would be foolish on anybody’s part.

Costa Concordia Disaster—Short Notes and Analysis

As of today, 5 people have been identified as fatalities, 29 missing among the 4,000 passengers and crew. 1. No training at muster station for passengers, to provide training on proper use of life boats and full awareness of life boats’ locations. From a project management perspective, training is sorely needed during the implementation process … Continue reading →