Good Risk and Bad Risk

Bruce Tate writes about this in his book “From Java to Ruby“. But what does this mean?

If you are running projects or are managing a team/company (for that matter), you have been told to manage risk(s). Chances are good that you also have been told that risks should be avoided or at least mitigated. Therefore risks are bad, aren’t they?

Well, there is an economic saying: “stagnation mean regression”. This means you need to progress and you need to do new things to do so.  So you go for chances. This in turn implies that you take some risks in order to gain (economic advantage). In general you take the more risk(s) the higher your gain may be (unless you run into a rare lucky case).

So taking risk(s) is good and important after all?

It sure is. However you need to know what you do, you should take those risks intentionally (instead of accidentally).

That is what risk management is all about.

What is Common Sense after all?

So, what is Common Sense or as we Germans say “Gesunder Menschenverstand”?

According to Wikipedia Common sense is what people would agree in common.

What does that mean? I think Common Sense is what a group of people have learnt or experienced and now know implicitly. It is what they intuitively think is right.

Ken Schwaber say

Common Sense is a combination of experience, training, humility, wit and intelligence.

in his book Agile Project Management with Scrum.

If learning and experience is part of this thing, can we learn Common Sense? On one hand, Common Sense seems more than knowledge. On the other hand let’s look a bit on the phases of learning:

  • First there is unconscious incompetence: I do not know that I don’t know (e.g. kids are not aware that they can not drive a car).
  • Then comes conscious incompetence: I know that I don’t know (This feels like sitting in a car’s driver seat for the first).
  • Then comes the learning work leading to conscious competence: I know that I know (For the first couple of month driving a car, I do everything very conscious).
  • Last phase is unconscious competence: I don’t know that I know (I do not have to think when driving a car)

By the way is there a similar though slightly different concept in eastern philosophy called Shu-Ha-Ri.
The elements we have learnt and that are part of our unconscious competence (or we are in the Ri state for that matter) portfolio basically build our paradigms (another of those big words). Those paradigms in turn are part of our Common Sense.

So a part of what we see as Common Sense is actually what we’ve learnt and experienced (particular in interaction with others).

On the other hand only things that really work and are easy to comprehend will make it to our Common Sense. This would exclude complex processes or artificial prescriptive instructions.

Hey, what is this crap good for, now? First, this was not the question here…

Second, there might be another post…

Another interesting question though is: can we unlearn or “overlearn” things? Or to state it in another way: How does the (our) Common Sense change over time?

InfoQ Interview on Lean

The guys over at InfoQ have an interview (video) with Mary and Tom Poppendieck on Lean online.

The explain the heritage of Lean as well as the basic principals applied to software development in general and product management in particular. They explain some of the seven principles:

  1. eliminate waste
  2. amplify learning
  3. delay commitment
  4. deliver fast
  5. build integrity (in the product)
  6. engage the intelligence of the people involved
  7. optimise the whole system

They discuss some of those principles in more detail (my favourite one is the discussion on late decisions). They are positioning Lean to Scrum, RUP and CMM. They also have a open discussion on the constraints of applying Lean principles (I particularly liked the statement about the level you have to aim for and the discussion about Lean under contract).

You might also want to check out the Poppendieck’s website.

Done or not done: that is the question

“How far are you with this task?”. This question is quickly asked and chances that you get an answer like “we are 80% done” are very high.

Does such an answer really makes sense? How do humans assess the progress of a task? According to the Pareto principle we might need 80% of the effort to fulfill the last 20% of the task, but most likely we perceive this differently (more linear). So even if we have the best intentions, the human brain is being tricked here.

So what are the options?

There are a couple of ways to report the completion of a task (see e.g. Rob Thomsett: Radical Project Management):

  • binary (0-100): Either a task is finished or considered as not yet started
  • binary (50-100): As soon as a task has been started, it is considered as 50% done
  • linear: If a task is scheduled to take 10 days and 8 have been spend on that task it is 80% done. This is the Microsoft Project way
  • subjective: Most often used in ad hoc reporting. The team is asked and tells their gut feeling (more or less)

The advantage of the binary strategies is that you are not tricked by the nonlinearity of things. There is no false security of having plenty of time.

And there is another positive effect: Designing tasks to be suitable for binary evaluation. By the team being aware that a task is either done or not, they will most likely start to design tasks that are actually suited for this approach: Not too big but still one entity. However it is very critical to resist the tendency of making tasks too small (to get them done quickly). Unfortunately there is no rule of thumb of how long a “standard” task should be (do not trust anybody who states otherwise).

There is another very important aspect to this: Defining the task in general and the criteria of completion in particular is key. As said above, a task needs to be a kind of atomic effort. You should not confuse this with an artifact or deliverable. A task can be a part of an unfinished deliverable but needs to have clear completion criteria.

Binary reporting also prevents micro management. The team will report the task done, when it is done. Asking beforehand does not make much sense as the binary answer is not done yet (either 0% or 50%). Having said this, it is the responsibility of the person or team that owns the task to escalate in time when they see a risk of not being able to complete the task in time.

Whatever you do, always remember to keep a buffer in project planning… But this might be another post.

Update 2007-03-01:  Johanna Rothman has a post on this topic: There is not such a thing as Percent complete.

Dimensions of a project

There are a couple of factors that define a project. Usually you have three or four of them. So what are those?

* Scope
* Cost
* Time(line)
* Quality

Why are they key? They are highly coupled (think rubber bands) and modifying one of them changes the other dimensions as well.

You say this is common sense? IMHO you are right.

However, if you try to communicate changes in one dimensions (aka change requests) and mention the consequences for the others, even seasoned project managers seem to forget this…