Product Details Lean Enterprise: How High Performance Organizations Innovate at Scale (2015)

Part IV. Transform

Chapter 13. Evolve Financial Management to Drive Product Innovation

Adhering to budgeting rules shouldn’t trump good decision-making.

Emily Oster

Right now, your company has 21st-century Internet-enabled business processes, mid-20th century management processes, all built atop 19th-century management principles.

Gary Hamel

Introduction

In many large enterprises, financial management processes (FMPs) are designed around the project paradigm. This presents an obstacle to taking a product-based approach to innovation. It is relatively easy for small teams to work and collaborate amongst themselves. However, on an enterprise scale, we eventually reach a point where evolution is blocked by rigid, centralized FMPs that drive the delivery and procurement processes that limit the options for innovating at scale. We will address some of the problems created by these FMPs, with particular emphasis on the budgeting process. We emphasize that to work through the issues your organization experiences as a result of financial management processes, you will need the help of your finance team. Start building good relationships with them and work collaboratively to improve outcomes for customers and the business.

Recognition of the interdependence of all management processes, the detrimental behaviors they can enforce, and the barriers they present to continuous improvement and innovation is essential to success at becoming lean. It is hard to let go of the long-held belief that strong, centralized control provides valuable efficiencies. However well it may have served us in an era of lower complexity and slower technical advances, it now creates barriers that prevent us from adapting quickly to emerging opportunities. In this context, the resources and efforts required to gather information, communicate, and monitor rigid centralized processes outweigh any efficiencies gained. As well, a strongly controlled centralized budget process encourages competitive, rather than collaborative, internal behavior. This is counter-productive to innovation, which requires teamwork.

Many large multinational organizations have transformed themselves by dropping the long-held belief that command and control is the best way to manage their financial processes. As further reading on this topic, we recommend Beyond Budgeting²²¹ and Implementing Beyond Budgeting,²²²as well as the Beyond Budgeting Round Table website.²²³

Dancing to the Beat of the Financial Drum Slows Innovation

Planning, budgeting, forecasting, and monitoring are essential for defining our success, in particular our commitment to shareholders. Relatively new or revised regulations and standards, such as Sarbanes-Oxley and International Financial Reporting Standards, have intensified the perceived need to centralize and control these processes. However, the intent of these regulations is to improve transparency and visibility into financial reporting, as well as our ability to make better decisions. Centralized control and decision making through annual budgets can easily create the opposite outcomes.

In this chapter, we consider the organizational financial management practices within enterprises that are typically identified as deterrents to innovation:

§ Basing business decisions on a centralized annual budget cycle, with exceptions considered only under extreme circumstances. This combines forecasting, planning, and monitoring into a single centralized process, performed once a year, which results in suboptimal output from each of these important activities.

§ Using the capability to hit budget targets as a key indicators of performance for individuals, teams, and the organization as a whole, which merely tells you how well people play the process but not the outcomes they have achieved over the past year.

§ Basing business decisions on the financial reporting structure of capital versus operating expense. This limits the ability to innovate by starting with a minimal viable product that grows gradually or can be discarded at any time. The CapEx/OpEx model of reporting costs is largely based on physical assets and is project based; it does not translate well to the use of information to experiment, learn, and continually improve products over time.

Combined, these practices force us to time key business decisions and annual work plans for the optimization of the finance department and reporting cycles, which in turn restricts when and how business innovation within the organization occurs. They are out of step with our ability and need to continually deliver value to customers. Large, fully funded, bloated programs of work that deliver questionable value grind on whilst new, unanticipated opportunities drift by because there is no funding available for exploring and testing our hypotheses about them. Time that could be spent on innovation is instead spent on managing and reporting on “the budget.”

Liberating Ourselves from the Annual Budget Cycle

Centralized budgeting processes are typically used to plan, forecast, monitor, and report on the financial position and overall performance of an organization. They drive everything from revenue target reporting to tax planning and resource allocation. However, in the context of product development, the traditional annual budget cycle can easily:

§ Reduce transparency into the actual costs of delivering value—costs are allocated by functional cost centers or by which bucket the money comes from, without an end-to-end product view.

§ Remove decisions from the people doing the work—the upper management establishes and mandates detailed targets.

§ Direct costs away from value creation by enforcing exhaustive processes for approving, tracking, and justifying costs.

§ Measure performance by the ability to please the boss or produce output—not by actual customer outcomes—by rewarding those who meet budget targets, no matter what the overall and long-range cost may be.

However, many large enterprises have found alternatives to the traditional centralized budget process to achieve the goals of good financial management. Figure 13-1 emphasizes the importance of separating out the goals of budgeting and suggests possible approaches.

Figure 13-1. Approaches to achieving the goals of budgeting, courtesy of Bjarte Bogsnes, author of Implementing Beyond Budgeting: Unlocking the Performance Potential

Stop Conflating Good Financial Management with “The Budget”

I hate the yearly budget with a fire of a thousand suns.

Anonymous

A budget should be viewed as the total sum of funds set aside, or needed, for a purpose: “What is the ceiling for how much we may spend on this activity?” It does not define what we are actually going to do—that is strategy. It is not a plan for how to achieve the strategy, nor does it forecast or measure our success in delivering value to customers. When we roll all of these essential activities into the budgeting process, we lose our focus.

Having a budget is a good thing, especially when we have set some stretch financial targets for ourselves. Financial constraints can be a strong catalyst for creativity, collaboration, and innovation. Particularly in the explore domain, we can spur innovation if we purposefully reduce funding to localized areas or products and allow teams to decide how they can best utilize available funds, as we describe in Part II of this book. However, this approach will not work if we simply reduce funding and tell teams what their targets are and how to achieve them.

Following the principle of subsidiarity described in Chapter 10, the responsibility to manage allocated funds should be pushed to the lowest appropriate level—generally, the people who are performing the work. We still need to provide teams with clear definitions of what is off-limits, but the teams need to be trusted and given the chance to make decisions. As described in Implementing Beyond Budgeting, when European petrochemicals giant Borealis took this approach, they expected that costs would go up. Instead, they went down.²²⁴ Although Borealis was well positioned and prepared for the change with a culture that supported the move, CFO Bjarte Bogsnes attributes most of the outcome to better visibility into cost drivers through the use of activity-based accounting principles:²²⁵ those responsible for the activities that generate costs report on their finances, and teams assume responsibility for better management of costs.

The great planning fallacy, evident in the centralized budget process, is that if we develop a detailed upfront financial plan for the upcoming year, it will simply happen—if we stick to the plan. The effort to develop these kinds of plans is a waste of time and resources, because product development is as much about discovery as it is about execution. Costs will change, new opportunities will arise, and some planned work will turn out not to generate the desired outcomes. In today’s world of globalization, rapid technology growth, and increasing unpredictability it is foolish to think that accurate, precise plans are achievable or even desirable.

A better approach is to set high-level long-term goals, carefully manage the more predictable near future, and constantly adjust our shorter-range plans to get closer to our targets. We can adopt this approach by implementing strategy deployment described in Chapter 15. Strategy deployment takes the Improvement Kata meta-method presented in Chapter 6 and makes it cascade through the whole organization, following the Principle of Mission described in Chapter 1. Bjarte Bogsnes presents a similar approach called “Ambition to Action” in Implementing Beyond Budgeting.²²⁶

Replace Annual Budgets with Rolling Forecasts

Rolling forecasts are one tool that can be useful to help improve financial planning and decrease dependency on the budget. As every period is completed, another is appended to the far end of the forecast so that it always covers the same length of time into the future. The far end doesn’t provide great detail, but does include known cost line items with estimates on what they will be for the period in question. In rolling forecasts, attention is focused on the near future, based on current and accurate information. We don’t spend as much time chasing details further out into the future that are likely to change in an unknown way.

In adopting this approach, remember that the forecasts are not meant to define targets or manage resources. Unless you use an approach such as strategy deployment or Ambition to Action to set targets and manage resources and performance, you will end up with a rolling budget instead of rolling forecasts, which Bogsnes describes as “a bit more dynamic but also four times more work.”²²⁷

As we separate activities required to perform good financial management from the annual budget process, we improve our ability to understand our current condition. We focus on developing flow in decisions and adjustments required to meet the targets we have set for ourselves. The shift is from “Do I have the funding to do what I am told to do?” to “Is this really necessary?”

Disassociate Funding Decisions from the Annual Fiscal Cycle

The use of the traditional annual fiscal cycle to determine resource allocation encourages a culture that thwarts our ability to experiment and innovate. It perpetuates spending on wasteful activities and ideas that are unlikely to deliver value. We must recognize innovation has an ongoing cost that can’t be defined and fully planned a year in advance. We need practical lightweight processes to fund innovation, and to be disciplined about stopping work on anything that’s not generating the desired outcomes.

When an annual process is the only avenue for obtaining funds tied to specific line items or new initiatives, it is nearly impossible to change direction in response to new information. Instead, every year we must spend a great deal of effort to present the best business plan to get as much funding as we possibly can, instead of being honest about what we think we need. Of all the submissions made during this annual event, only those with the most compelling story make it through unchanged. The rest get cut, or put on the backlog for consideration next year, accumulating delay cost.

Instead, some companies are taking an approach known as dynamic resource allocation shown in Figure 13-2. This creates more frequent checkpoints for funding decisions, and each decision has less risk associated with it. All decisions are based on the empirical evidence, so they become easier to make. When done correctly, access to funding expands to more teams, gets more frequent, has less associated risks, and brings better results. We thus encourage more innovation and reduce financial risks associated with large initiatives.

Figure 13-2. Dynamic resource allocation, courtesy of Bjarte Bogsnes, author of Implementing Beyond Budgeting: Unlocking the Performance Potential

The product development model we discuss in this book works well with dynamic resource allocation. When we have a new idea, we must begin with an explore phase. The cost of exploring the idea can be measured in terms of the product team’s operating costs. Boundaries are defined: you can have a small team for a defined period, and the maximum amount to spend is X. Once the team has evidence the idea will deliver value, we can provide further funding to move into the exploit domain. Across Horizon 3 as a whole, we aim to use the Principle of Optionality to manage our investments (see Chapter 2 for more on the three horizons and optionality). Our goal is to invest limited resources in a number of possible options, with the expectation that most will fail but a few will show a large upside.

Teams that successfully exit the explore domain and scale up will begin to practice continuous improvement, as described in Chapter 6, to constantly remove waste in the delivery process. It’s essential to avoid “rewarding” teams that achieve performance improvements by reducing their operating costs, cutting team size, or breaking teams apart. This instantly demotivates teams and kills the innovation mindset. Instead, the team should get to spend more time on exploring new ideas without onerous documentation, reviews, and approvals—as long as they maintain their high performance and keep costs within established boundaries. By creating lightweight processes to approve small blocks of additional funding to support the exploitation of ideas, we keep the momentum going.

By using a product paradigm rather than a project paradigm, it becomes much easier to calculate profit and loss on a per-product or per-service basis. We can calculate the costs of delivering and running a product or service simply through the operating costs of the team building and running it. This makes it much easier to see when the costs associated with a product or service exceed the value it provides, or when we are not obtaining the expected margin. When we want to build features that cut across multiple products, we can use Cost of Delay to make an investment decision (see Chapter 7).

As the value proposition and development and support costs of a product change over its lifecycle, we can change the composition of the team running and enhancing it. Finally, when the product starts delivering a negative value, we should retire it sooner rather than later. Often, an investment is required in order to retire products and services—and, again, Cost of Delay can be used to make an investment decision. This can require buy-in from executives: we know of one Fortune 500 company that gave bonuses to its VPs based on the number of services retired during the year, aiming to reduce system complexity and encourage innovation.

Smaller, simpler, local initiatives involving less risk should go through less review and a lighter approval process than complex, enterprise-level initiatives. Hand-in-hand with this, we need an ongoing process and defined criteria for when funding will cease. Review and oversight can be decentralized by creating local teams responsible for reporting the outcomes of their funding decisions. This can be rolled up for enterprise-level reporting. We still want to maintain high-level centralized control over larger enterprise initiatives, but there should be very few of these at any point in time. See Table 13-1 for some sample funding models.

Getting rid of a highly centralized annual budget cycle does not mean we are shirking our responsibilities for good financial management. Many large global companies, including Handelsbanken, Maersk, and Southwest Airlines, have started journeys to escape large centralized budgets and manage costs through other means.²²⁸ They start by decentralizing financial responsibility for operations and moving it down to individual business units:

§ Senior management doesn’t set the targets for all costs and revenues for the upcoming fiscal year.

§ Critical business decisions are not based on the budget.

§ Teams and individuals are not measured by their ability to stay within budget.

Everyone still has targets and is held responsible for improving the value they deliver. However, these targets are not mandated from the top but set by teams themselves, aligned with the organization-level goals and targets.

Explore Activity-Based Accounting Principles

Resource consumption should be directly tied to activities that generate value. Traditionally, costs are tracked solely by functional cost centers, such as IT, and there is little visibility into what drives these costs. IT departments and teams engaged in product development are often viewed as cost centers that can be managed and controlled independently from the business. Tradition thinking is that sourcing cheaper supply of IT services will reduce costs and provide equally good outcomes. If it were that easy, you probably wouldn’t be reading this book. The reality is that our business drives our IT and product development costs, and we can’t manage them independently.

Activity-based accounting (or costing) allows us to allocate the total costs of services and activities to the business activity or product that drives those costs. It provides us with a better picture of the true financial value being delivered by the product. However, like all models and approaches to business, activity accounting is not a panacea. We need to be careful that we do not pursue unnecessary precision, creating complicated models and processes that outweigh the value we aim to provide. The goal is simply to get better information for adjusting plans and activities to improve value—starting small and stopping when we have enough empirical evidence on which to base our decisions.

MAKING BETTER DECISIONS WITH ACTIVITY-BASED COSTING

Here is a story from work at a former employer that shows how activity-based accounting gives clarity into how technology supports value to customers.

In an attempt to cut costs, our executive finance committee had mandated unrealistic targets for the upcoming fiscal year. They had difficulties relating to the established budget line items, such as cost of servers, and didn’t understand why we just couldn’t reduce our staffing levels and support more people and systems at the same time. To give them a picture they could relate to, we turned to activity-based accounting principle of allocating costs to business activities (operations, revenue management, marketing, customer relations, supply chain management, etc.), rather than the line items in our budget (IT people, software, hardware, IPS, servers, etc.). Our financial management system was not set up to provide this view, and we had a tight deadline, so we used what we had at hand: spreadsheets, current operational numbers, two people, two days, full access to IT senior management for information, and plenty of food and beverages.

We didn’t focus on being 100% accurate or precise: we figured 90-95% accuracy was good enough. Our goal was to give the executives the big picture of how IT costs were related to servicing our customers and the growth of our organization.

Fortunately, we already had a clear understanding of our IT services and costs related to the business activities. We were able to link many costs directly to a business product or service. For example, our customer support center got all of the costs associated with interactive voice recognition software. Other costs, such as email services, had to be divided between business units, so we took their number of people as a measure and divided those costs proportionately. We also allocated specific costs to our own department—those related to department service management and our own consumption of common services.

The output from this effort was a series of graphs and charts that showed how business activities drove the IT costs. When presented with this information, rather than the traditional budget expense line items, executives were more comfortable making decisions on what to support (or not) in our budget submission. Most importantly, everyone got a better picture of the true cost of ownership of business products and services and we were able to better calculate the cost of delay for retirement and replacement of systems.

Avoid Using Budgets as the Basis for Performance Measurement

Perhaps the biggest mistake we can make with budgets is to use them as a key indicator of performance—to base reward and recognition on the capability of an individual, a team, or the organization as a whole to adhere to a budget. Staying within an assigned budget only tells us if we spent or earned as much as we said we would. If we tell teams they are going to spend more or less than they need to do their work, they will find a way to make it happen or spend a great deal of time justifying why they couldn’t. However, this prevents us from paying attention to the most important questions: did we plan at the right level, set good targets, get more efficient, or improve customer satisfaction? Are our products improving or dying? Are we in a better financial position than we were before?

Bonuses and rewards for good bottom-line financial results work better when they are shared equally—not just with upper management and executives but with every employee within the organization. Working teams will eventually cripple the organization by inertia and subterfuge when their contributions are not acknowledged and rewards are based on a process perceived as unfair. Conversely, people tend follow good leaders and make the organization great when recognition and incentives are shared equally with all.

FINANCIAL INCENTIVES WITH POSITIVE IMPACT: THE CASE OF WESTJET

WestJet has been one of the most financially successful airlines in North America over the past 15 years. WestJet’s founders knew that, if they were to succeed, it was essential to create a culture of responsibility and ownership for all employees. To create this culture, they clearly stated their strategy and goals, screened and trained employees for a good culture and values fit, and established financial incentives that benefit all employees.

Twice a year, a portion of the company profits are distributed to all employees, prorated on their base salary. All employees are invited to attend the profit share party where physical cheques are handed to team members by their managers—face-to-face whenever possible, so managers can personally recognize every employee for their contribution.

In addition, WestJet allows employees to voluntarily purchase up to 20% of their base gross pay in WestJet shares, and then matches the employee’s contribution in shares under the employee’s name. In 2012, over 85% of employees participated in this program, becoming part owners of WestJet.

These financial incentives have helped to establish a true sense of responsibility and ownership for all employees, from call center agents to executives. Everyone knows that the decisions they make in their day-to-day work and the way they treat their guests will have a direct effect on the overall earnings of WestJet; they will personally share the rewards, or sorrows, resulting from those decisions.

This approach has helped WestJet remain profitable in a tough, highly regulated industry for close to two decades. As of the end of 2013, WestJet has reported an annual profit in 17 of the 18 years of its operation.²²⁹

Stop Basing Business Decisions on Capital Versus Operational Expense

Concern over capital (CapEx) versus operating (OpEx) expense reporting is important for organizations. There are tax advantages and positive financial impacts from reporting organization expenditures appropriately in these different buckets, so a lot of attention is paid to it. The basic premise of capitalizing software systems is they are viewed as an asset that creates future benefits for our organization. This can have significant impact on balance sheets and, in turn, on the market value of an organization.

Unfortunately, this distinction is often used as the foundation on which critical business decisions are made. It injects another element of complexity into decision making and funding for innovation. All costs associated with any work must be categorized into one of the two buckets, and the traditional process for managing the buckets assumes that a team’s work is one or the other but can’t be both at the same time.

The traditional process also serves to obscure the true cost of ownership and escalates operating costs. A project will be fully capitalized, allowing us to spread out the reporting of that cost over an extended period, so it has less short-term impact on our profit. However, many of the items that are being capitalized during the initial project have an immediate negative impact on our OpEx, starting before or immediately after the project dissipates. The long-term operating costs required to support the increasing complexity of systems created by projects are not calculated when capitalized projects are approved (because they don’t come out of the same bucket). Ongoing support and retirement of products and services is an OpEx problem. In the end, OpEx teams are stuck with justifying their ever growing costs caused by the bloat and complexity created by CapEx decisions.

If we are serious about innovation, it shouldn’t really matter which bucket funding comes from. Open, frank discussion, based on real evidence of the total end-to-end cost of the product, is what we should use as the basis of business decisions. Funding allocation of a product’s development into CapEx or OpEx should be performed by accountants after the business decisions are made.

Let’s look at the explore domain first. Most ideas turn out to deliver zero or negative value—but CapEx applies to assets that deliver long-term value. It therefore makes sense to consider all explore activities to be OpEx. We still need teams to define the amount of resources they intend to consume on exploring, but they shouldn’t need to obtain further funding approvals every time they want to try something new within their defined boundaries.

Moving to the exploit domain, finance and product teams need to talk to each other frequently to determine how to allocate funding. We want to avoid adding complexity and unnecessary waste when we decide on the tracking methods to determine CapEx versus OpEx allocation. It should be easy enough for everyone to understand how it works and provide a fairly accurate representation of the long-term value proposition. In the end, allocating costs into CapEx could be as simple as defining that a fixed percentage of this teams’ resources (or time) are spent on developing assets that have a lifespan long enough to be capitalized. Here are some topics to discuss with Finance regarding CapEx funding decisions:

§ How can we build a flexible model for allocating funds based on CapEx and OpEx principles but avoid using rules and rigid processes that require everyone to compete for all funding at the same time?

§ What elements, other than projected project costs, should affect the amount of scrutiny and rigor we apply to funding decisions: complexity, time estimates, team size, net effect of operating costs, anything else?

§ How can we manage local initiatives versus enterprise-level initiatives to reduce delays and overall response time for local opportunities?

§ How can we structure funding decisions to accommodate shorter time frames and improve availability to more teams?

§ How do we base further funding decisions on demonstrated delivery of working products, as opposed to the amount of activity?

In these discussions, it is important to consider the projected lifespan of the product. Technically, software assets should be capitalized only if the projected lifespan of the product matches or exceeds the current depreciation term for software products—most businesses currently use three years. However, it seems unrealistic to believe that all of these systems have a valuable lifespan of three years if left unchanged. This presents an interesting question. Which is less risky and more responsible:

§ Categorize software product development entirely in OpEx, or

§ Capitalize costs and claim a write-down in the future if the product is retired before it is totally depreciated?

There’s probably no single definitive answer; you will need to consider many variables that are different for each organization.

Modify Your IT Procurement Processes to Gain Greater Control over Value Delivery

In his 1982 book Out of the Crisis,²³⁰ W. Edwards Deming proposed 14 principles of management required for American companies to improve the effectiveness of their businesses. Number 4 on the list reads, “End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.”

More than 30 years later, we see many organizations that have not grasped the true meaning of this principle. We fail to quantify the total cost, and we treat products and services as fungible commodities that can be easily produced by any supplier. While procurement processes used to award contracts may result in long-term relationships, they are seldom built on collaboration and trust.²³¹ The net result is that procurement policies, processes, and practices conspire to prevent us from improving the value we provide through software delivery.

The first mistake we make is thinking that with large amounts of upfront planning, we can manage the risk of getting something that doesn’t deliver the expected value. In many large enterprises, the manager engaging any third party for software delivery services must define all expected outputs up front, in the form of a request for proposal (RFP). This is followed by detailed responses from suppliers as to how they would deliver the exact expected outputs and at what cost, often derived from hourly rates and expenses plus a desired margin. Award decisions are then based on the responses received and presentations made by the groups that make it to the short list.

This painful, highly detailed contractual process has several negative side effects:

It is a poor way to manage the risks of product development

It is based on the misconception that we can know exactly what we need up front—in other words, that while building the system we won’t make any significant discoveries about what users find valuable nor encounter any significant unexpected complexities.

It favors incumbents

Suppliers who already have a presence in the organization have easier access to its people so can better understand its budgets and targets that need to be matched. As the procurement process for new suppliers is so painful, it’s easier to automatically renew established contracts even with mediocre suppliers. The perceived costs and risks associated with finding a new supplier are often thought to be greater than renewing existing contracts.

It favors large service providers

Large companies employ people who specialize in responding to RFPs, which can be filled with minutiae and check boxes but have little or no bearing on outcomes.

It inhibits transparency

Success is usually awarded on cost of delivery, with little regard for the related costs of integration, business process change, or ongoing operational costs. Rarely do we see consideration for how the products provided will affect end-to-end value delivery. Offshore delivery, for example, usually looks inexpensive in terms of unit cost. However, when we take into account increased communication and travel costs, as well as delays in response and rework due to time differences, it can easily take longer than co-located delivery—at similar overall costs.

It is inaccurate

Due to the planning fallacy (see Chapter 2), both suppliers and managers tend to be overly optimistic in their estimates of the number of people and the amount of work required because they know that contract price has the most weight in the decision. Suppliers know they can make up the money with change requests.

It ignores outcomes

Contract performance is measured on the ability to supply services as contracted, at the rate contracted, for the period of time contracted. There is usually no mention of how well the delivered services work. Regardless of outcomes, the suppliers are usually rewarded with further contracts for supporting, fixing, and improving the service.

Tip

If you are stuck with a long term, project-based contract that specifies delivery of a solution at the end of the term, mitigate your risks by offering to pay the supplier in advance, based on the delivery of incremental working software. This incentivizes them to provide you with working software that you can put into production so you can get feedback from your customers on the value of the solution. In turn, you can adjust the direction of the product’s development, based on your test outcomes.

The second mistake in the typical procurement process is that is assumes all services are equal in both the quality of the people working on the delivery and the quality of the software delivered. Through painful experience, many of us know this is not the case. There are many factors that determine how successful the outcome of engaging a supplier will be, the least of which is cost. What is their error occurrence and fix rate? What is the maintenance effort associated with their solutions? How many lines of code are in the solution (less is better)? How closely can we work with them? Can we trust them? Although we may gain some insights by talking to other customers of the supplier, the acid test is experimentation. We need to test out the relationship and measure the result—which requires modifying the processes we use to engage third-party service providers.

UK GOVERNMENT CHANGES ITS IT PROCUREMENT PROCESS TO ENCOURAGE INNOVATION

Early in 2014, the UK government announced dramatic changes to the rules applied to awarding and managing contracts for IT services.²³² These changes aimed to encourage competition in the IT service sector and help the government become a more intelligent customer of the service providers. They believe they will achieve better outcomes in their IT services by limiting big IT contracts and by broadening their source of potential suppliers.

To make it easier for small- to medium-size enterprises to bid on government IT contracts, four major changes were announced in the UK government’s IT services procurement process:

§ No contracts over £100m would be rewarded except under exceptional circumstances.

§ Companies with a contract for service provision will not be allowed to provide system integration in the same part of the government.

§ New hosting contracts will be for a maximum period of two years.

§ No contracts will be automatically renewed.

The UK government hopes to create more efficient and responsive services meeting public demands by getting better access to innovative and cost-effective digital solutions. They are expanding the range of suppliers and creating more opportunities to assess and negotiate contracts that may be based on outdated and expensive technologies or are just not delivering value.

The agile manifesto says we should prefer customer collaboration over contract negotiation. We need to continuously work with our suppliers to produce high-quality results. The best relationships and results are achieved when we don’t throw requirements over the wall and then expect a product or service to magically appear months later. We have to be engaged, manage contracts and relationships, encourage flexibility, and seek opportunities to experiment with different providers so we can assess their competence and capability to deliver value.

Conclusion

Organizations that continue to structure funding decisions around financial cycles will face serious obstacles to improving their innovation capabilities. We need to move beyond the centralized budget paradigm and introduce flow into the processes of financial forecasting, planning, and reporting. This is essential if we want to see more than incremental benefits from applying lean principles.

We should disassociate funding decisions from the annual budget cycle, and stop worrying if it is capital or operational expense. This is how we can make better decisions on what and when should be funded to create the outcomes we want. We still need to manage our costs carefully, but better results can be achieved through shorter cycles of planning, forecasting, and monitoring, along with relating costs back to the business activities that drive them. Restricting resources and time frames for testing ideas helps us to gracefully cut investing in ideas that don’t pan out. Resources can then be channeled into exploring new ideas for products and services.

Finally, to support innovation and experimentation, we need to modify our procurement processes and rules. Without long-term trust relationships based on a mutual desire to get better at delivering value, large organizations will forever be hampered by legacy systems and products that are often outdated before they are even deployed.

Questions for readers:

§ Can your product teams openly experiment with new ideas and technology without spending large amounts of time on seeking approval and funding? Can you easily obtain funds for new technology-related work at any time of the year, or are you restricted to an annual cycle?

§ What are your criteria for a successful investment? Is it enough for projects to come in on time and on budget, or do you attempt to measure customer and organizational outcomes?

§ How much time is spent managing your team’s budget throughout the year, including reviewing reports and justifying variances?

§ How far out and how often are you expected to plan for detailed costs? Is there an easy process for continuous adjustments and reporting within the plan?

§ Does the process for allocating capital expenditure versus operational expenditure prevent people from making responsible investment decisions? If so, is there a simple, low-risk way to experiment with a different approach?

²²¹ [hope]

²²² [bogsnes]

²²³ http://www.bbrt.org

²²⁴ [bogsnes], p. 90.

²²⁵ Activity-based accounting is an approach to costing and monitoring activities that involves tracing resource consumption and costing final outputs [CIMA].

²²⁶ Ambition to Action, presented in Chapter 4 of [bogsnes] from p. 114 onwards, is derived from Kaplan and Norton’s Balanced Scorecard approach.

²²⁷ Personal communication.

²²⁸ http://www.slideshare.net/LESSConf/11-12-what-is-bb

²²⁹ http://www.westjet.com/pdf/greatWestJetJobs.pdf, https://www.westjet.com/pdf/global-reporting.pdf, WestJet Management Discussion and Analysis of Financial Results 2013, http://bit.ly/1v73i6N.

²³⁰ [deming]

²³¹ In the NUMMI story in Chapter 1, some of the problems GM faced in adopting the TPS related to the fact that suppliers were not used to the idea of working collaboratively to improve the quality and specification of parts in response to results in the field. This is a direct analog to the problems we face when we outsource development and, at the end of the contract, find that the product delivered is not fit for its purpose.

²³² http://bit.ly/1v73rXY