I first wrote about governance of Agile projects three years ago, when I was developing a governance approach at a DSDM development site. That work, and the work I have done elsewhere since, have further convinced me of the basic ‘correctness’ of that theory. I presented that theory at the Agile Business Conference that same year to a very interested audience.
Fast-forward to the present day and I was recently invited to attend a meeting of the APM Special Interest Group (SIG) on Agile Governance. The APM are working on a Guide on this topic and are keen to elicit opinion and insight from far and wide. When the meeting broke up into break-out groups, I attended the one focussing on the Principles – the one where I thought I could be most helpful. The principles I put forward are what I believe to be some of the guiding principles by which an Agile governance authority – however that is manifested in your organisation (perhaps the PMO, perhaps a separate body) – ought to run the portfolio of projects. They are, in no particular order :
- People and accountability. Good governance comes from having the right people accountable for delivery, and the quality of the solution delivered. I have blogged before about the need to have the companies Security Officer (or equivalent) responsible for application security and to be accountable for the security of any application development being implemented. Similarly, Marketing should be accountable for the look-and-feel of a web-site development. And the Governance Authority should be people who have no vested interest in the outcome of the project – but they are accountable only for ensuring that it is conducted properly. If, for example, the person responsible for managing the governance process is accountable to the Head of delivery, governance will achieve only what is in the best interests of the Head of delivery. If he/she is paid to deliver more projects, then more projects will go live, even bad ones.
- Ensure projects are adequately resourced. No project should start unless it has the resources (people, knowledge, skills, tools, equipment, etc) to ensure at least a realistic chance of success. There are no guarantees in life, but every project needs to be given every chance to succeed, and starting a project with only half the people it needs – or with poor equipment, a lack of meeting space, or anything else a successful project needs – is the road to failure.
- Scale the governance to the project/programme. Avoid unnecessary bureaucracy, but ensure the project is under control. Good agile governance should promote agility by encouraging good agile practice. But such practices and the controls around them need to be adapted to the needs of a project and the people working on it. For example, the governance of a year-long project developing an entirely new product line and all the attending infrastructure needs to be governed differently to one involving a two-month long enhancement to a web site.
- Review viability frequently. Consider whether all the elements that contribute to success are still in place all the way through a project. One way to do this is to review at every iteration boundary (or every Steering Group meeting) whether the project is still on track to meet the business case, achieve it’s vision, and deliver the planned scope on time and within budget. Consider whether the direction or solution design changed significantly. What happens, for example, if one key person leaves, and takes a few of his friends with him? Is the project still viable? Probably not, and that needs to be recognised and addressed. The job of Governance is to highlight the issue and assist the project team to resolve it.
- Transparency. Ensure all pertinent information is widely available – on walls, dashboards, etc. It should be the responsibility of governance to ensure a project team are not hiding any bad news. All stakeholders should be aware of the true status of the project, which leads onto…
- Fact-based reporting. Measure real progress, through delivery of valuable solution components at regular intervals. “We are 80% finished” means nothing unless that 80% can be (or has been) tested and, if necessary, implemented. Don’t measure progress by the subjective reports by PMs, so typical of most organisations – they are not always reliable.
- Do ‘just enough’ planning throughout. This can be considered more a project management principle than a governance one, but it is also the job of governance to encourage speed to market, and early benefits realisation.
- Ensure adequate contingency is available. Whether in time, cost or scope, different projects need to fix different elements of that triangle. Governance should check that sufficient contingency exists on an appropriate axis/axes.
I don’t know whether any of the above will find their way into the APM Guide, but I may soon be able to refine these further and put them into practice myself once again. Watch this space.