5
Business-Change Governance
We’d all like to know how the information revolution eventually shakes out. I think we know. It ends in ordinariness, disappointment and advertising, as things always do.
—Tom Toles, Washington Post
Interlude: The “Logic” of Political Engineering
Some years ago, I found myself involved in a would-be project that stood at the crossroads of a major medical practice plan and its hospital system partner. Both parties had agreed on the need to streamline the online system that allowed patients to select their doctors, but neither side demonstrated any willingness to make the structural changes necessary to make it happen.
The problem was that patients had access to two distinctly different websites that offered the same doctors at the same clinics. Each site relied on its own database and middleware, and any consistency between the two systems was essentially a coincidence. Each organization believed the other’s solution to be the inferior one. The hospital system wasn’t about to give up its scheduling system, and the practice plan insisted on control over the physician listings.
Now, I can’t think of a more worthy business case than “help patients in need get the right medical care.” Unfortunately, the IT brain trusts at both organizations were thoroughly entrenched, and it really didn’t matter how simple or laudable the goal was. Absent a champion who both respected the business need and comprehended the means necessary to attain it, this idea was dead on arrival.
My role in the erstwhile initiative was to break the news to the stakeholders that the technical barriers were just too great. In this case, the stakeholders were a group of world-renowned physicians who were unaccustomed to being told what was and wasn’t possible.
At the time, I believed I received this assignment because of my ability to explain complex issues to important people without talking down to them. In retrospect, I was probably just sent in because I lacked the savvy to make it somebody else’s responsibility.
When the day came, I walked into a room full of highly respected physicians who made no attempt to conceal that this meeting represented an interruption to their important work with patients. I walked carefully through the reasons why their perfectly logical request had no chance of being fulfilled. At the time, I felt as though my explanation was exceptionally clear and well measured.
When I finished, I was met with an excruciating but very brief silence. The words that broke it came from a particularly irate oncologist, and I doubt I’ll ever forget them:
“We cure #@$&ing cancer, and you came over here today to tell us you can’t get two databases to talk to each other!?”
Culture change encourages everyone to view their world from a different perspective—that just delivering technology won’t do the job. The new business/IT conversation makes the culture change real by redefining responsibilities. Fixing Agile gives us specific techniques for making the changes happen, and by instituting the concept of BusOps, changes achieved through Agile techniques have a chance of being incorporated into the day-to-day work of the organization.
Which brings us to the challenge of figuring out how the business decides which business changes to invest in and how much to invest in them. That’s what change governance is about.
Start with how the new business/IT conversation starts, with the question, how do you want your part of the business to run differently and better?
The change governance practices you’ll need if you’re going to succeed in intentional business change . . . in eliminating IT projects in favor of business-change efforts . . . start with the answers to that question.
They end with decision-makers abandoning return on investment—the ever-popular ROI—as the alpha and omega of what constitutes good in business.
Not ROI as a concept. That can stay. It’s ROI as it’s usually conceptualized—as a purely financial metric—that’s just too one-dimensional to apply to ideas for improving how business gets done.
To understand why, we have to dive into two related topics. The first is the nature of business benefit, which happens only when one or more of four “goods” improve. The second is the difference between what a business-change project can plausibly deliver and its impact on the four goods.
The“Four Goods”
In even the most enlightened executive suites, only four business improvements really matter: more revenue, lower costs, better-managed risks, and enhanced mission fulfillment.
Three of the four sure do look like purely financial metrics, don’t they?
They do. And yet, in practice it doesn’t exactly work out that way. Here’s why.
The Cost Case
Imagine you propose a project to streamline a manufacturing process you’re accountable for. Your proposed improvements will reduce the incremental cost of the doohickeys your company sells by 10 percent. Some spreadsheet work computes an ROI of 20 percent.
It’s a slam dunk.
No, it isn’t, because you aren’t planning to lay off 10 percent of the manufacturing staff. You’re going to keep them where they are on the grounds that this way the company can absorb the growth in volume to be expected when the company reduces the price it sells doohickeys for.
Or, you could lay off the employees to make the cost reduction tangible. That lets you lower prices, which increases sales volume, which in turn results in considerable time and expense wasted finding employees to replace the ones you just let go.
Or, you could avoid these complications. You could lay off employees and keep the price of a doohickey the same. Instead of revenue growth you get better margins for the revenue you do get.
But on the other hand, if you go for the margins you don’t get improved marketshare, mindshare, and walletshare— revenue’s leading indicators.
The investment you’re asking for is counted in tangible money. The growth you’re basing your plans on is just a promise, and without it you’ll have investment without return.
Revenue Reliance
Cost reduction sells. Revenue growth doesn’t.
It isn’t that nobody wants the revenue. Of course they do. But two major barriers separate the desire for more revenue from the steps needed to get it. The first is that the causal connection between any one action the company might take and increased revenue is uncertain while planning.
The second is that it’s impossible to prove following execution.
It’s uncertain while planning because unlike cost-reduction projects, which can directly reduce costs (but see above), multiple factors affect revenue, many of which are beyond your project’s influence, let alone control.
Among them are how your products compare with what competitors bring to market, the effectiveness of your advertising, the caliber of your sales force, your ability to build and deliver products compared with that of your competitors, and how well customer service in all its forms minimizes customer defections.
Revenue is multivariate. When it changes, whether it improves or deteriorates, proving what caused the change is close to impossible. That being the case, in ROI-driven businesses, revenue-based business cases are generally viewed with skepticism.
Which is why, in ROI-driven businesses, given a choice between a revenue-enhancement project and a cost-reduction project, cost-reduction usually wins.
The Risk of Risk
A risk is something bad that might or might not happen. This is different from the risks actuaries price. Actuaries deal with statistical risk. They’re dealing with the certainty that given enough cases, the something bad in question will happen a certain fraction of the time.
Actuarial risk results in predictable costs, which is why a program to improve employee health would count as cost-reduction, not better risk management: while on any given day a specific employee either is or is not ill, over the course of a year and across all employees, the total number of sick days taken is quite predictable.
Contrast that to, say, a proposed investment in next-generation information security—an investment in anticipating new types of threats and deploying preventive responses. Further imagine that for many of these next-generation threats, you’ll have no way to detect unsuccessful attacks.
And so the company decides to approve the proposal. Five years later your systems have never, to the best of your knowledge, been penetrated.
Does this mean your project was a success, or does it mean your systems were never attacked?
The answer: successful prevention is often indistinguishable from the absence of risk, and the less an audience wants to understand the details, the more this is true.
That’s the problem with investments in risk management. There’s rarely a way to attach a reliable probability to a given risk, and without that probability there’s no way to compare the value of prevention, mitigation, or insurance with their costs.
And so, with ROI as your company’s metric, risk-management projects have a hard time competing for funding with those that promise cost reductions.
A complete discussion of this topic is beyond the scope of this book. Here, it’s worth mentioning that the world of business has made significant progress, specifically because when it comes to enterprise risk management, boards of directors and members of the executive suite no longer insist on ROI to justify investments.
Instead, the conversation is about whether a given risk is plausible enough to warrant investment in a response, and if so, which of the four types of risk responses makes the most sense, the four responses being:
1. Prevention (also known as Avoidance), reducing the odds of the risk becoming reality
2. Mitigation, reducing the damage if the risk does happen
3. Insure, spending a fraction of what the risk would cost if it became real now, so as to share it out if it does
4. Accept (a version of which is hope), which is how businesses deal with the possibility of an asteroid striking the earth because Bruce Willis didn’t get to it in time
The Merit of Mission
With or without a direct financial business case, your organization’s mission is a perfectly valid investment target.
Not what your mission statement talks about. Forget mission statements. They’re worthless. Understanding your mission, on the other hand, is vital, once you understand that “mission” means what it is you do that provides value to your customers, and what it is you do that provides enough unique value that your customers decided to be your customers instead of spending their money elsewhere.
What mission doesn’t always do is directly drive profits. Take, for example, the pre-Great Recession General Motors. Its neglected mission was to sell cars people wanted to buy. Most of its profits came from financing the cars it sold, which explained how it came to be that GM eventually had to bribe consumers to buy its uncompetitive cars through the expedient of providing sizable rebates.
And even with the bribes its marketshare eroded.
As a second example, look at the business model followed by print media and most cable channels. To the unenlightened,* when they watched Sharknado on the SciFi channel, they were watching one of the SciFi channel’s products.
But that wasn’t what was happening. Sharknado, the daily newspaper, and other such things aren’t products. They’re bait, designed to attract media consumers who the media company in question then sells to advertisers.
From the perspective of most media companies, we’re the product.
In the long run, businesses can’t succeed when they fail at their missions,† but the delay between mission erosion and business failure can, as was the case with General Motors, be long enough to create the illusion that mission success and business success are uncorrelated.
The business model most of us learned about first was simple and straightforward. Call it the “better mousetrap model.” It’s the model followed by companies that make something tangible (the mousetrap), selling it for more than the cost of making it. Investments in mission are easy to justify when your business adheres to the “better mousetrap” model.
And it’s why investments in mission are nearly impossible to justify otherwise: the costs are immediate, but the benefits are delayed, indirect, and possible to demonstrate only after years of making the wrong decisions.
Can’t We Fix Problems?
Sometimes, the rationale for a project is that it fixes a problem. Isn’t that good enough?
Well . . . no. If there’s something or other that’s annoying but doesn’t have any impact on revenue, cost, risk, or mission, it’s a darned* shame. But the world is filled with annoyances. That doesn’t mean it makes sense to try to fix them all.
Annoyances rise to the status of “problem” only if they have some impact on one or more of the four goods. They might be too small for the impact to be measurable, which is okay if the cost of the fixes is also too small to be more than a rounding error. Otherwise, the problems in question probably aren’t worth taking the time and effort to resolve.
But Wait—What about Strategy?
Oddly enough, business strategy doesn’t enter into change governance very much. It isn’t that strategy doesn’t lead to change. Of course it does. It’s that business-change governance focuses on evaluating and supporting bottom-up proposals for business improvement.
Strategy—its definition, its funding, and its implementation plans—comes from the executive suite. The business-change governance practice does not have a role to play in evaluating it.
Value Levers
Value lever analysis isn’t, we’re sad to report, original with us. The concept is, however, essential to understanding how business-change governance should work.
While there’s no one model that fits all businesses . . . and no one model that’s standardized across all consultancies either . . . they all work something like this:
• Tangible change: what’s going to be better tomorrow than it was yesterday, with “better” usually defined by the six dimensions of optimization as described in chapter 2.
While not universally true, most tangible changes will be quantitative and measurable—for example, the change is expected to result in a twenty-minute (10 percent) cycle time reduction.
• Business outcome: the direct reason you care about the tangible change you’re trying to implement—for example, improved customer retention, increased customer walletshare, product superiority, or improved product pricing.
Because most business outcomes are multivariate, affected by more than one business change, the estimated impact on each business outcome will usually be qualitative.
• Four-goods impact: how the business outcome will affect revenue, cost, risk, and mission.
The connections between improvements to revenue, cost, risk, and mission and the business goals that drive them are multivariate. The connections among improvements to business goals and the projects that drive them are also multivariate. Consequently, project proposals should establish their logical connection to improvements in one or more of the four goods without making promises of provability.
You might be tempted to try to connect tangible changes to business outcomes and business outcomes to the four goods quantitatively. With sufficiently excellent analysts and carefully chosen analytics, this just might be possible.
But we’re skeptical, and even if a sufficiently brilliant analyst managed the modeling required, you’d need a way to test the model before you could rely on it. You’d also need procedures for updating the model after every business change.
Qualitative linkage, accompanied by clear explanations of why the linkage is logical and plausible, usually has to do, and is usually sufficient for, governance purposes.
With the above in mind, here’s a framework for business-change governance to get you started.
Business-Change Governance
Effective business-change governance depends on the culture change we described in chapter 1, specifically:
Where there are IT projects, business executives view project proposals with suspicion. They see their job as screening out bad ideas, which is why they insist that the CIO provide a hard-dollar return on investment, typically calculated as the number of warm bodies to be laid off multiplied by their annual compensation plus benefits.
Where there are no IT projects, business executives view project proposals as opportunities to improve how their company conducts its business. They see their job as helping good ideas succeed. Because of this they insist that all project proposals be described in terms of business change, described that way by a business sponsor who is enthusiastic about the possibilities and supported by an IT SME who attests to the project’s technical feasibility.
Effective change governance is about helping good ideas succeed.
Which in turn means that whatever it’s called and whoever participates, before the change governance body* evaluates its first project proposal, it:
1. Obtains the business-change budget. Determining the funding available for business-change projects is the first business-change governance decision. The rest of business-change governance is deciding how to allocate it. Speaking of which, in steps 2 and 3 the council allocates the budget.
When preparing the budget, all parties need to take the distractions of the present into account when reserving staff time for making the future get here. This is especially true for the men and women you want to include in business-change efforts the most, because they’re the ones who are likely to be called away to handle day-to-day urgencies.
2. Reserves a slice of the pie for enhancements. Enhancements are small items—something a programmer can handle in a couple of weeks but certainly no more than a month. A manager might need a new report; moving a field from one screen to another might make life easier.
The council should exclude itself from decisions about specific enhancements, as this is the business equivalent of being pecked to death by ducks. Instead, it allocates a pool of IT developer hours to each business area for its use in requesting enhancements.
As an alternative, maintain an Agile-style backlog* for each application. The size of each application support team, set by the council, determines overall capacity. Managing the backlog is a process/product owner responsibility.
There’s a principle of information theory that applies here: one person’s signal is another one’s noise. From the perspective of the CIO, taken collectively, the enhancements queue is noise. From the perspective of the requesters, it’s a very important collection of signals.
3. Allocates the total business-change budget, either in dollars or in project-team-member hours, among the four goods, so that, for example, individual risk-reduction projects don’t compete for funding with individual revenue enhancement projects.
4. Establishes and ranks the company’s most important business goals: customer retention, product innovation, and so on.
5. Publishes guidelines for the ingredients of a successful proposal, which are:
• Change stewardship. If the point of a project is to improve a business function, the change steward, who corresponds to the business sponsor in traditional environments, and product owners where Agile holds sway, is the manager or executive directly accountable for the affected business function.
The inviolable rule: no change steward, no project.
Which business function or functions will improve.
For each affected function which of the six dimensions of optimization will improve and, preferably, how much they’ll improve.
• Which business goals will be closer to achievement and how the planned business function improvement will bring them closer.
• Which of the four goods will improve, based on the value levers analysis the company’s strategic planners have already performed and published, or, if they haven’t, how your own four-goods analysis connects the relevant dots.
• Connection to the company’s strategy and strategic plan. Note that there are plenty of good ideas that deserve to be pursued that have no direct connection to the strategic plan.
That’s okay, and in fact it’s commonplace for localized, nonstrategic projects to increase revenue or decrease costs in ways that can help pay for the strategic plan.
What aren’t okay are projects that run counter to the strategy, that make accomplishing the strategy more difficult, or that risk dragging the company in a different direction.
• Compliance impact. Documentation that the change design conforms to whatever compliance regimes are relevant to the change in question.
• The plan. Preparation of a detailed project plan in advance of receiving approval to proceed would be a waste of time. Failing to have any plan at all, on the other hand, suggests a lack of seriousness—an expectation that daily improvisation coupled with good intentions will somehow lead to successful implementation.
Somewhere between these two extremes is a road map that describes the most important work streams, lists the project roles needed for each of them to get the work done, and puts them all on a timeline.
• Ripple effects. Most changes will, in addition to their desired consequences, affect other parts of the organization.
At a minimum, business changes that require significant investments in information technology will probably need ongoing support. The organization needs to be prepared for and agree to fund this cost.
Beyond this, it’s likely that changing how one business function goes about things will have some impact on other business functions it’s connected to. These are all part of the business change the proposers are recommending. If those responsible for these ripple-effect-affected business functions haven’t agreed to participate, the proposal isn’t complete.
6. Evaluates proposals. With this foundation the governance body is ready to evaluate proposals for business change. To do so it:
• Consults with proposers whose proposals are weak but seem to have good ideas hidden inside them, to help them improve their proposals. The goal, you’ll recall, is to help good ideas succeed, not to choose the best-written proposals.
This is very much parallel to the hiring process, where smart managers recognize the difference between the candidate with the best résumé and the best candidate.
• Decides which proposals to approve. Along with this, a tip: once the council reviews a proposal, decision-making is binary. The two possible results are scheduled and rejected.
There is no yes that means anything unless the council has added the project to its master schedule, which means the project has a start date, on which the staff needed to execute the project will be available and ready to begin.
Also, there’s no maybe or not yet. These are fictions. If a proposal isn’t good enough to be put on the master schedule now, it never will be. Don’t pretend.
In companies that violate this rule, their change governance body is inevitably and perpetually plagued by approved proposals that never seem to launch. Which is why the two outcomes for any proposed project are scheduled and rejected.
• Ensures all approved projects are fully staffed. Fully staffed means the project never has to wait for the employee responsible for a project task to become available to work on it. We’re stealing a page here from Eliyahu Goldratt’s Critical Chain methodology, which teaches that it’s far better for an employee to have idle time than for a project to sit idle because the employee isn’t available.
And no, multitasking doesn’t solve this. All it does is provide a euphemism for interrupting interruptions with interruptions. If two tasks take twenty hours each when performed sequentially without interruptions, you can bet they’ll take at least fifty hours in total when an employee has to multitask to handle them concurrently.
Full staffing is the most important reason to make a master project schedule central to the actual work of business-change governance, as it is the tangible mechanism through which staff commitments can be managed.
7. Reviews progress, for projects that are in flight, and outcomes, for projects that completed since the last review period.
Projects get into trouble for any number of reasons, a small fraction of which are bad management and problematic project teams. Vendors don’t deliver, employees leave the company, sponsors receive promotions . . . the list goes on. Troubled projects need either help or cancellation. The council is responsible for both.
As for outcomes, a project proposal describes a project’s promise. The council evaluates the proposal to decide how likely it is that the promise will pan out. This means the council needs to determine whether it actually does, not to “hold the proposer accountable” but to evaluate and improve its own competence at evaluating proposals.
The Business Change Governance Council
Companies that have IT projects typically have an IT Steering Committee to govern them. By now it shouldn’t be a stretch that as we’re moving the goalposts from IT product delivery to intentional business change, it’s no longer IT that we have to steer.
What’s less obvious is something else we don’t need: a committee.
But it should be obvious. Few would argue with the proposition that businesses need to be faster and more nimble. And yet, equally few recognize one of the immutable truths of organizational dynamics: no matter how slowly things are happening now, you can count on a committee to slow things down even more.
Which is why we recommend forming a council instead. As we use the terms, a committee’s members represent the part of the company they come from. A council’s members, in contrast, see themselves as leaders of the whole enterprise, who just happen to currently focus on the area they’re responsible for.
A committee’s members negotiate and trade favors. A council’s members collaborate to figure out what’s best for the company as a whole.
Two cautions: first, even with the best of intentions, even the most council-oriented governance group can deteriorate into a committee. Changes in membership are a particularly sensitive situation, as new members are likely to walk in the door with the expectation they’re joining a committee.
Second: all it takes is one “cheater on the system”—a council member who starts to advocate for their silo—for the council to start the short, quick slide into committee-ness.
Shadow IT
Back in the early days of personal computers, much of their appeal was that users didn’t have to wait for IT to get around to their request (IT never did because it was already eaten alive by bigger ones); instead, users could DIY a solution quickly, af-fordably, and without IT even knowing it had happened.
They might push spreadsheet software to its limits. They might build a database using one of the several end-user DBMS packages designed for this, like dBase II, Paradox, or Access.
They might buy and install an inexpensive commercial package. Sales reps, for example, loved Act! because it was (1) cheap, (2) easy to use, and (3) designed to help sales reps sell. It was the ancient-day equivalent of installing a smartphone app.
IT had, and mostly still has, a hate/hate/hate/hate relationship with shadow IT. IT hates it because from time to time, shadow IT-ers need help, and IT isn’t in a position to provide it. It hasn’t, after all, been involved in implementing the shadow system, so it has no expertise to offer.
IT also hates shadow IT because it makes IT look bad: end users make their own IT happen, successfully, and at a fraction of the time and expense IT would have needed to accomplish the same result.
IT has legitimate concerns as well, especially with respect to security and compliance, as well as support and integration. Not that IT has a perfect track record when it comes to these critical challenges, but at least it has processes to implement proper controls for security and compliance, governance practices to plan for support, and, to some extent, architectural standards for integration.
And finally, IT hates shadow IT because it can’t stamp it out. After all, stamping out shadow IT means IT saying to its business customers, “We won’t do it for you and we won’t let you do it for yourself.”
Especially for those IT shops that adopted the internal customer metaphor,* telling business users they can’t implement their own IT is tantamount to Home Depot refusing to sell dry-wall and joint compound to shoppers.
And yet, one way or another, most IT advisers recommend locking down desktops and keeping end-user DBMSs out of the hands of end users, the business case being recognition of all the disadvantages while carefully ignoring all the benefits.
Which lasted until the advent of the cloud and Salesforce. IT could lock down desktops. Locking down the internet proved to be quite a bit more difficult.
The Solution: “Illuminated IT”
As there’s no longer any such thing as an IT project, it stands to reason there’s no longer any such thing as shadow IT.
Quite the opposite: business DIY projects have the advantage of business change and improvement being the whole point. IT can come by later to replace the inadequate plumbing and wiring so they meet its metaphorical building codes, without having to be very involved in designing and implementing the business change the technology is supposed to enable.
Something else IT can do is to provide the integration that’s almost always impossible for shadow IT projects. Integration is arguably IT’s most challenging responsibility, as the analysis and technology needed to interface systems with different origins and design philosophies is intrinsically complex.
It’s like this: a sales manager can sign up for Salesforce licenses for every sales rep in the company. When data entered into Salesforce are needed in a different system, though, someone has to rekey them from a Salesforce screen into the other system.
Unless and until, that is, IT steps in to provide the integration.
IT has other expertise business users generally lack—not only integration but also methods for choosing the best package or tool and managing the project itself. Beyond this, if a business DIY change project neglects to pay attention to relevant compliance requirements, IT can provide a backstop.
And an oddity: often, shadow IT teams forget that the point is to change how business gets done. They become nothing more than additional IT teams only without IT’s special expertise. In the new world order we’re advocating in this book, IT can provide consulting that helps illuminated IT teams keep their focus.
How to do this: usually there are employees throughout the business who have skills and aptitudes comparable to IT’s business analysts (now internal business consultants). Give them all the education, advice, and other support they can handle, and they’ll do much of the heavy lifting required to make illuminated IT projects . . . strike that, illuminated business-change projects . . . successful.
Illuminated IT can greatly expand a company’s capacity for business change. With IT’s support it’s possible to minimize the disadvantages while reaping most of the benefits.
Illuminated IT requires a fundamental change in how IT works and thinks. It is, in fact, the exact same fundamental change this book is about: IT no longer “owns” the technology silo. It’s a technology steward, but it’s a partner and collaborator with the rest of the business, in this case supporting businessled technology implementations as part of its role in enabling intentional business change.
In Conclusion
Change governance has quite a few gears and pulleys, and there’s no one way to connect them that fits all situations. We’ve tried to provide useful guidelines. Your success will depend on experimentation—a willingness to try new techniques and, even more important, to admit when something you’ve tried isn’t working out as hoped.
Behind it all, and most important for change governance to be the linchpin of intentional business change instead of its greatest impediment, is the difference between committee and council.
If your change governance body is composed of people who see themselves as leaders of the whole organization and not representatives of one of its parts, the rest will happen.
If not, you’ll probably see some forward progress, but it will be nothing like the company’s actual potential.
If You Remember Nothing Else …
• Investments in business change should benefit one of the “four goods”: increased revenue, decreased costs, better risk management, or improvements in accomplishing the organization’s mission.
• The group responsible for business-change governance should be constituted as a council, not as a committee, the difference being that council members consider themselves leaders of the whole organization, currently responsible for a chunk of it, as opposed to committee members, who consider themselves to be representatives of the silo they currently lead.
• Business-change governance should be devoted to helping good ideas succeed, far more than screening out ideas that aren’t worthwhile.
• Business-change governance reviews should have only two possible outcomes. Proposals should be either scheduled or rejected. If a project isn’t important enough to be placed on the project master schedule, it hasn’t really been approved, and pretending has no place in effective business-change governance.
• Shadow IT—DIY business-change efforts, with DIY including the implementation of information technology—used to be preventable. With the advent of SaaS, IT can’t stop it anymore, nor should it. Encouraging and supporting it turns shadow IT into “illuminated IT,” greatly increasing the organization’s change bandwidth.
What You Can Do Right Now
• Disband your IT Steering Committee and replace it with a Business Change Governance Council. Make sure everyone involved embraces the difference between a committee and a council, and commits to it.
• Build a project value framework around the “four goods” (revenue, cost, risk, and mission), making use of value lever analysis as the means for connecting project results to them.
• Establish an “illuminated IT” support function within the IT organization and publicize its availability and capabilities throughout the rest of the business.
* Those who haven’t read this book.
† This includes those companies that mistake their eminently ignorable mission statements for their mission.
* Sorry for the strong language.
* Call it the Business Change Governance Council, as explained in the next section.
* For those who aren’t Agilistas, the backlog is the list of desired capabilities for a new software application under development. It’s up to the product owner to decide their relative priority. We figure, just because an application already exists, this doesn’t change very much: in an Agile project, after a month or so the core application exists too.
* All of them.