On Tuesday we looked at using your exception-handling process to conceive and drive strategic improvement. Today, we will look at how pre-planned projects should be positioned to maximize their strategic value.
Something I used to tell people is that technology is not a good in-and-of itself, instead it is valuable as an “enabler” for improving something. As a result of my years doing massive transformation projects, I no longer believe this is an adequate explanation. While it’s true that a new tool or redesigned process can enable improvement or growth, if that’s the only thing it’s doing you’re missing major opportunities. If you’re going to go to the effort of doing a substantial project, it should actually propel you forward – not just enable something.
The issue with "enablement"
Some years ago I had a client who brought my team in to analyze, plan and ultimately implement a large systems transformation project. The core of the project would be replacement of a very old, cobbled-together ERP system that was no longer supported, but it would also include a number of enhancements to various boundary systems like CRM, data management, and warehouse management systems. In addition to core benefits like saving on support, less downtime and some replacement savings, the business case included a number of high-value opportunities like such as a) Automating inventory replenishment to match projected demand; b) Enhanced project profitability reporting; and c) When it was being sold to the business, executives and ultimately the board, the main selling point that the project would “enable” change in the enterprise. This was a mistake.
This messaging was interpreted to mean the project would enable them to operate their business a little better because the technology was newer, but wouldn’t substantially change the nature of their operations. As a result, as leadership responded to issues, new requirements, staffing shortages and budget constraints, higher-value “transformational” pieces of the project were shelved and it gradually devolved into a systems replacement project. This resulted in several high-value pieces of the business case going unrealized (they never tracked actual results to the business case either, but that is a post for another day). The project was successfully implemented and everything that was ultimately designed worked really well, but there was still a lot of value on the table. So what should we have done differently?
Why is the language important?
When I think of successful technology investments, I want them to drive the strategy forward. What we should have said was the project would help “drive strategic improvements into multiple areas of the business” or that it would “propel the change that was required for them to react to new market conditions.” Although it sounds like an overstatement, either of these would have been absolutely true. Most importantly, it would have changed how the executives and business leaders reacted to project exceptions:
- They would have been more eager to put their best people and most influential leaders in key positions since they would be setting and executing strategically important parts of the business
- They would have been more aggressive about insisting on changes to their processes and job responsibilities
- The project would have received more visible and more powerful executive
- There would have been more accountability for justifying the cost of the project by measuring actual benefits
Evolving to technology projects that "drive"
When I think about these projects now, I look at them in four ways:
In the pictures below, the orange dot represents the area the project will impact. The other dots represent four related but distinct areas of the business.
Some system is outdated or incredibly unreliable so it needs to be replaced or upgraded. See my post from Tuesday on how to make this project more of a game changer. I won’t re-hash this again today
How does the new solution improve its focus area?
Example: If you’re replacing a project accounting solution, does it make the function of project accounting easier and more accurate?
This is sort of the “enablement” bucket. Am I improving this immediate area and making it easier for other areas to improve as well?
Example: When I implement a new project accounting solution, can I make it so the project values are visible to my receivables department and then train them to prioritize billing and cash collections by backlog and revenue?
Projects that drive strategy
These projects drive the implementation of high-level strategy into the business and force the organization to implement, track, and improve on this strategy. These would achieve holistic transformation across the business and, in addition to achieving its core mission, force meaningful change in other important areas
Example: if your business is a products business but sees most of its future growth on the services side, when I do the project accounting project in points 2 and 3, do I change the expectations of my accounting department to not only track costs for engineering projects but also be able to report on profitability, labor time and expense, automatic estimate-to-complete, etc.? Then can I also change how projects are sold, staffed and billed based on historical data to make them more profitable and improve their quality?
Now is the time to re-frame the conversation
Technology is now going to be part of all strategic decisions you make. This year, all executives should understand how it interacts with your overarching strategy to make sure you're getting the most value out of your investments. Each investment has the ability to drive you forward; not simply to enable incremental improvement.
Last in the series, coming on Friday 1/8: Technology and talent: How tools should improve your people