Monthly Archives: September 2016

Recording decisions

In my experience, something that is commonly overlooked, or undervalued, is the trusty Decisions Register. This is a simple artifact, which can be stored by your project manager or yourself, perhaps in the same spreadsheet as the risk register, or on a page in your team wiki.

It’s interesting to consider why a decisions register is not commonly used. Many people don’t want to take responsibility for decisions, or are too shy to document that someone else made the decision, because it seems like we’ll blame them if the decision wasn’t right in the long term. However, it’s really not about that.

It’s value comes into play in a few situations:

1. In the long-term, or throughout the life of the project, people will come and go

To prevent the same questions being discussed at length by different people, the decision can be recorded when it is made, with an explanation of why it was made and who was involved in making the decision.

This isn’t about blaming the person who made the decision, or locking in a requirement, should it need to be discussed and reviewed in the future. Stuff changes, and that’s OK. However when people move on that were key to that decision, new people can often spend hours, days or weeks debating why a decision was made, wasting incredible amounts of time.

2. Your project is showing signs of an underlying issue through constant requirement or design changes

If one of your stakeholders is making continuous changes to the requirements or design, chances are you’re coming up against a deeper issue. A decision register can be useful in this situation, because it can show a history of the changes.

Perhaps the architect is constantly re-architecting a solution because they are being pushed to implement “quick fixes”, leading to a lot of re-work and changes to the design decisions. Or perhaps your business stakeholder is constantly flipping on his/her decision because they really just don’t know what they want. Having this recorded can enable you to call out and address the real issue – in the above cases the pushing to implement quick workarounds which are ending up costing more than a well architected solution, and a poorly defined requirement with little basis for a solid decision which needs a deeper investigation into the reasons behind the requirement.

3. Your project has a lot of stakeholders that aren’t co-located

When staff aren’t located right near each other, people start to talk to those closest to them and start making decisions between themselves. It takes a special effort to get people in different locations to collaborate to make a decision, and sometimes decisions can’t wait for everyone to call in to a group meeting or workshop.

Having a decision register on a wiki that everyone is subscribed to enables people to be automatically notified whenever a decision is recorded. When used properly, the team can record all decisions that affect the larger project, and everyone gets notified automatically.

It’s not about finger-pointing

Now I could say that a decision register also helps in the situation where a client or stakeholder change their mind about a requirement. And it can. However it’s important to understand why that stakeholder wants to change the requirement. Is it because the requirement has genuinely changed? If so, you’ll need to revisit your requirements. That’s what being agile is all about – change is inevitable. Or is it because the person has forgotten why the requirement was there, or the team can’t remember who made the decision? Well that’s a set case to refer to the decision register and explain the reasons why the requirement was set. This can save loads of re-work and time and help to keep your project on track.