Book Summary: Waltzing with Bears Part II

Risk Diagram

• x-axis: dates
• y-axis: relative probability

Nano-Percent Date (N)

• the first date that has a nonzero probability (nano-percent likely)
• on software industry average, window size is somewhere between 150-200% of N

Mechanics of Risk Management

• yesterdays' problem is today's risk - initially add the project retrospective results of previous projects
• Risk management is not the same as worrying about your project
• Some risks expire during the course of a project. By the end of the project, all the remaining risks expire.

What to do about a Risk

• avoid: don't do the project
• contain: set aside sufficient time and money to pay for it, should it materialise (risk reserve)
• mitigate: take steps before-hand in order to reduce containment costs
• evade: do nothing and the risk doesn't materialise

Risk Exposure

• expectation of containment cost
• risk exposure = cost x probability
• risk exposure can be expressed in terms of time of expected delay

Showstoppers

• can only be managed by project assumptions
• should any one of the project assumptions prove false, have to escalate the issue upwards
• showstoppers are beyond the responsibility and authority of the project

Risk Management Prescription

1. compile a census of risks using a risk-discovery process
2. make sure all core risks are present
3. do homework on each risk
• name and id
• transition indicator
• estimate impact (cost & schedule) & probability
• calculate risk exposure (budget & schedule)
• determine contingency actions & mitigation actions
• add mitigation actions to project plan
4. designate showstoppers as project assumptions
5. determine nano-percent date (first-pass schedule estimate)
6. construct a risk diagram using N date
7. express all commitments using risk diagrams showing the uncertainty
8. monitor all risks for materialisation & expiration and execute contingency plan if required
9. keep the risk-discovery process going

Commitments and Goals

• schedule = goal = N => stupid
• schedule > goal > N => sensible

Public Risk Management

• keeps all eyes on the core risks
• enables all to engage in the ongoing risk-discovery process

Simplicity

Excellence through Simplicity

- Lao Tzu

Book Summary: The Elegant Solution

The Elegant Solution by Matthew E. May

Part I: Principles
The Art of Ingenuity - Business meets art and science in an emerging view of work.
The Pursuit of Perfection - Conventional wisdom forcing a choice between small steps and big leaps misses the point.
The Rhythm of Fit - What distinguishes great innovation is its ability to serve the changing needs of society.


Part II: Practices
Let Learning Lead - Learning and innovation go hand in hand, but learning comes first
Problem: Learning disabilities hinder 360 innovation.
Cause: Learning is misunderstood and undervalued.
Solution: Make learning the job

IDEA: Investigate -> Design -> Execute -> Adjust

Learn to See - Elegant solutions often come from customers - get out more and live in their world
Problem: Solutions don't work as imagined
Cause: The facts aren't clearly understood
Solution: Learn to see

a) Observe -- watch the customer
b) Infiltrate -- become the customer
c) Collaborate -- involve the customer

Design for Today - Focus on clear and present needs, or your great ideas remain just that
Problem: Solutions land far before the need
Cause: Preoccupation with invention
Solution: Design for today

innovation -> providing tomorrow's solution for today's problem

Think in Pictures - Make your intentions visual - You'll surprise yourself with the image
Problem: The endgame isn't clear
Cause: Underdeveloped storytelling skill
Solution: Tell the story with pictures.

Capture the Intangible - The most compelling solutions are often perceptual and emotional
Problem: Solutions lack that certain something
Cause: Transaction tunnel vision
Solution: Capture the intangible

Leverage the Limits - Restraining Forces Rule - Resource constraints can spur ingenuity
Problem: The entrepreneurial spirit is M.I.A.
Cause: Addiction to abundant resources
Solution: Rest the bar

Master the Tension - Breakthrough thinking demands something to break through
Problem: Solutions lack inspiration
Cause: We satisfice
Solution: Work through creative tension

Run the Numbers - Think for yourself - Temper instinct with insight, focus on facts, and do the math
Problem: Proposed solutions lack basis in fact
Cause: Aversion to numbers
Solution: Counter intuition with insight

Make Kaizen Mandatory - Pursuing perfection requires great discipline - Create a standard, follow it, and find a better way
Problem: Innovation is hit or miss
Cause: Creativity is misdirected and mismanaged
Solution: Embed the kaizen ethic

Kaizen basis is standardisation
Creating a standard requires: A. Clarity B. Consensus
a) Establish a Best Practice
b) Document the Standard
c) Train to the Method

Keep it Lean - Complexity kills - scale it back, make it simple, and let it flow
Problem: Too many, too much - of everything
Cause: Assumption that more is better
Solution: Start thinking lean

Lean: doing more of what matters by eliminating what doesn't
How do we know we are lean? When the customer says "It's just what I needed. Getting it was effortless."
Lean: Customers pull compelling value from you effortlessly.

Leaders make meaning

Marketing and Innovation

Business has only two basic functions-marketing and innovation.

- Peter Drucker

Learning Organisation and WOW Expansion Pack

My colleagues and I were on return flight from Toyota factory tour. Starting with topics of organisations and skill-acquisition-based career path rather than role-based path, which tends to limit one's growth opportunities in my opinion, the discussion moved on to Toyota and their career promotion structure. How it is extremely long and challenging process to become a chief engineer and the enormous skill acquisitions on the way.

I like the idea of skills-acquisition-based career path and having long list of skills that would take ages to master as similar to chief engineer concept in Toyota. It is similar to playing MMORPG such as WOW. The best part of WOW is leveling up from level 0 to max level 60 (for initial launch). You get the sense of progress all the time. Once you hit max level, it feels great for a while but soon becomes less exciting because the rate of learning slows.

Luckily Blizzard publishes expansion pack every 1-2 years and increases max levels by 10 or so. Certainly all maxed out players get new things (skills) to learn. Cool. Joy of learning!

I think a learning organisation should do the similar by constantly generating expansion pack for members to learn. Identify new list of skills required to achieve organisational objectives and to articulate what they are and to generate content (training programs) for them to acquire new skills so their increase levels (effectiveness, growth, capability). Leaders in an organisation would be just like content developers for MMORPG. After all, everything is trainable, I believe.

Technical Risk Management

While reading Waltzing with Bears, I realised that I had never done any rigorous risk management over technical risks. There are many common risks I can think of even without trying. For example;

• selecting wrong middleware or servers
• sup-optimal architecture/design assumptions
  
• a module or component fails to deliver due to complexity or dependency
  

PMs/IMs generally own the risk register and the register usually excludes technical risks due to their lack of technical knowledge. I believe the technical risks should be managed with the same level of focus. I'm not sure it would be better to include the technical risks in general project risk register or to manage in a separate list managed by technical team. One thing is sure that I can improve my technical risk management better.

Set-Based Concurrent Engineering (SBCE) anyone?

Waltzing with Bears Part I

Gems from Waltzing with Bears by Tom DeMarco & Timothy Lister.


If a project has no risks, don't do it.

Risk management is project management for adults.

The word maturity has nothing to do with technical proficiency. It is, rather, a quality of grown-up-ness, ......

A risk is a problem that has yet to occur, and a problem is a risk that has already materialized.

Risk management is the process of thinking out corrective actions before a problem occurs, ...... The opposite of risk management is crisis management, ......

Risk Transition: the point at which the risk materialises.

Transition Indicator: the visible event at the time of risk transition.

Component activities for risk management

1. Risk Discovery: initial risk brainstorm & subsequent triage
2. Exposure Analysis: quantification of each risk (probability & impact)
3. Contingency Planning: what you do if it materialises
4. Mitigation: steps that must be taken before transition in order to keep your options open and to make correction possible afterward.
5. Ongoing Transition Monitoring: tracking of risks

The worst organisations penalise unappealing forecasts, but not unappealing results.

Without risk management, projects have no way to distinguish between stretch goals and reasonable expectations.

Before any risk management. Speak the words "failure", "rejection", and "cancellation". If the words do not come out easily, you have cultural problem!

When you choose to ignore a risk, you're depending on luck.

Reasons to ignore a risk:

1. The probability of materialization is small enough to ignore.
2. Should the risk materialise, it makes the effort under management irrelevant.
3. The risk has minimal consequences and requires no mitigation.
4. It's somebody else's risk.

When a project comes wrapped as a challenge, it forces you into a posture of counting on a certain amount of luck.

Limiting the extent of your losses in software project work is more important, on average, than doing anything about your wins.

Project for Success

Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures by C. W. Johnson and C. M. Holloway questions the usual blame placed on inadequate requirements engineering for software project failures (safety-critical software). The paper is here.

The paper then presents the following list as root causes of the project failure identified incorrectly under inadequate requirements engineering.

1. lack of stakeholder involvement
2. incorrect environmental assumptions
3. communications failures within development teams
4. inadequate conflict management
5. lack of contextual detail

I find #4 interesting in particular. We suffered a bit from #4 in current project. The project required input from different departments (marketing, operation, client service and etc) which had different interests. It was a difficult process to draw a decision to everyone's satisfaction. The lesson was to work out conflict resolution process early among stakeholders.

It is a great checklist for early phase of a software project and a great starting point for discussion with project sponsors & project leaders.

See Alistair Cockburn's blog about the paper.

Belief

We do not believe in ourselves until someone reveals that deep inside us something is valuable, worth listening to, worthy of our trust, sacred to our touch.

Once we believe in ourselves, we can risk curiosity, wonder, spontaneous delight, or any experience that reveals the human spirit.

- E. E. Cummings

Chief Engineer

The top product development program at Toyota is the chief engineer (CE). CE is the project leader, project manager and technical leader all rolled into one. CE designs the system and is ultimately responsible for delivering value to the customer and the program's commercial success. CE therefore is usually sponsored by someone in vice-president level.

In Toyota product development, managers with no technical skills are moved to manage other things. Knowledgeable engineers without interest in people and money are sent to R&D.

During the program, CE becomes the primary voice of the customer. Because of this, a person with the background and experience to establish an emotional connection with the target customer is selected as CE for a program.

Therefore selecting chief engineer for a program is the critical first step of Toyota product development process.

Once selected, CE focuses on value discovery process and value definition. CE then communicates customer-defined value & vehicle-level performance objectives and aligns the vehicle-level performance goals of the entire program team.

Another interesting thing is the document called shijisho produced by CE. This is a concept paper that outlines the CE's vision for the new vehicle. The literal translation of shijisho is "direct order document" almost like a military order.

Elements of Toyota's Lean Product Development

This is from Lean Product and Process Development by Allen C. Ward.

• All Toyota developers spend about half of their first year assembling and selling cars. The final customers & the customers for the product development process.


• Identifies the critical skills associated with each job.
  
  1. Understands the basic engineering principles
  2. Works fast enough to keep up with the team
  3. Takes responsibility for the work
  4. Can teach the skills


• Keeping people in position long enough to become expert and to get good feedback on their decisions.


• Require engineers to "get their hands dirty".


• Developers must be evaluated on their contributions to project success.

Follow Process Mapping with Walk Through

I have never walked through a process mapping or a process flow during the discovery phase of a project. This simple technique was mentioned in a local lean group meet-up.

Just pick up a process map and physically follow the process where the operational people are. Opportunity to talk to people on the ground, learn more about what they do and review the current process mapping. It can lead to rich learning experience. Rich context around the words and drawings.

Definitely something to try next time.

Standards

I'm reading Toyota Production System by Taiichi Ohno. In "The True Intention of the Ford System" chapter, he quotes Ford's book regarding standards.

One has to go rather slowly on fixing standards, for it is considerably easier to fix a wrong standard than a right one. There is the standardizing which marks inertia, and the standardizing which marks progress. Therein lies the danger in loosely talking about standardization.

And the rest of the passage talks about that standards effort should not be directed from above or it does not lead to progress.