Posted by James King on July 24, 2010
When auditing a project (or taking over a project or even taking on a senior role in a team) I like to go and talk to everyone in the team.
When I do, I generally ask them the same questions to get a better feel for what is going on.
I really liked a set of questions I picked up from a book called “The First 90 Days”, so I use a modified set of them:
What is your role?
- What does that mean?
- How would you explain it to my mother?
- How would others explain what you do?
How confident are you the project will meet it’s objectives?
- What are the objectives? Really?
- How clear are you on the objectives?
- What do management think the project is doing?
- What do others think?
- If it fails, where will it probably have gone wrong?
What is the biggest issue facing the project?
- What would happen if we could get rid of that problem?
- What would need to change to get rid of it?
- How could we deal with that problem?
- How is it impacting us/the project? How does it impact you?
- How are we currently dealing with it?
- Why is it still there? What is stopping us deal with it?
- What should we do about it now?
What is the biggest unexploited opportunity in the team?
- What would have to change for us to exploit it?
- What would happen if we did?
What would you do if you were me?
Most projects are really really complicated. But most people know how well it is going or how scary it is if they have time to think about it. So I find you get a pretty good overall understanding if you just ask everybody these questions.
Posted in Investigation, Reflection, Risk | Leave a Comment »
Posted by James King on July 24, 2010
I was talking to a colleague recently and promised to share some of the questions I ask when auditing a project (or taking one over).
My first question is generally “what is the project about?” But that generally leads to a vague answer. So I use my “question compass”:
My question compass
These are the questions I use to get a basic orientation when analyzing just about anything. By way of explanation though, I don’t always use the exact wording shown.
When asking “what do you mean” I use a technique that sounds really simple and is surprisingly effective – the “nouns and verbs” technique.
I listen for a noun in a sentence and then ask “what do you mean by ‘noun’?”. When I get a response I ask about one of the verbs in the response “How do people currently ‘verb’?” or “How do you envision people will ‘verb’”.
I keep doing this for a little while even if I think I know what people mean because it is amazing how often it clarifies my understanding. Then I pick one of the things the person said and ask “why are we doing this project?”.
I do use the famous 5-whys technique to probe more deeply (ie ask why several times) but I also add the question “why else?”.
I was once told that we do things for two reasons – the right reason (the one we tell people) and the real reason. I think it is a quote from someone famous. But it certainly clarifies my thinking when I ask this question.
My next question is “Is that true?” and I ask this one in a number of ways:
- What would the team say the purpose is if I asked them?
- Do all the steering committee share the same understanding?
- How do you know that is true? How do others know?
- How would you know if that was not the case? (my favourite question).
Almost there – but I still have one last question – “So what?”. Like asking if something is true, asking so what can seem a bit blunt. So I ask it in a couple of different ways:
- What impact is that having?
- What would happen if we didn’t do it?
- What would the impact be over the long term if we don’t do it?
- What will happen if we do it? What else will happen? What won’t happen?
- What are you hoping won’t happen if we do that?
- What will the team/customer say when it happens?
After these questions I generally at least have some idea of what is going on – which is often the best place to start.
Posted in Investigation, Reflection, Risk | Leave a Comment »
Posted by James King on April 5, 2010
We set up a stand at the recent Software Development Conference to run the Agile Release Planning Game I designed.
It seemed to go down really well, so I have decided to make the game available publicly if anyone is interested in using it.
In the game, participants are a group of scientists and engineers who are stuck on Mars after a “less than successful” landing. They are on a mission to make scientific discoveries but must now rebuild a basic infrastructure for survival before returning to their original mission.
Participants then create a strategy based on rebuilding their ship, building a base and/or returning to their basic goal of research. In doing so they must make trade-offs between quality and velocity.
The game introduces concepts such as release planning, iteration planning, velocity, release planning trade-offs, building by feature and adaptive planning.
The game is designed to be led by a facilitator, but can be run without one. The release planning game takes around half an hour to play and can be replayed multiple times to explore different concepts in more detail or to improve the outcome based on lessons learned in the first attempt.
Different options allow the game to be played as a very simple introduction to the concepts of release planning or a more complex game involving more realistic trade-offs and decision making under conditions of uncertainty and pressure.
In addition, there is an extension included in the game that focuses on planning within the iteration (or sprint) rather than across the wider release.
Let me know if you are interested in learning more, or even trying the game for yourself.
Posted in Capability growth, Decisions, Events, Games, Products, Risk | 6 Comments »
Posted by James King on September 21, 2009
We all know that managing risk is important. In fact, Graham Downes recently suggested (in a comment on this blog) that the best way to stop eager young project managers from being “blown up” is to teach them to better manage risk.
But even when they manage risk actively, I see a lot of teams rating the cost of a risk blowing up on them as “TBA” (ie – to be advised … ie we don’t know).
Some projects even end with a whole pile of risks listed as high impact with a dollar impact of TBA.
If this is the case, then possibly it is better to not worry about having a column in the risk register to cover dollar impact. Instead, focus on making the impact relevant and real to the team.
I do like to rate the dollar impact of my risks and like other people I often don’t have the time to assess the dollar impact of every risk properly. But I do like to rank my risks by dollar impact to have a look at the scariest ones.
So what I do is allocate a cost to the risk on a scale of really bad to really trivial. I do this as follows:
- Decide on what would represent a huge cost in the context of the project, one that makes it worth canning the whole project. I often do this by simply doubling the budget of the project.
- Assign this dollar value as “category A”. So for example if $10m is a really scary figure for the project, then “A” means “any risk whose impact could have an impact of over $10m”.
- Then assign category B, category C and so on to smaller numbers so that you have a scale with wide ranges for each letter. It might look like this – A = greater than $10m; B = $2m – $10m; C= $500K – $2m; D=$100k – $500K; E= $20K – $100K; F= $5K – $20K and so on.
- Eventually you will get to amounts that are small enough to agree not to worry about them as risks.
The trick is to have broad ranges so that it is easy to guess where a risk should fit. The mathmatically pure among you may notice that a risk could fall into category A and B if it is exactly $2m. I claim this doesn’t matter and that you should in this case assign it to the higher category.
Adding a scale for risks allows the team to assign a (very) rough dollar value without too much analysis, yet allows you to categorise risks as really scary or not so bad.
This, I think, makes it easier to deal with the bulk of the risks. Of course you can still assess the dollar impact of certain risks in more detail if appropriate.
Posted in Risk, Techniques | Leave a Comment »
