As companies move to become a digital enterprise they are often faced with a serious disconnect between their desires, strategies and execution. Building a digital enterprise takes considerable time and money, as the business needs to build new high-impact customer facing applications while revamping old, legacy IT systems and architectures.
In today’s digital age, execution is not just about delivering software. Executives need to implement business strategy with customer-facing technology, integrated with internal systems and data, all with seamless process and operations. And even if your organization already has a strong software delivery capability, you might be building the wrong products, or a least, less valuable products for customers.
An effective portfolio management process that focuses on critical investment decisions and delivering the highest value each and every day, rather than focusing on heavy artifacts and outdated processes, can have a major impact on the effectiveness of your digital transformation.
Here are six lean principles for how to do so:
The first major shift required for your technology organization to deliver more value to the business and customers is to focus on the outcomes you’re trying to achieve. Whenever a new project or product gets funded, make sure all stakeholders are aligned and agree on the underlying driver for doing work in advance.
Is the goal, for example, to build a new platform to consolidate systems and cut costs? Or is it to attract a new customer segment? Clearly defining the desired outcomes provides a way to measure and track whether the work is providing value to the business and customers or not.
Instead of funding and tracking how much of a platform has been built, fund and track how much has been saved from consolidating systems so far, or how many new customers you have acquired. If your investments are not providing the value you need, the work should be stopped.
Once you are clear on the desired outcome or value of a particular opportunity, it is much easier to prioritize based on which opportunity will have the most value to the business rather than on internal politics.
For example, if you have seven opportunities which will reduce IT costs, you can choose to pursue the one with the greatest ROI.
Make sure, however, you are not comparing apples to oranges: if cost saving opportunities and new growth opportunities are prioritized out of the same bucket, short term gains will always win out over long term investment, to the detriment of the company’s future. In practice, this means your prioritization metrics should consider both qualitative as well as quantitative measures, to ensure that overemphasis on profit doesn't stifle new opportunities for innovation. This brings us to the next important point.
Spending should be intentionally allocated in advance towards achieving key outcomes, rather than on a first-come first-serve basis. Don’t let your IT or technology budget be at the hands of ad hoc requests—instead work with the business to understand how much they want to invest in different areas towards achieving key outcomes.
Let’s say, for example, that you have a goal of expanding into a new market this year. First you should decide how much it is worth investing in achieving that goal and only then should you decide on which initiative(s) to fund within that budget allocation.
This prevents overspending from paying more to implement something than it is worth. And it protects against underspending on important future innovations, due to the loud and urgent demands of the immediate business needs.
In a competitive business landscape it is enormously important and valuable to be able to respond to changes and quickly move in a new direction. This kind of flexibility can be achieved from using agile software practices, which allow teams to deliver work in an iterative way. Instead of investing and allocating budget for a two-year program, break it down into smaller phased releases such as pre-alpha, alpha, beta 1.0, beta 2.0 and so on.
At any point in time circumstances can change—in the market, internal budget, customer feedback and so on. This kind of incremental delivery approach will result in both faster speed to market (from incremental value delivery) and de-risk your investment (from incremental funding).
Even with small frequent software releases, you can’t assume your project or product is meeting the desired outcomes. At each release you should be testing with real customers, even if it is a small set of early adopters. Whether the customer is internal or external, they should use your software in real world situations not simply a lab environment.
Since you have clearly stated assumptions and success metrics you will be able to test and measure whether or not desired outcomes are being met. This is the essence of “Lean Startup” practices to “build, measure and learn” with each release.
This allows better business decision making on whether to double down, pivot or stop investing in a particular initiative, and put that money to better use for the company. In order to be successful at this you’ll need to get into the habit of decoupling the problem from solution so you can test and learn whether the current solution is working or not.
It is far easier to commit to starting new work than it is to complete or stop ongoing work. Often organizations have far too much ‘in flight’ and don’t realize the extent that all the context-switching, multi-tasking and multiple dependencies are dragging their ability to deliver down to a snail’s pace. (Jim once had a client that had 44 ongoing projects for 42 staff people and they wondered why nothing ever got finished. This same client also considered an 18 month delivery to be a “fast” project.)
One of the best ways to cut down work in progress and speed up delivery is to have a single, dedicated, cross-functional team work on a single project, product or outcome at a time. Think of these as self sufficient or encapsulated teams, that can do their job without major dependencies on others. Once they complete their current task, they move onto the next highest priority task. This is the essence of Kanban.
Assigning work to a dedicated team makes your delivery capacity abundantly clear: If you have 50 teams, you can only do 50 streams of work. If you want to start something else, you must wait until a team completes their stream of work, or stop (kill) that stream. A lightweight portfolio management process will allow you to adapt and move quickly by regularly (re)prioritizing small batches of work. This mode of operating is far more flexible and efficient than maintaining a highly complex scheduled sequence of projects.
Remember that investment decision making is equal parts analytical and political
We are often asked, “How do you set priorities in an agile environment?” The situation behind this question is usually, “We suck at setting priorities.” Those asking priority questions hope that some newfangled agile process, will “fix” their current muddled prioritization state. But the barrier to effective priority setting isn’t process—it’s dysfunctional politics and lack of trust. Having a culture of trust and healthy, collaborative politics is an important aspect needed to implement these six principles.
If your organization is getting incremental outcomes in a world of exponential opportunities, or your expansive digital strategies are failing to connect to your delivery capabilities, maybe the disconnect is in your approach to portfolio management. If your portfolio management is stuck in a traditional process and artifact oriented approach it may fail to capture fleeting value opportunities, take too much time to deliver, and fail to adapt to new needs quickly.
If so, replacing it with a decision-driven, feedback rich, fast iteration, and innovation-centric approach should be high on your list of priorities. If you see any of these opportunities or problems in your organization, maybe it’s time to re-examine your portfolio management process.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.