Lean IT Governance is the leadership, organizational structures and streamlined processes to enable IT to work as a partner in sustaining and extending the organization’s ability to produce meaningful value for its customers. This article addresses several topics:
- What is Lean IT governance?
- Why Lean IT governance?
- The lean governance mindset
- Lean governance strategies
- The Process
What is Lean IT Governance?
As with most things in IT, there is no standard definition of what IT governance is. For example, the IT Governance Institute provides this definition:
“IT Governance is the leadership, organizational structures and processes to ensure that the organization’s IT sustains and extends the organization’s strategies and objectives.”
Gartner, on the other hand, offers this definition:
“IT governance (ITG) is defined as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals. IT demand governance (ITDG) is the process by which organizations ensure the effective evaluation, selection, prioritization, and funding of competing IT investments; oversee their implementation; and extract (measurable) business benefits. ITDG is a business investment decision-making and oversight process, and it is a business management responsibility. IT supply-side governance (ITSG) is concerned with ensuring that the IT organization operates in an effective, efficient and compliant fashion, and it is primarily a CIO responsibility.”
In Disciplined Agile, we promote the following definition:
“Lean IT Governance is the leadership, organizational structures and streamlined processes to enable IT to work as a partner in sustaining and extending the organization’s ability to produce meaningful value for its customers.”
As you can see in the following diagram, IT governance is part of your organization’s overall corporate governance strategy. IT governance encompasses several more narrow forms of governance, including but not limited to the governance of IT delivery/development, data/information, IT security, IT investment, enterprise architecture, and IT operations activities.
IT governance typically addresses areas such as:
- The effective and timely investment in IT to sustain and extend the organization over the long term
- The evolution and support of roles and responsibilities to streamline how people work together
- Definition of decision rights and decision making processes to streamline interactions between people
- The evolution and support of common procedures and guidelines to ensure appropriate commonality of activities and artifacts
- The evolution and support of common roadmaps to guide the efforts of IT teams
- The monitoring of activities to provide insight into their effectiveness
- Formation of a governing body that is responsible for guiding governance activities
- Definition of exceptions and escalation processes to streamline critical interactions
- Creation of a knowledge sharing strategy to grow individuals, teams, and the organization as a whole
- The support and monitoring of risk mitigation strategies to promote appropriate and holistic adoption of IT solutions
- Adoption of a reward and compensation structure to support the attraction and retention of excellent staff
- Status reporting to share information throughout the organization
Why Lean IT Governance?
Lean IT governance is the leadership, organizational structures, and streamlined processes to enable IT to work as a partner in sustaining and extending your organization’s ability to produce meaningful value for your customers. There are several reasons why this is important for your success. Lean IT governance strives to ensure that:
- Your organization’s IT investment is spent wisely. Organizations invest in IT to enable them to run and extend their business. From a financial point of view, your goals should be to regularly and consistently create real business value and to provide appropriate return on investment (ROI). To do this you must determine how you will execute your strategy by selecting and prioritizing the most valuable initiatives to undertake. You must also monitor these initiatives to ensure that they fulfill their promise, and if not then remediate them appropriately.
- Your IT strategy supports your organization’s needs. Your IT efforts should deliver consumable solutions in a timely and relevant manner AND operate and support those solutions once in production. Part of your IT governance efforts will be to ensure that this is actually happening in practice.
- Your IT teams are empowered to carry out their work. An important aspect of IT governance is to ensure that people and teams have the authority to fulfill their responsibilities. Many agile transformations run into trouble when the roles and responsibilities of people are not agreed upon, or when they are they are not properly supported by senior management. Another important strategy is to empower teams to own their process, to self determine how they will work together, enabling them to tailor their approach to meet the needs of the situation that they face.
- People are motivated to work together effectively. There are several aspects to this. First, IT teams need to work effectively with their stakeholders. For this to happen in practice IT professionals need to understand the fundamentals of the business domain that they are working in and business stakeholders to understand the fundamentals of IT. Second, IT teams also need to work effectively with their IT colleagues. To do this you must adopt processes and organizational structures that encourage people to collaborate together and to learn from one another. Third, stakeholders need to work together effectively when it comes to IT. Your organization has limited resources to invest in IT, so it behooves your IT department to work with stakeholders to invest those resources wisely. Doing so are important aspects of your Portfolio Management, Product Management, and of course your Lifecycle efforts.
- Risks are monitored and mitigated at appropriate organizational levels. Although team-level risk mitigation is a good start it isn’t sufficient from an organizational point of view. Many small risks that are acceptable individually can add up to a very large risk for your organization. For example, one team using a new technology platform is an experiment. Fifty teams adopting that new platform at the same time is a significant risk if the platform proves to be problematic. Someone must be looking at risks from a portfolio perspective and guide teams accordingly.
- Your IT infrastructure is sound. Your IT department must be able to operate and support solutions that are in production over both the short and long term. Your IT governance effort should guide and monitor your teams to ensure that they leverage and evolve your IT infrastructure effectively.
- IT works in an open and collaborative manner. There are several ways that the DA toolkit promotes this. First, IT solution delivery is performed in an agile manner that is inherently open and collaborative. Second, all IT teams should present accurate and timely information to stakeholders, not just solution delivery teams. For example enterprise architects can make their work available to everyone, as can your portfolio management team, your data management team, and so on. Third, stakeholders can and should be educated in the fundamentals of IT so that they better understand how to work with IT teams. Fourth, IT professionals should be educated in the business domain and fundamental business concepts so that they can interact more effectively with stakeholders and understand how to serve them better.
- All of these things will continue to be true now and in the future. Lean IT governance balances your short-term and long-term needs. Too many organizations have allowed technical debt to grow in recent years, for the skills of their IT staff to stagnate, and to continue to tolerate traditional IT process strategies from yesteryear. This is because they allowed short-term priorities to trump long-term health. We must do better.
There are two fundamentals reasons why IT practitioners should be interested in lean IT governance:
- You’re being governed, like it or not. Regardless of the size or your organization, the length of time it’s been in operation, or the sector(s) in which you work, someone is keeping an eye on and guiding your IT efforts.
- You deserve to be governed effectively. Sadly, as we’ll explore in the next posting in this series, most IT governance strategies prove to be ineffective in practice due to application of traditional strategies and ways of thinking.
The Lean Governance Mindset
The mindset required to govern IT in a lean or agile manner is very different than the traditional mindset. The following are key aspects of a lean governance mindset:
- Lead by example. People take their cues from their leadership teams. If your governance strategy is streamlined and light weight then whatever it governs will inevitably become streamlined and light weight. Conversely, an onerous and heavy governance strategy will lead to onerous and heavy strategies by those being governed.
- Be a servant leader. The primary function of governance people should be to prevent roadblocks, and if not to get rid of them as soon as they arise. You should strive to get teams the resources that they need and then get out of the way. Wait a minute, isn’t that the job of the Team Lead on a Disciplined Agile Delivery (DAD) team? Yes, but who do you think that they work with to actually get that done?
- Motivation over management. IT professionals are intellectual workers, and intellectual workers generally don’t respond well to being told what to do. But they can be motivated, and once motivated will actively work on what they’ve been motivated to do. So motivate them to do the “right thing”. One way to do this is to communicate very clearly what your organization is trying to achieve. Another way to motivate people is to ask tough questions such as: What value is there in doing that? What can we do to increase value? How can we eliminate waste in what we’re doing? and What will we learn by doing that?
- Enablement over audit. Psychology shows that people, when given the choice, will usually take the easy path. This tells us that if we want people to do something, or to work in a given manner, then if we make it very easy to do so then they likely will. For example, if you want developers to follow common coding conventions then provide easy to understand and straightforward guidelines. Better yet, provide code analysis tools that they can include in the continuous integration (CI) tooling that provides feedback that they can act on. The traditional approach would be to rely on code inspections or code audits to ensure that conventions were being followed. This approach is not only onerous, and thus less likely to be followed, it has a long feedback cycle which means that any feedback resulting from the audit will be much more expensive to act on (on average) than the code analysis tool which has a very short feedback cycle. Yes, you may need to run the occasional audit, particularly when you’re working in a regulatory environment, but you should do so only as a last resort.
- Communicate clearly, honestly, and in a timely manner. Effective governors communicate what the priorities of your organization are and what is expected of people. It is crucial to set realistic expectations in an open, honest, consistent, and continuous manner.
- Streamline collaboration. Governors should help teams collaborate effectively with others. This not only helps them to achieve their goals but also supports enterprise awareness.
- Trust but verify. Agile is based on trust, but to ensure that the right thing is happening within your organization there needs to be verification of that. Governors can do this by monitoring teams via several strategies. These strategies include asking people what’s going on, automated metrics (via team dashboards), looking at information captured by information radiators, attending team demos, and as a last resort asking teams to produce status reports to address questions that can’t be answered via automated metrics.
- Focus on mitigating risk, not just reviewing documents. A primary goal of your governance strategy should be to mitigate risk. Sadly, many governance strategies have fallen into the bureaucratic trap of relying on documentation reviews to provide insight into what a team is doing. For example, your “architecture quality gate” might be based on the review and acceptance of an architecture model or document, the idea being that if some knowledgeable people assess the content of the document they will be able to determine whether the described architecture strategy will work. Unfortunately this isn’t the case. We’re sure you’ve seen several IT project teams who had a well-documented architecture, which was reviewed and signed off on, yet the technologies didn’t work well in practice, or perhaps they didn’t perform well, or perhaps they didn’t even integrate easily. The only thing that the review and acceptance of a document tells you is that a document was created, reviewed, and accepted.
- Learn continuously. Good governors learn as much as they can about what they’re governing so that they can make better decisions and can make effective suggestions to the people being governed.
- Consider both the long and short term. Governance must balance short-term needs with the long-term strategy of growing and enhancing your organization.
- Be a great host. People who have fun at work, who enjoy what they do, are much more productive than people who don’t. In this respect being an effective governor is like being a good host at a party — as host it’s your job to see that everyone has a good time and gets along well with each other, and to swiftly deal with any problems that arise.
Having a lean governance mindset, as described above, helps you to increase your effectiveness at governing IT.
Lean Governance Strategies
There are several strategies that you can adopt to promote a lean approach to governance. These strategies include:
- Empowered teams. Teams should have both the authority and responsibility to fulfill their mission. Agile teams should be allowed to be self organizing, the implication being that the team itself determines who will do what work (the team doesn’t have a manager telling them what to do). Related to that the team should own their process, which is the agile way of saying that the team is allowed to determine how it will work together and as the team learns it will evolve the process that it follows — of course the team will be guided and constrained by your organization’s governance strategy.
- Enterprise awareness. One of the principles of the Disciplined Agile (DA) toolkit is that you should work in an enterprise aware manner. It is based on the observation that your team is only one of many teams, so therefore you need to consider the bigger picture when you’re working and do what is best for your organization, not just what is convenient for you. Promoting enterprise awareness throughout your organization is a fundamental enabler of lean governance.
- High-level roadmaps. High-level technology and business roadmaps, produced by your Enterprise Architecture and Product Management efforts respectively, will provide important guidance to your teams. These roadmaps capture the vision as to where your organization is heading, helping teams to understand what the overall vision is, to focus on what is important to your organization, and to help guide and constrain their decisions.
- Collaborative enterprise IT professionals. The DA toolkit includes several process blades, including Enterprise Architecture, Product Management, Data Management, and others that address IT-level concerns. The people performing these activities should work closely with their customers, the delivery teams and stakeholders, in a collaborative and evolutionary manner. This promotes better governance for two reasons. First, by getting the vision, knowledge, and skills of the enterprise professionals into the hands of their customers it increases the chance that they work in a manner that is consistent to the needs of your organization. Second, the enterprise professionals want to get feedback from their customers and learn more about what their customers need from them. This enables them to be more effective at serving the enterprise and guiding their customers.
- Enterprise IT knowledge in teams. Although roadmaps and enterprise IT professionals collaborating with development teams help, it is far more effective to have people with enterprise knowledge embedded within the development teams. This is why we promote the idea that Architecture Owners (AOs) should not only work closely with the enterprise architects but should preferably be a member of the EA team. Similarly, Product Owners (POs) should either work closely with the product management team or preferably be a member of that team. And it’s possible to do better than that — if team members are truly enterprise aware and are continuous learners, then it is reasonable to expect them to pick up enterprise knowledge over time. The more knowledgeable people are about their organization and its goals the less supervision/governance they will need.
- Automated dashboards. Automated dashboards, a strategy that we’ve referred to as development/operational/IT intelligence in the past, is a scalable form of information radiator. With just a bit of work you can take the information being generated by your tools and, using business intelligence (BI) technologies, populate team and even portfolio dashboards in real time. These dashboards provide important information that teams can use to manage themselves as well as governors to monitor what is happening within your organization. This enhances governance because when you get better quality information into people’s hands and they are more likely make better decisions.
- Defined roles and responsibilities. Defined roles and responsibilities help people to understand who does what, what are they are responsible for and when they need to collaborate with others. This is an important aspect of governance because critical guidance about how people will need to interact with one another.
- Defined organizational structure. You may choose to have a hierarchy of teams, a network of teams, a collection of circles (along the lines of holocracy), or combinations thereof. This is important to your governance efforts because people need to know what are the teams and how do they interrelate within your organization.
- Common guidance. Guidance—standards and guidelines—is important to your governance effort because it helps people to understand how they can develop consistent assets which in turn are easier to understand and evolve. Common development guidance includes coding standards, data naming conventions, user interface (UI) design guidelines, security standards, and more. This guidance should be straightforward, ideally be supported through automation, and collaboratively developed.
- IT governance team. People, typically senior people, are responsible for IT governance. The team, who is on it and what they do, should be defined and publicly known by those being governed. Everyone knows who the governors are and what they do, so that your governance strategy is open and transparent.
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 the Disciplined Agile (DA) toolkit 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.
The process factors that you need to consider for IT governance are:
- 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 DA framework 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.
- 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).
- 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.
- 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.
- 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.
- Develop guidance. Guidance is ideally developed collaboratively with a combination of practitioners and experienced enterprise IT professionals who understand the bigger picture.
- 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 has both delivery team roles as well as enterprise IT roles defined.
- 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 Address Risk goal, 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.