While technologies change, people do not
I spent much of last week in Washington (DC) discussing plans for large-scale integration of enterprise social networking technologies into the day-to-day operations of government agencies (a.k.a. Gov 2.0). What was interesting—but not surprising—was that I spent most of my time sharing lessons learned as to how to successfully manage the introduction and adoption of high-change technologies across large, geographically-disbursed organizations with strong cultures. It goes to show the more technology changes, the more things stay the same: the most complex challenge we need to manage is not creating new technology, but integrating into our lives in ways that make it useful and productive.
People will only adopt technology if they find it useful
I have never seen top-down mandates to use technology across an organization actually produce the outcomes originally desired. We have all seen the letter from the C-level championing the introduction of “New Enterprise System X.” However, much of the time people in the organization simply follow the “letter” (but not the “spirit”) of these mandates, officially using the system but creating whole processes around the system to actually get things done. This is what Dr. Edgar Schein (one of the founders of the Change Management field) calls Tacit Artifacts of organizational culture. It is reinforced by two external metrics: the high percentage of large-scale enterprise program that fail and the higher number of programs that are replaced or rebooted within two years of completion.
However, I have seen the introduction of technology (and/or process) create enormous, beneficial changes. These examples occurred when staff members across all levels of the enterprise had a stake of ownership in how the technology was selected, configured and integrated into their day-to-day lives. Because staff had a voice in direction they were true owners; because they were owners they adopted and used the technology (making corrections when needed to ensure it worked). Essentially the new technology (or process) was their “baby.”
The trick to successful adoption is creating—AND sustaining—this culture of ownership.
The decision-based governance model is the most success means I have found to implement high-change programs
I know what you are thinking, once you hear the word “Governance” you think of long council meetings with endless slides and few action items. You also begin to visualize use of governance as something to slow (or even stop) the introduction of change.
However, it does not have to be this way. Governance can be turned around and used as both a driver of change and a vehicle for reducing obstacles to change. Essentially, you are re-working governance to implement Dr. Kurt Lewin’s “Force Field Model” to manage complex change.
Over the past two decades, I have created a model I call “Decision-based Governance” to achieve this for management both of large-scale programs and continuing enterprise operations.
Sources for creation of the decision-base governance model
We are probably ready for an acronym (I know I am sick of typing “Decision-based Governance Model). So let’s use DGM moving forward.
DGM draws from a variety of sources:
- Program management techniques* by Joseph Shea (the program manager of NASA’s Apollo Program and originator of the modular mission-based milestone model)
- Business analysis and software development best practices established by Barry Boehm of RAND (N.B., software development practices often work equally well for process development as both develop non-physical artifacts used on a daily basis)
- Scope management techniques from the Object Rules Groups’ Business Motivational Model (BMM) and the Rational Unified Process’ (RUP) Inception Phase (Vision document)
- (Human, not ITIL) change management approaches* developed by Kurt Lewin and Edgar Schein
- Structured stakeholder analysis from Ronald K. Mitchell, Bradley R. Agle and Donna J. Wood (published in American Management Review)
- Cell-based approaches to creating resilient networks* (practiced in everything from development of the Internet to creation of intelligence networks) developed by practitioners at Lockheed Martins Systems Integration Group and featured in Harvard Business Review cases and books on Lean Six Sigma
*I directly learned these from these practitioners
This sounds like a lot of things to but together (remember a lot of ingredients go into the best recipes). However the trick of the DGM is that it embeds this practices into repeatable frameworks and steps. This enables it to be taught in less than one week of session and replicated across dozens of people to execute large-scale programs.
The core themes of decision-based governance
Outlining the entire DGM is beyond the scope a blog post (or even series or posts). However, at a top level, the DGM follows the following themes
- Define scope as achievement of a business imperative
- Decompose scope into nested, modular easier-to-achieve initiatives
- Assign an accountable leader and team of definitive stakeholders to each initiative
- Use risk-based project management to always look for things that can go wrong
- Use definitive stakeholder teams to obtain rapid buy-in using structured decision-making
- Leverage the nested, modular program structure to escalate and resolve problems that cannot be addressed at the initiative level
Here is a little more detail on each theme:
1. Define scope as achievement of a business imperative
First, the DGM defines scope as the set of capabilities needed to solve a problem (or achieve a goal)—and NO MORE. This essentially ends those famous “…but that’s not in the scope document arguments.” If a feature or capability is essential to solving a problem or achieving a goal, it is in scope; if not, it is out. This differs greatly from “success = rollout of System X”
To do this successfully, you need to define your problem or goal in a complete, measurable fashion then link all the top-level things you need to achieve success. When you are complete, your entire time has the same visualization of success (and can explain it in 30 seconds or less). Both the BMM and RUP provide excellent tools to do this. I have adapted each depending on whether you wish to define scope based on achievement of a problem, opportunity or goal.
2. Decompose scope into nested, modular easier-to-achieve initiatives
Second, the DGM applies cell-based network self-organization approaches to continuously break down the program into nested “cells.” It keeps doing this until each cell is small enough that a team of 10 or fewer people can implement it (the maximum number of people performing non-repeatable, creative tasks that one person can manage). You have probably seen this already as cells can be called work streams, initiatives, etc.
You will need to re-apply Business Imperative-based scoping to each cell. This is not a trivial exercise. However, when you are done you can easily understand the following:
- What small each initiative has to achieve to build to success for the entire program
- What each team has to achieve for each initiative’s success
This breakdown is not arbitrary. It should instead follow from you top-level Problem or Goal Statements. For example, if your problem is “product development is too slow” and your solution is to “bring products through the steps of development to market faster” you will initially decompose the program into modules based on the steps to get through each major product milestone.
3. Assign an accountable owner and team of definitive stakeholders to each initiative
Third, the DGM assigns an owner to each initiative who is fully accountable for it success. It them builds a team around this owner populated with people who are required to complete the scope of the initiative. This matches the Initiative Owner’s resourcing and authority to his or her level of accountability (a critical success factor)
It is important think about all the types of team members an initiative will need for success. If you only include implementers, you will get “something” done, but it may not be liked or adopted by others. To ensure successful completion, rollout and adoption, you need to include resources from all areas of the definitive stakeholder partnership on your team: solution owners, implementers, supporters, approvers and adopters (end users). BTW, this approach “folds in” a key element of change management: cross-organizational ownership.
4. Use risk-based project management to always look for things that can go wrong
The fourth theme in the DGM basically accepts the maxim, “stuff happens.” It rejects the fallacy of the all-perfect, up-front project plan and replaces it with iterative planning for milestone achievement.
Prior to beginning each milestone, the project manager puts together a near-term plan (based on where the initiative currently is). Once this plan is complete, he or shen then immediately and continuously looks for things that could wrong (i.e., risks). He or she then assess each and determines plans to prevent or mitigate the most important risks (also on a continuous basis). This is risk-based project management
The most important achievement of risk-based project management is prevention of surprises:
- You look for things that could wrong
- You assess these in a structured matter and share these with the team
- You make contingency plans so you are prepared
- You get inform your external stakeholders and include them the decision as to how you should proceed
The best managed programs and projects are not those that never had problems; they are those that “rolled with the punches” without missing a step.
This may sound overly theoretical. It is not. I carry with me a set of spreadsheets and document templates (it is that simple) that I can teach a project team in three hours or less to do this in a scalable, repeatable fashion.
5. Use definitive stakeholder teams to obtain rapid buy-in using structured decision-making
If you leave your initiative teams alone, they will invariably pick those answers to resolve each identified problem that present the shortest path to completion. This is great for the team but often bad for the larger organization. The way to prevent his is to pair a Steering Team of Definitive Stakeholders to each initiative.
The essential job of the Steering Team is to make all decisions required for success. These decisions will generally span two areas:
- Selection and approval of approaches to success
- Selection and approval of actions or contingency plans to address risks or problems
The first trick is keeping this team the right size. If it is too small, it will not be inclusive enough to cover all domain areas required for success (e.g., implementation, support, approval, adoption). If it too large, it will be inefficient. Essentially you need a team of all the people who must agree to 1) provide resources, 2) say “yes and/or 3) not say “no” in order for the initiative to succeed. This is not a trivial exercise (done incorrectly it can actually alienate key people in the organization).
The second trick is ensuring you use your time with these stakeholders to the greatest efficiency. If you do not, you will have meetings that spiral out of control. This will lead losing stakeholder involvement and, later, stakeholder support.
I have adapted a model from the theory on structured stakeholder analysis (by Mitchell, Agle and Wood) is repeatable and apolitical. This model ensures you get all the people you need and leverages the nested, modular breakdown of the program to ensure each team is kept to a good working size. It also adds some basis “Rules of Order” to manage this in a way that avoids surprises and incorporates an understanding of how organizations make decisions.
These Steering Teams are the “secret sauce” of the DGM. They not only provide the basic structure of ensuring resources are available and scope is on track but also serve as the primary vehicle for execution of the Force Field Model for managing complex change (from implementation to rollout to adoption).
6. Use the nested, modular program structure to escalate and resolve problems that cannot be addressed at the initiative level
Eventually, you will encounter decisions that cannot be resolved at the Initiative level (these could be really large ones with wide policy implications or ones that may conflict with other initiatives). This is where the nested, module approach to managing the program.
If an Initiative Steering Team cannot make a decision, it immediate escalates to the next level of the program. As you move upward, you move from more tactical “how do we get this initiative done” decisions to more strategic “how does this fit into the big picture” ones. An example of this is below:
This nested governance approach provides three primary benefits:
- Decisions are made at the lowest level possible. This reinforces ownership and drive speed. It is also critical to scaling large programs (without bogging them down)
- Problems that cannot be resolved are shared in a structured manner. This prevents surprises and naturally incorporates elements of the Force Field Model for change management.
- There is a repeatable process to escalate and resolve problems. This ensures that no problem—regardless of size—is left outstanding for long periods of time. I have used this on fast-moving programs to ensure that most decisions are resolved within one week and no large decision will languish for more than three weeks before it is resolved at the highest levels of the program.
This nesting is essential to ensuring a correct balance of strategic and tactical decision-making across the program.
The decision-based government model is an efficient way to implement “high change” programs in manner that ensures accountability to all critical stakeholders and creates a culture of ownership and adoption. It can be scaled down to support small simple projects or very large complicated programs. It naturally embeds best practices for business analysis, risk management, change management and governance into an easy-to-reuse model.
This model is not a theoretical construct. I have taught elements of it to over 2,000 people across three continents. I have used it to manage over $500m (USD) of programs and $250m (USD) of operations across over 40 countries—all within 5% of schedule and 10% of budget.