Noobs vs Experts

Inspired by the conversation with my colleague Jason.

Evil Marketer

My friend Ryan needed me to confirm he was answering correctly to avoid any future spam while subscribing to a reputable papar magazine online. Snap!

You may need to click on the image to read the text at the bottom

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.