Tag Archives: transformation

Goals. We hear them. We read them. We are supposed to strive to achieve them. What happens after a goal is set – and decisions are made? How do we maintain sight of the original goals? Instead of using project completion or technology deployment to measure success, many companies have started to find measurable value with business capability evolution. Let’s explore how planning capability evolution will increase the likelihood that execution matches strategy and your business goals are met.

Here’s a generic (far-fetched, but relevant) scenario:

CEO: “I want predictive analytics.”

CIO: “Ok, I hear you.”

The CIO shares the request with his team.

CIO’s team to CIO: “In order to provide predictive analytics, we need to upgrade our ERP system.”

In this scenario, the conversation quickly shifted from a high-level need for predictive analytics to an implementation choice of upgrading the ERP. Someone, somewhere, will get a chunk of the funding to implement various systems, technologies, or practices – including that ERP system. Unfortunately, this has become a glorified game of telephone, where no one is paying attention to the original goal of providing predictive analytics for the executives. Here’s the problem: the disconnect has already happened. The IT team works hard to achieve the goal of the project – upgrade the ERP. Months later, they host a small party to celebrate a successful upgrade to their ERP. Of course, steps or tactics are required to deliver business outcomes. In this case, the company needs to upgrade their ERP to deliver predictive analytics. Unfortunately, as happens at many organizations, the focus shifted from the business capability onto the tactic, and through no fault of their own, the team lost sight of the original goal.

Let’s consider this scenario with agility added to the mix of project execution. Early and often, choices are made where the project’s path can be altered irreparably. In our example, the conversation veered off-course when the main objective shifted to become the safe delivery of the ERP upgrade. If your target was set based on a technological choice intended to achieve an outcome, and not the specific outcome itself, then you risk making decisions and taking actions that don’t contribute to achieving the original goal. At each step, remember to ask yourself, “Are we on the right track to deliver the business outcome the executives expect? Did something change?” Even further, are these questions being asked in the context of supporting a capability or are they in the context of deploying a project? Context matters because the answers will drastically differ depending on the actual goal.

Working sessions and meetings could result in pivot points that might change the course of the project. If you start the project with smaller pieces (milestones) in mind that are defined in the context of the capability evolution (business outcome), then the pivots are made to stay in alignment with executive expectations. If you are measuring success based on the achievement of the capability evolution then you won’t lose sight of the project’s original intention. You’ve changed your mode of thinking. The project still exists, but it will be funded through capability evolution. When procuring technology to support the evolution of the business capability, you’re buying/enabling abilities with a business outcome-driven mindset, not just technology for the sake of technology.

Gartner1 states that “by 2017, 60% of Global 1000 organizations will execute on at least one revolutionary and currently unimaginable business transformation effort.” The ability to track strategy as it relates to concerns, business drivers, influencers, and issues is directly related to projects making or missing their mark. A capability-based approach to project execution is your answer to tracking strategy. According to Gartner, “almost 90% of transformation projects miss their mark.” Organizations that fund business capability evolution will close the gap between strategy and failed implementation. It’s important to detach your thoughts from legacy constraints because, when you’re tied to implementation, your scope can become very narrow. Looking at questions or concerns from a capability perspective is an abstraction of thought. Don’t focus on “how” you do it. Focus on “what” it is that you’re doing.

The Enterprisers Project states that “when faced with a business challenge, business leaders often have a good idea where they need to go and how they must evolve. But there is often a mismatch in how prepared they perceive their organization to be, and the cold, hard reality within their walls.” Let’s take a step back and look at the initial conversation about the request for project funding. When trying to get funding, stop talking about projects or technologies or roadmaps or backlogs. Instead, focus the conversation on capabilities. If you talk about, and lead with, capabilities, then to some degree, technology ends up being what enables everything. You’re bound to get much farther in the conversation and become the bridge between reality and perception.

Business leaders seek to manage complexity and create visibility into and traceability of their business and IT landscape, but what does that really mean to the funding and evolution of business capabilities? Keeping a focus on capabilities that are delivered is critical to success.

Innovation comes from giving teams space, some constraints, and a bit of time pressure

The long history of business IT has been one focused on efficiency and optimisation. From the early days of computing power being used to help food manufacturers to crunch numbers, enterprise technology has been focused on automation and process improvement. The CIO has been, as one of my old bosses used to put it, “Director of Gross Margin”.

But today the game is changing. IT is upending many sectors, and even those that are structurally immune to being Ubered are seeing significant shifts in customer expectation as everyone raises their digital game. And here lies the central challenge for IT: to be able to both optimise and innovate.

In my work at the moment there appears to be one area where this transformation is starkly in relief: the world of collaboration.

Collaboration means people working together. It also means a category of software product. And IT groups need to be extremely cognisant that not only does the latter not guarantee the former, but also that teams that are able to collaborate effectively (not just efficiently) are crucial to an organisation’s ability to innovate.

You don’t innovate through optimisation of processes. You don’t, crucially, get insight from poring over masses of data – much psychological and neurological research shows that true moments of insight are most likely to be triggered when the brain isn’t thinking “logically”. Innovation, as soft and as woolly as this will sound, comes from giving teams space, some constraints, and a bit of time pressure. Good tools to support that can then help.

Think about that when you are next reviewing a business case for collaborative tools in your organisation. What’s the story? Is it one of efficiency and person hours saved? One of cost effectiveness in infrastructure? If your organisation is driving purely for efficiency, then great. But if innovation is on your agenda, collaboration itself should be seen as a crucial lever, and so effectiveness should be as big a goal (if not eclipsing) efficiency targets.