Praise! Use numbers to show quality impact.

I just stumbled upon a very nice blog entry by Fergal McGovern of Visible Thread. It is about my article on "Extreme Inspections". Fergal appreciates that I showed ROI figures:

What was doubly exciting for me in this article is that you see the actual ROI of inspection in clear terms. Utilising the approach of ‘extreme inspection’ in one case Rolf cites, we see a reduction in the number of defects per page by 50%. Clear empirical evidence of actual defect reduction as a consequence of inspections in real projects is hard to come by and so Rolf’s case studies are useful to consider.

Thank you Fergal!

I took a looong look on Fergal's company and website. Their solutions look very promising in terms of document quality assessment and improvement. Visible Thread does detailed quality checks on Office documents and shows the results, for grounding decisions on data is always better than on gut feeling.
Head over and see for yourself.

What are the most valueable specifications?

During my last vacation I came across evidence of good technical value specifications. At VW's Autostadt there is a display of this wonderful old Phaeton Sedan (sorry the photo is blurred).

There also is a reproduction of a poster that was used to market the car at its times. It clearly states the most important values the car delivers. Reading through it, and thinking of the extreme focus on functions nowadays, I ask you: Did we forget to focus on the really important things, like value?

The poster reads:
It is our belief that the most important "specification" of the Cord front-frive are: Do you like its design? Does the comfort appeal to you? Does it do what you want a car to do better and easier? When a car, built by a reputable and experienced company meets these three requirements, you can safely depend on that company to adequately provide for all mechanical details. -- E.L.CORD

Problem to Solution - The Continuum Between Requirements and Design

Christopher Brandt, relatively new blogger from Vancouver, Canada, has an awesome piece about the difference between problem and solution. If he blogs more about problem solving, and in this outstanding quality, he definitely is someone to follow.

While I do not completely agree with the concepts, I believe everybody doing requirements or design should at least have this level of understanding.

Requirements written that imply a problem end up biasing the form of the solution, which in turn kills creativity and innovation by forcing the solution in a particular direction. Once this happens, other possibilities (which may have been better) cannot be investigated. [...] This mistake can be avoided by identifying the root problem (or problems) before considering the nature or requirements of the solution. Each root problem or core need can often be expressed in a single statement. [...] The reason for having a simple unbiased statement of the problem is to allow the design team to find path to the best solution. [...] Creative and innovative solutions can be created through any software development process as long as the underlying mechanics of how to go from problem to solution are understood.

Which brings me to promote again and again the single-most powerful question for finding requirements from a given design: WHY?

Don't forget to have fun ;-)

Why High-level Measurable Requirements Speed up Projects by Building Trust

(Allow 5 minutes or less reading time)

Stephen M.R. Covey‘s The Speed of Trust caused me to realize that trust is an important subject in the field of Requirements Engineering.

Neither the specification of high-level requirements (a.k.a. objectives) nor the specification of measurable requirements are new practices in requirements engineering after all, just solid engineering practice. However, they both are extremely helpful for building trust between customer and supplier.

The level of trust between customer and supplier determines how much rework will be necessary to reach the project goals. Rework – one of the great wastes that software development allows abundantly – will add to the duration and cost of the project, especially if it happens late in the development cycle, i. e. after testing or even after deployment.

Let me explain.

If you specify high-level requirements – sometimes called objectives or goals – you make your intentions clear: You explicitly say what it is you want to achieve, where you want to be with the product or system.

If you specify requirements measurably, by giving either test method (binary requirements) or scale and meter parameters (scalar requirements), you make your intentions clear, too.

With intentions clarified, the supplier can see how the customer is going to assess his work. The customer‘s agenda will be clear to him. Knowing agendas enables trust. Trust is a prerequisite for speed and therefore low cost.

“Trust is good, control is better.” says a German proverb that is not quite exact in its English form. If you have speed and cost in mind as dimensions of “better,” then the sentence could not be more wrong! Imagine all the effort needed to continuously check somebody’s results and control everything he does. On the other hand, if you trust somebody, you can relax and concentrate on improving your own job and yourself. It’s obvious that trust speeds things up and therefore consumes less resources than suspiciousness.

Let‘s return to requirements engineering and the two helpful practices, namely specifying high-level requirements and specifying requirements measurably.

High-level Requirements

Say the customer writes many low-level requirements but fails to add the top level. By top level I mean the 3 to 10 maybe complex requirements that describe the objectives of the whole system or product. These objectives are then hidden somehow implicitly among the many low-level requirements. The supplier has to guess (or ask). Many suppliers assume the customer knew what he did when he decomposed his objectives into the requirements given in your requirements specification. They trust him. More often than not he didn‘t know, or why have the objectives not been stated in the requirements specification document in the first place?

So essentially the customer might have – at best – implicitly said what he wants to achieve and where he is headed. Chances are the supplier’s best guesses missed the point. Eventually he provides the system for the customer to check, and then the conversation goes on like this:

You: “Hm, so this ought to be the solution to my problem?”

He: “Er, … yes. It delivers what the requirements said!”

You: “OK, then I want my problem back.”

In this case he would better take it back, and work on his real agenda and on how to rebuild the misused trust. However, more often than not what follows is a lengthy phase to work the system or product over, in an attempt to fix it according to requirements that were not clear or even not there when the supplier began working.

Every bit of rework is a bit of wasted effort. We could have done it right the first time, and use the extra budget for a joint weekend fishing trip.

Measurable Requirements

Nearly the same line of reasoning can be used to promote measurable requirements.

Say the customer specified requirements but failed to AT THE SAME TIME give a clue about how he will test them, the supplier most likely gave him a leap of faith. He could then either be trustworthy or not. Assume he decided to specify acceptance criteria and how you intend to test long after development began, just before testing begins. Maybe the customer didn‘t find the time to do it before. Quite possibly he would change to some degree the possible interpretations of his requirements specification by adding the acceptance criteria and test procedures. From the supplier‘s angle the customer NOW shows your real agenda, and it‘s different from what the supplier thought it was. The customer misused his trust, unintentionally in most cases.

Besides this apparent strain on the relationship between the customer and the supplier, the system sponsor now will have to pay the bill. Quite literally so, as expensive rework to fix things has to be done. Hopefully the supplier delivered early, for more time is needed now.

So...

Trust is an important prerequisite to systems with few or even zero defects; I experienced that the one and probably last time I was part of a system development that resulted in (close to) zero defects. One of the prerequisites to zero defects is trust between customer and supplier, as we root-cause-analyzed in a post mortem (ref. principles P1, P4, P7, and P8). Zero defects mean zero rework after the system has been deployed. In the project I was working on it even meant zero rework after the system was delivered for acceptance testing. You see, it makes perfect business sense to build trust by working hard on both quantified and high-level requirements.

In fact, both practices are signs of a strong competence in engineering. Competence is – in turn – a prerequisite to trust, as Mr. Covey rightly points out in his aforementioned book.

If you want to learn more on how to do this, check out these sources:

• Measurable Value (with Agile), by Ryan Shriver.
• How to rewrite a requirement / How to make it measurable (See a live example of a bad and a good high-level specification), by Tom and Kai Gilb.

You can also find related material on Planet Project:

• How to Specify High-level Requirements (aka goals).
• Requirements Hierarchies and Types of Requirements.

Quantum Mechanics, Buddhism, and Projects - Again!

Today I'm proud to announce that my QMBP :-) article was again published by a major web site on business analysis, requirements engineering and product management: The Requirements Network. The site is full of interesting material for beginners and experts. I recommend reading it.

You'll find the piece of mine and some interesting comments here.

And - ha! - mind the URL of my article: ... node/1874.

Did you know that Winston Churchill was born that year? Must say something ... :-D

Find out more about 1874.

Value Thinking: Using Scalpels not Hatchets

Ryan Shriver, managing consultant at Dominion Digital, has put out an excellent article on Value Thinking. I think his views are extremely relevant, as we see cost reduction programs all around the IT globe. I can't tell you how much Ryan is spot on, considering the organization I work for (sorry, can't tell you more in public).

The article is short, gives ample information on the WHAT and (more importantly) the WHY.

Ryan writes in due detail about 4 policies and 5 practices, his advice to struggling IT shops and IT departments.  Thanks Ryan!

It's on gantthead.com, and I recommend signing up if you aren't already, it's free.

Update on Specifying Goals

I updated the Planet Project article on Specifying goals, using some of Tom Gilb's approaches and recent experience with the topic from one of my projects.

In this project, we struggled somewhat to explain to our subject-matter experts the importance of beginning with the (ultimate) end in mind. They thought they had to describe every little step, every button and every view of an IT application down to the smallest detail.

My favorite example was the following sequence (from a use case description), repeated a hundred times within the requirement specification:

1. User does some inputs
   
2. User "sends" the input, i. e. confirms his inputs
3. System checks inputs against rules X and Y
4. Systems shows an error message in case the checks fail.
5. ...

I finally got them with suggesting an alternative solution, roughly like this:

1. User does some inputs
2. (System has to make sure rules X and Y are not broken)

I guess the key was to make up a scenario which used quite a lot of sarcasm:

1. "I think I am an expert user."
2. "I do these simple inputs. Damn I'm good!"
3. "Now send the stuff to the stupid machine." *klick*
4. "Ooops ... What the ...."
5. "The stupid machine says I did it wrong?!"
6. "Why didn't it prevent me from doing it wrong, is there anything this machine is useful for?"

:-D

How to Personally Get the Most Out of Finished Projects

Name: How to Personally Get the Most Out of Finished Projects
Type: Process
Status: final
Version: 2008-05-19

Gist: Dustin Wax wrote an awesome article at the Lifehack web log. Topic: Getting Past Done: What to Do After You've Finished a Big Project
As it is significantly more stuff than fluff I will essentially post a link only, for once. However, you might like the following definition.

reflective thinking DEFINED AS active, persistent, and careful consideration of any belief or supposed form of knowledge in the light of the grounds that support it and the further conclusions to which it tends [that] includes a conscious and voluntary effort to establish belief upon a firm basis of evidence and rationality <- Dewey, J. 1933. How We Think: A Restatement of the Relation of Reflective Thinking to the Educative Process. Lexington, MA: Heath.

S1: Read: Getting Past Done: What to Do After You've Finished a Big Project <http://www.lifehack.org/articles/productivity/getting-past-done-what-to-do-after-youve-finished-a-big-project.html> and extract the questions.

S2: Answer the questions in a quiet moment. You could also use them for a guideline in a lessons learned meeting.
Note: Reflection is method of learning with scientific proof of its effectiveness.

S3: Prepare a checklist for future use on finished projects (or link here).

12 Helpful Rules for Refactoring a System

Name: 12 Helpful Rules for Refactoring a System
Type: Rules
Status: final
Version: 2008-04-25

Gist: to provoke 2nd thoughts if you are to take some part in a refactoring. Refactorings seem to come about more frequently these days, maybe because even the stolid of the business people start to talk about 'agile'. Like all these now-buzzwords, there's a lot of potential misunderstanding hiding in the very word.

Refactoring DEFINED AS modifying something without changing its externally observable behaviour with the purpose of making maintenance easier. Note that you can refactor many things, ranging from systems to architectures to design to code. However, relevant literature suggests that Refactoring is meant to relate to Design and Implementation. See Martin Fowler's Website. Also see Code Refactoring.

R1) Whenever you hear the word refactoring, run! 'just joking...

R2) Precisely understand what the various stakeholders think a refactoring is. You'll be surprised. Correct the wording if needed.

R3) Precisely understand what purpose the refactoring has, from each of the stakeholder's point of view. Align expectations before you start.

R4) Assume a great deal of resistance from the people who pay. Refactoring for them is another word for "Give me $$$, I'll give you what you already have! " Find out who will pay for maintenance.

R5) By all means reduce the risk of having a system with new bugs after the refactoring. This can be done by rigorous test driven or even behaviour driven development for example. Any change in behaviour should be treated as a bug.

R6) Challenge the business case (if any ...) of the refactoring. At least, do proper cost-benefit analysis. For example, the system may not live long enough to amortize refactoring.

R7) Prepare for the situation that nobody can provide exact and dependable information on how future budgets will be affected by the refactoring

R8) Back off from refactoring if significant portions of the code will be both refactored and worked over due to new requirements. Do one thing at a time and bear in mind R5.

R9) Prepare for 3 different points of view if you ask 2 people for what specific refactorings should be done.

R10) Think of short-term and long-term effects.

R11) The improvement must be both quantified beforehand and measured afterwards, at least for non-local changes to the system.

R12) Be suspicious if someone suggests only one or two specific refactoring techniques will suffice to reach a project-level goal.

5 Powerful Principles to Challenge Arguments

Name: 5 Powerful Principles to Challenge Arguments
Type: Principles
Status: final
Version: 2008-04-21

Gist: to provide a general checklist for the suspicious. The 5 principles show behavioural patters people use to make you do things in their favour, but not necessarily in your favour. Use this on (in alphabetical order) advisors, colleagues, consultants, counsels, managers, salespersons, vendors.

Sources: Scott Berkun: How to Detect Bullshit; and my all-time-favourite checklist: 12 Tough Questions by Tom Gilb.

P1) People are uncertain and tend to ignorantly stretch the facts.

• How do you know?
• What are your sources? How can I check them?
• Who told you that?
• Can you quantify the improvement?

Note: Carefully watch the answerer. If he needs a while, maybe uncomfortably shifting position, there's a good chance he's either making something up or needs time to figure out how to disguise a weak argument.

P2) People with weak arguments often have not made their homework on the topic.

• What is the counter argument?
• Who else shares this point of view?
• What are the risks of this, and what will you do about it?
• Can you quantify the improvement?
• How does your idea affect my goals and my budgets?
• What would make you change your mind?
• Have we got a complete solution?

Note: As from any facts, one can draw a set of reasonable interpretations, not just one. Everyone with intimate knowledge won't have great difficulties taking a different point of view for a while.

P3) People tend towards urgency when you are asked to make a decision with some hidden consequence.

• Can I sleep on this?
• When do we need to have a decision made? Why?
• I'd like to consult Person A first.
• Expert B, what do you think?

Note: People pressing ahead may try to throw you off your guard.

P4) People without a clear understanding of their point of view tend to inflate the language used.

• Please break this in smaller pieces, so I can understand.
• Explain this in simpler terms, please.
• I refuse to accept this until me, or someone I trust, fully understands it.
• Are you trying to say <...>? Then speak more plainly next time, please.

Note: Mark Twain once wrote in a letter to a friend: 'I'm sorry this letter is so long; I didn't have enough time to make it shorter.'

P5) People tend to have stronger arguments if they know someone is present who is hard to deceive.

• Use your network.
• Invite colleagues who have worked with these people.

Note: Simply help each other, like your family would do.

How to figure out what the problem really is

Name: How to figure out what the problem really is
Type: Principles, Process, Rules
Status: final
Version: 2008-03-27
Source: Don Gause & Gerald Weinberg, Are Your Lights On?; two own thoughts

Problem DEFINED AS difference between things as desired and things as conceived
Note: Don's and Gerald's original definition stated 'perceived' instead of my 'conveived'. I changed this due to some buddhism-oriented mindset of mine. Thanks to my friend Sven for reminding me.

Principles
P1) Each solution is the source of the next problem.
P2) Moral issues tend to melt in the heat of a juicy problem.
P3a) You can never be sure you have a correct problem definition, even after the problem is solved.
P3b) You can never be sure you have a correct problem definition, but don't ever stop trying to get one.
P4) The trickiest part of certain problems is just recognizing their existance.
P5) There are problem solvers and solution problemers.
P6) In spite of appearances, people seldom know what they want until you give them what they ask for.
P7) The fish is always last to see the water.
P8) In the valley of the problem solvers, the problem creator is king.

Process
S1) Ask: Who has the problem? Then, for each party, ask: What is the essence of your problem?
S2) think of at least three things that might be wrong with your understanding of the Problem. If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem.
S3) Test your problem definition on a foreigner, someone blind, or a child, or make yourself foreign, blind, or childlike.
S4) Generate points of view. Every point of view will produce new misfits between problem and solution.
S5) As you wander the weary path of problem definition, check back home once in a while to see if you haven't lost your way.
S6) Once you have a problem statement in words, play with the words until the statement is in everyone's head.
S7) Ask: Where does the problem come from? Who sent this problem? What is she trying to do to me? The source of the problem is most often within you.
S8) Ask yourself: Do I really want a solution?
S9) Ask Why 5 times. Normally this leads you to the essence of the problem.
S10) If a person is in a position to do something about a problem, but doesn't have the problem, then do something so he does.
S12) Try blaming yourself for a change - even for a moment.

Rules
R1) Don't take s.o. solution method for a problem definition - especially if it's your solution method.
R2) Don't solve other people's problems when they can solve them perfectly well themselves. If it's their problem, make it their problem.
R3) If people really have their lights on, a little reminder may be more effective than your complicated solution.
R4) If you solve s.o.'s problem too readily, he'll never believe you've solved his real problem.
R5) Don't leap to conclusions, but don't ignore your first impression.
R6) We never have enough time to do it right, but we always have enough time to do it over.
R7) We never have enough time to consider whether we want it, but we always have enough time to regret it.

Simple Solid Decision Making

Name:
Type: Process
Status: final
Version: 2008-02-01

Gist: how to make well-grounded decisions even if you cannot use Tom Gilb's Impact Estimation method for some reason (see Gilb, Competitive Engineering, Elsevier 2005). Decision making is the process of choosing a solution to a problem from a set of solutions, given a set of goals.

Sources: Stefan Brombach (http://www.dreizeit.de/), Kai-Jürgen Lietz (Das Entscheider-Buch, Hanser 2007), Tom Gilb, own thoughts.

S1: Make clear the goals of your endeavour. you need to understand what you want to achieve, what you want to keep and what you want to avoid. Consider using the Decomposing Goals principles.

S2: If you have many 'small' goals, say more than 12, then consider integrating some of them in a more abstract goal. Example: 'low costs for running the application' and 'don't exceed the budget' could be combined into a 'cost' goal. If you have to be quick and can't afford doing step S1 (please really consider doing it!) take the common three goals {time, scope, quality}.

S3: Compare each goal with every other goal. The more important goal gets a point. If you can't decide which one is more important, give 0,5 points to either goal. In the end, add 1 point to every goal for every goal has at least 1 point. Now you know the ranking of your goals in terms of importance.

S4: Go find at least three different realistic 'solutions' or ways of achieving your goals. You need three or more to have a little room for manoeuvres. Bear in mind, if you only have one solution there's nothing to decide.

S5: Using a 0..3 scale, iterate through all your solutions and goals and again give points to the solutions. 0 means solution X does not help achieving goal Y at all, 3 means it helps a great deal. Multiply these points with the importance of the goal from step S3.

S6: For each solution, add all products from step S5. The solution with the largest sum wins.

Decomposing Goals

Name: Decomposing Goals
Type: Principles
Status: draft
Version: 2007-12-21
Source: D. Doerner ('The Logic of Failure'), own thoughts

Gist: to explain why - for a complex, dynamic, interrelated endeavour - it is paramount to decompose global, complex, vague goals into specific goals.

Also see: Specifying Goals, Courses of Action

Definitions:
A global goal is a goal which has only few (one) evaluation criteria.
A vague goal is a goal which has only few (none) measurable evaluation criteria.
A complex goal is one that can be decomposed in two or more goals that are more specific.
An implicit goal is one you're not conscious of now.
Note: Quite often it is possible to say "problem" for "goal", as a goal is a problem turned upside down.

P1: Using a single word for a goal seems to imply that there is one thing the word stands for. Example: "User-friendlyness" Looking closer, we find that there ist no such one thing, it is composed of several other things (subgoals), like "percieved performance", "nice GUI" etc.
Note: This decomposition is subjective.

P2: The subgoals may contradict each other, like "percieved performance" and "wealth of functions". This is why we need to decompose the goal: otherwise we have a single goal which is in itself contradictory. This makes people feel uncertain and insecure.
Note: Often people don't know why they feel uneasy when confronted with such a goal.

P3: Subgoals usually will be handled in one to three different ways:
- dissection of central and peripheral goals, to be able to focus on the central ones
- dissection of important and urgent goals, also to be able to focus, but dependent on outside constraints like "deadline"
- delegation of the goal, to get rid of the difficult goal

P4: Conflicting (sub)goals get handled in two ways:
- finding a balance in reaching these goals, i. e. compromise
- ignoring one of the goals completely for the good of the others
- eupemistically re-arrange the whole system of goals, for the contradictions to dissappear ("if we had 'new' citizens...")

P5: Implicit goals can be uncovered by asking "What do I want to keep?" while aiming at some change.

P6: Confronted with a complex, global, vague goal, we usually find a (wrong) subgoal either because it seems apparent or because we are able to solve it. After a while this makes us feel even more uncertain, because we seem to not get closer to the goal.
Note: An apparent goal may not be the important nor urgent, and may be perpheral.
Note: In the IT world, this behavior surfaces as the confusion of means and ends. E. g., people think gathering data is the end, while it is a means to empower decion making. We usually do so because we feel secure in what we do.

P7: Confronted with a complex, global, vague goal, we proceed "ad hoc" in the sense we don't care for future problems caused by our problem solving. More uncertainty.
Note: "Ad hoc" has its advantage, it's better than doing nothing. This of course also is dangerous if we feel pressed to do something.

P8: Confronted with a complex, global, vague goal, we proceed "ad hoc" in the sense we ignore implicit goals. More uncertainty.

P9: Ultimately, feeling really uncertain and unsecure, we tend to dive deep into one of the goals and ignore the rest. This goal is the new holy grail.

How to give a project a good start

Name: How to give a project a good start
Type: Process
Status: final
Version: 2007-12-06
Gist: describes what to do as a manager to make sure that the project after it's finished will be seen as a success AND something of real value has been produced.

S1: Meet with a few of your management colleagues and talk about the project's goals until you reach a consensus.
S2: Gather a kickoff meeting with these colleagues and make everybody bring one or more workers who are supposed to do the project work.
S3: Be as precise and specific as possible if some of the workers ask questions.
S4: Be specific about the project goals or concrete deliverables you might want to see. Let the project work out project organisation and courses of action.
S5: Ask the workers to explain their understanding of your vision.

Note: Surprisingly, you might have a hard time finding a project leader to happily go along with this behavior, for he can't sell almost anything as a success for you.

Specifying Goals

Name: Specifying Goals
Type: Rules
Status: final
Version: 2007-12-20
Source: various authors, including D. Doering ('Die Logik des Misslingens')
Gist: to describe goals (of an organization, of an IT system, …) in a clear and useful fashion
Note: like always, goals are a kind of requirement. So it doesn't hurt at all if you use the rules to lower levels of requirements, e.g. system requirements.
R1: Seperate different goals, even if they seem interrelated, for you can reference them.
R2: Name each goal unambiguously, use a short name.
R3: use the PAM structure:
P urpose
A dvantage
M easure
Purpose: Supplies a higher level rationale for the goal. Understanding the why gives you freedom in finding proper solutions.
Advantage: Differentiates the goal from others and from non-goals. So you also know what NOT to achieve.
Measure: Keeps you on track and supports your communication with the higher management. Gives you a clear sense of 'done' and provides satisfaction at the end. Makes it possible to evaluate measures concerning suitability and effectiveness.
R4: Iterate! There's nothing bad about changing goals along the way. Please restate the set of goals, though.
R5: Avoid comparatives, work until you know what they really mean. Try decomposing a comparative goal into a number of specific goals.
R6: Mind if you specify positive (get to x) or negative goals (avoid y). A positive goal gives you fewer opportunities to succeed than a negative goal, which can be good or bad. Be aware of the possibility that someone states a goal negatively because he does not know how it can be stated positively. You're bound to fail, not within the scope of the stated goals but in the scope of the real goals. Negative goals tend to be too global.
R7: global and specific goals are good, unclear goals are bad. try to make a global goal specific, however. if your global goal is unsufficient and you cannot come to a specific goal, try stating intermediate goals that maximise the opportunity of success. How? By specifying many subgoals with a good chance of reaching them. another way to put it is: try to set goals so, that by adhering to them you will be in a better tactical position towards your strategy.
global: the future state is determined by few (sometimes only one) criteria
specific: the future state is determined by many criteria
unclear: the future state is not determined by a sufficient number of criteria
R8: be extremely suspicious if you seem to have only one goal. this situation is very rare and the phenomenon indicates you forgot a number of goals.

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.