Project Management

Lean IT Governance: A Goal-Driven Approach

From the Disciplined Agile Blog
by , , , , , ,

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Disciplined Agile Certification Training Goes Virtual

Videoconferencing Tips - How to Have Effective Calls

Examining the differences between DA and existing PMI materials

Spotlight on Product Portfolio Funding

Spotlight on Optimizing Flow

Categories: Governance

Governance is a common thread throughout all aspects of the Disciplined Agile (DA) toolkit. Delivery governance activities were built right into Disciplined Agile Delivery (DAD) v1.x, each of the process blades include a governance process factor, and there is an IT Governance process blade that coordinates all IT governance activities.

The following process goal diagram overviews the potential activities associated with a disciplined approach to IT governance.  These activities are typically performed by a variety of people within your organization. In DA each of the process blades includes activities around governing the activities encapsulated by that blade. For example, the Enterprise Architecture blade includes architectural governance activities and the Data Management blade includes data/information governance activities.

Disciplined Agile IT Governance

The process factors that you need to consider for IT governance are:

  1. Governance view. There are many potential aspects, or perhaps subsets, to IT governance including security governance, data governance, delivery governance, and more. Too many organizations make the mistake of treating each of these issues separately, which is easy enough to do given the different focus of each one. The Disciplined Agile toolkit promotes a more holistic, integrated view that results in a streamlined, consistent, and effective governance strategy. Another common mistake is to focus on portfolio governance over other aspects and have your Portfolio and Project Management Office (PPMO) be responsible for IT governance. PPMO-led governance efforts tend to result in documentation-heavy, bureaucratic strategies instead of lean, risk-based approaches.
  2. Develop metrics. Metrics define the measurements that you will take to gain insight into what has happened, what is happening, and hopefully what may happen in the future. The least effective approach to metrics is to have a standard set that all teams are expected to collect whereas the most effective is a context-sensitive approach such as a light-weight implementation of Goal Question Metric (GQM).
  3. Measure. The measures themselves can be collected either manually or automatically (usually as the result of tool or system usage). We have found that a combination of the two is required – although automated metrics are inexpensive, accurate, and real-time you cannot always automate all of the measurements that you need to collect.
  4. Monitor. Information radiators are sufficient in smaller organizations, but automated dashboards in combination with direct interaction with teams are also needed in modern enterprises. Traditional strategies, such as status reports or status meetings, do not prove to be effective in practice nor do they provide an honest assessment of what is actually occurring.
  5. Guidance detail. An easy and important way to support governance within your organization is to have commonly accepted guidance, including standards and guidelines, for teams to follow. We suggest that you keep this guidance lightweight, starting with high-level rules but aiming towards principles whenever possible.
  6. Develop guidance. Guidance is ideally developed collaboratively with a combination of practitioners and experienced enterprise IT professionals who understand the bigger picture.
  7. Define roles and responsibilities. The definition of roles and responsibilities is an important aspect of your overall governance strategy as it describes what is expected of people. We’ve found that the most effective way to do this is to start with the roles and responsibilities described in the Disciplined Agile (DA) toolkit and then collaboratively evolve them from there. The framework ha both delivery team roles as well as enterprise IT roles defined.
  8. Manage IT risk. Risk management for the entire IT portfolio, including both in-progress development teams as well as operational risks. Small risks on individual teams can add up to a large risk across your organization. For example, if many teams adopt a new and relatively unproven framework and that framework is then abandoned by its creators (think about how many open source projects or new companies flounder) then you have a serious problem. Similarly, when multiple teams start addressing a similar business opportunity and that line of business dries up or is legislated away.  Although risk management is addressed on delivery teams via the goal Address Risk, their focus is on risk management within a team as opposed to risk management across all of IT, or even across all of your organization.

Related Reading:

Posted by Scott Ambler on: May 24, 2016 03:53 PM | Permalink

Comments (0)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.


"This planet has - or rather had - a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which is odd because on the whole it wasn't the small green pieces of paper that were unhappy."

- Douglas Adams