Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Traditional IT governance typically focuses on a command-and-control, documentation-based approach. Teams are expected to adopt and then follow corporate standards and guidelines, to produce (reasonably) consistent artifacts, and to have those artifacts reviewed and accepted through a “quality gate” process. The following diagram overviews such a process for an IT delivery team – in practice we’ve seen several traditional governance lifecycles that were more complex than this and a few that had less quality gates.
Traditional governance strategies often prove to be both onerous and ineffective in practice due to the focus on artifact generation and review. For example, delivery teams will often produce required artifacts, such as requirements documents or architecture documents, solely to pass through the quality gate. The implication is that these artifacts often reflect what the team believes the governing body wants to see, and that may not be what the team is actually doing. The result is a governance façade that often injects risk, cost, and time into the team efforts: the exact opposite of what good governance should be about.
Lean IT governance, on the other hand, is a lightweight approach to IT governance that is based on motivating and enabling IT professionals to do what is best for your organization. Lean IT governance strives to find lightweight, collaborative strategies to address governance areas. It does this by focusing on risk mitigation, not on artifact generation, by leading people not by commanding them, and by enabling people by making the “right things to do” the “easy things to do”.
The following table compares and contrasts traditional and lean approaches to IT governance. The table also indicates where each governance area is addressed by the Disciplined Agile (DA) toolkit.
| Governance Area | Traditional Strategy | Lean Strategy | Disciplined Agile Implementation |
| Common roadmaps – What should we be doing as an organization? How should we be doing it? | Detailed technical and business architecture models
Architectural reviews to ensure conformance |
High-level technical and business roadmaps/models
Architecture owners embedded in teams Enterprise IT professionals work collaboratively with teams |
Product Management is responsible for producing and supporting business roadmap
Enterprise Architecture is responsible for producing and supporting technical roadmap |
| Decision rights and processes – Who is responsible for doing and deciding things? | Defined roles and responsibilities
Defined organization structure |
Teams are empowered with responsibility and authority to fulfill their mission
Defined roles and responsibilities Defined organization structure |
Self-organizing teams with appropriate governance
Robust set of agile roles defined for both delivery teams and for enterprise IT People Management is responsible for supporting creation of effective teams |
| Exception and escalation processes – How do we work together to address unexpected issues or problems? | Defined exception and escalation procedures
Defined roles and responsibilities Defined organizational structure |
Teams are empowered with responsibility and authority to fulfill their mission
Defined roles and responsibilities Defined organization structure |
Defined Enterprise IT workflow of DA 2.x
Self-organizing teams Teams are enterprise aware and expect to work with each other Defined roles and responsibilities |
| Governing body – Who is responsible for governing and how do they go about doing it? | IT Governance Team
(Optional) Topic specific (e.g. data governance, security governance) teams formed to address those specific issues |
IT governance team
Topic-specific governance is built into those processes |
IT governance team formed if and when needed
Enterprise IT teams self-organize to address topic-specific governance activities |
| Investment in IT – How can we spend money on IT wisely? | Quality gate(s) for assessing financial viability | Light-weight milestones
Continuous financial review |
Portfolio Management is responsible for making and monitoring IT investment decisions
Light-weight milestones: Shared Vision and Project Viability Product Owners are responsible for monitoring team finances Iteration wrap up includes explicit go-forward decision |
| Knowledge sharing – How can we learn together and promote common understanding across the organization? | Training and education programs
Coaching and mentoring Communities of practice (CoPs)/Guilds Centers of Excellence (CoEs) |
Same | Continuous Improvement focuses on sharing learnings across teams
Improve Team Process and Environment process goal Support for CoPs and CoEs |
| Metrics and monitoring – How can we gather intelligence to make better decisions? | Metrics gathering (automated and manual) and reporting
Status reporting Goal-Question-Metric (GQM) |
Automated dashboards
Manual metrics gathering (as needed, very limited) Light-weight GQM |
Automated dashboards (Development and Operational Intelligence)
Support for light-weight GQM Metrics and monitoring built into each process blade |
| Procedures and guidelines (guidance) – How do we do what we do? | Defined, and often comprehensive, guidance and templates | Critical guidance is captured in a light weight manner
Collaborative development of guidance |
Teams are enterprise aware and expect to follow appropriate guidance
Each process blade includes development of appropriate guidance |
| Quality – Is the quality of our IT assets sufficient? | Quality gates
Reviews Automated quality metrics Organizational guidance |
Automated quality metrics
Organizational guidance Build quality in from the start |
Quality strategies built into delivery process via Accelerate Value Delivery, Improve Quality, and Align with Enterprise Direction process goals
Reuse Engineering promotes ways for teams to rescue and reuse assets Enterprise Architecture promotes greater consistency across teams via common technical roadmap and strategy Data Management responsible for promoting greater data quality |
| Reward and compensation – How do we recognize the work of our staff and pay them appropriately? | Human Resources (HR) program for IT | Same | People Management addresses reward and compensation strategies |
| Risk mitigation – Have we taken on an acceptable level of risk given our current situation? | Risk monitoring via status reporting and reviews of artifacts | Risk monitoring via automated dashboards and close collaboration with teams | Portfolio Management process blade addresses IT-level risk
Identify Initial Risks and Address Risk process goals build risk mitigation right into delivery process Risk-based milestones built into delivery lifecycles |
| Roles and responsibilities – Who does what? | Many narrowly defined roles
Roles and responsibilities are well defined |
Fewer, more widely defined roles
Roles and responsibilities are defined |
Delivery team roles and responsibilities defined
IT roles at scale defined |
| Status reporting – What is going on? | Regular written status reports
Automated dashboards |
Automated team dashboards
Automated portfolio dashboard |
Automated dashboards (Development and Operational Intelligence) |
Related Reading:
- What is Lean IT Governance?
- Why Lean IT Governance?
- What is Agile Delivery Governance?
- Strategies that Enable Agile Governance
- Supporting Agile Delivery Team Governance
Posted
by Scott Ambler
on: April 20, 2016 06:49 AM |
Permalink