IT Business Management

1. Be Deliberate

Boeing has been successful for over a century, and a company like that has to deal with the fact that their way of working has served them well. In this context, you cannot change things easily, everything is interconnected. And inertia, of people, their process (whether good or bad) is currently accomplishing something useful. So, how do you go about changing things so you don't cause harm?

A lot of the work in Enterprise IT is done to support the business, full of people that know their technology and process can improve. They know that technology-enabled products and services are equivalent to the competition. There is a ton of demand for new and improved capabilities that digital technology promises. And unfortunately, IT struggles to keep up with delivering on that demand. But why?

The Business tends to think about IT as a necessary cost. Using the language of scarcity, even those of us who work in IT feel we cost the business money, repeating the oft used term "cost center." This can lead to the misconception that costs should be reduced, that we need to control the projects, and avoid poor choice. Remember what happened with that one initiative that ran over budget and was two years late? We can't make that choice again! This suggests that all work that gets approved has approval and needs to meet requirements, leaving little room for experimentation and learning.

In the IT PMO, I learned that one of the biggest gaps in making progress in IT is the lack of clarity around just what work is being done and why. Strangely, for an environment that feels the need to have everything figured out before work begins, very little is given to the context of how one effort relates to another.

We didn't have the right lens with which to see what our team's outputs were that drive value for the business. The reason why Agile practices are so important today is to reduce the risk of being wrong for too long. Naturally, any idea will need to grow, be tested, and adapted to the circumstances of a real-life scenario. And yet, even in Agile teams, we suffer from being wrong for too long. Not because teams were not producing enough features, but because the system is complex and teams struggle to see the bigger picture, even a slightly wrong one. We struggle to link IT improvements to the business value they enable.

In a large complex system, making change is hard and will have unknown consequences and risks. We hear that we should focus on outcomes not outputs, fail fast, and iterate. But when you're on a product team, designing and developing something that might replace an outdated Enterprise Resource Planning (ERP) application, just which outcomes does one start with? How do you define an outcome for so many people? You feel like you've failed before you even get going. We don't want failure, we want clarity. We need to fail safely.

Failing safely starts with really understanding the business, and knowing who can inform those business processes. The other way of framing it, as you might have heard by now, is to "learn fast." Our challenge in an IT PMO, an office that is supposed to support the lifecycle of a project, is to fill that gap between "idea" (aka "business case") and the kickoff of that initiative.

Teams often have to rework all sorts of items and struggle to get going. The IT PMO can help guide teams by translating the business case into the objectives and key results that relate to a business value stream, so teams can connect product features, user stories, and user outcomes to the business impacts and KPIs as requested. This kind of support will help teams learn fast and fail safely.

"Being deliberate" means you engage with the Business, to understand their KPIs, how they are important, and how the business generates that value. Where IT teams get lost is the distance they have from the value the business creates. IT, for the most part, is non-value added, in the Lean sense of the word. The primary reason people in the Business side (and IT) still thinks of IT as a cost-center.

Recall that an IT product helps an end-user, typically in the business, do something useful that will add value for the customer. An IT PMO fails to support teams if they do not give them the thinking tools and methods to connect Value-Enabling IT products to the actual Value the business delivers.

We in IT PMOs need to be the stewards of value for the IT products that are being built. By laying the groundwork that enables product delivery teams to make connections between their IT products and the way their business partners want to use those products. We in the PMO must be deliberate in our service to those teams, by showing examples, inspecting and adapting with teams as they learn from their assumptions, and be a role model to help clarify their product's purpose for the business. 

By showing IT teams how to consume "business cases" and "requirements" and challenging them to reframe those into benefit hypotheses, user-centered outcomes, and measurable impacts for the business, the PMO can provide a bridge to deliberate practice. Only then can teams Be Agile.

2. IT Governance

Working in a PMO is not as straightforward as it has been in the past. PMOs are undergoing a change from the "additional layer of bureaucracy" they were in the past to an adaptive, customer-centric, servant-leader model of change and strategic insight that few other organizations in the business have for responsibility.

In the past, PMOs were focused on making up process and directing people to follow the standards that were copied from other places. But it was difficult to show that these efforts were effective, and even if they were, the people these processes affected often reported that the PMO felt like a policing function more than anything else. As if to reinforce what had been learning, just after I joined the company, I introduced myself to a coworker in an enterprise architecture role, who said something to the effect of "Oh, the PMO, that's who we call when things go wrong."

But PMOs can't promote change this way, and what you most certainly get when you mandate hard to follow process or compliance activities (or even moderately reasonable ones) are people that try to avoid you and do things under the radar. 

Governance is about steering the ship in the right direction. The PMO is supposed to help guide and steer, to get data from teams to help them see how the initiatives they are working on are doing and if the products they deploy to end-users are having the impact our directors want for the business to achieve.

I joined the PMO in IT at this critical moment. Turnover was high and the group lacked clear direction. This holds for other PMOs as well, as the uncertainty about what a PMO's role is and how they should operate differently from their past.

To help orient myself in this complicated space, I knew we had to get a handle on what exactly IT does for the business, and how people accomplish their work managing IT initiatives. To get a broader picture of where the PMO fits in, one has to go all the way up to the Board of Directors. (Though unfortunately, I didn't get to interview them!)

Governance starts at the top, and strategic direction flows to management who act according to their discretion. Management decides what things to do that they believe will achieve the strategy. Leadership directs change at a pace they believe will positively affect the business. And management makes those changes happen.

While we all want changes to happen at a pace the business can tolerate, it is different for technology, isn't it? IT is changing so fast the business is at risk of being left behind. In enterprise IT, we almost have the inverse of governance, we're not even sure which changes to direct. And even when our govenors try to give us commands, the field of play already looks different. To add insul to injury, there is so much demand for change that we can't do it all at once even if we had all the resources. 

The IT PMO plays a central role in establishing and maintaining an IT Business Management platform that helps managers and their delivery teams ideate, plan, design, build, test, deploy, release, and monitor IT-enabled products and services that can be quickly consumed by the business and adapted for changing needs. The PMO should be involved in helping teams create the telemetry they need on their products and services so they can assess how it performs for the business. And use that feedback to help the business and IT management make better bets on what might work better. 

IT Governance isn't just about making business cases and tracking costs of running IT products and services using off the shelf portfolio management software. To govern IT is to use the power that IT gives to the business and leverage it for the benefit of managing IT for IT.

To do that, IT Business management professionals need to think about IT as a production system and view the value chain of IT. They need to visit with development teams and see how they make sense of their mission. The PMO can help teams see their role in the bigger picture, one that enables value within a business value stream. If you can help teams identify the IT products they work on in the context of a business value stream and if teams can contextualize this (or even to help them realize how much they still need to discover), you have empowered teams to be self-organizing and able to establish the right feedback loops.

The PMO must help map the flow of IT value and socialize this across IT. We must also meet the teams that produce and support those products to understand what slows them down. Guess who gets blamed by those teams for introducing friction? That's right! The PMO and other governance, risk, and compliance teams.

Mik Kersten, author of "From Project to Product" provides a useful concept and methodology called the "Flow Framework" that can help operationalize this understanding of the IT production system. Once you have the team's delivery and operational value chain captured, and you map where their products and services fit into the bigger picture as part of a business value stream, you can model the key outcome-based variables you believe might have an impact for the business.

And once you have that, you have the beginning of strong problem and solution hypotheses; A way to make informed choices with data that will give one the necessary insights to manage IT delivery. And with that, leadership can steer the ship and govern IT for the benefit of the enterprise and the customer.

3. Technology Business Management

I did not expect to focus as heavily as I did to navigate the landscape between business and finance. But I discovered that in enterprise IT, a complex system, it is difficult to translate the money spent in IT into products and services used by the business and its customers. In many ways, it's easier to define the business' customers and what they do (and are willing to pay) than the internal spend on IT for a particular function and set of business activities.

At the heart of good product design is the ability to design effectively for the business, to hone in on a problem and solve it. A good design process can conceptualize how different people and goals fit together to tell the story of the people and the technology products that create a success story. We must, in design, be able to imagine multiple possible futures and work with our partners to understand where we want to go next. And tell that story.

In technology business management IT, the business, and finance want to use a management system that can quantify technology demand, current value, and expected benefits of technology use at the enterprise. Each function provides different and necessary angles. Taken together, we can manage IT as smartly and strategically as we would our business. 

Meanwhile, back in the PMO, we want to know what initiatives are contributing to key targeted improvements. And yet, without a shared concept to drive our conversations about "targeted improvements" we tend to fall back on conversations about cost, scope, and time targets, thus optimizing for the so-called "plan," even if there are flawed assumptions driving the project.

What we need, is a common connection to a higher order organizing principle that gives us a shared way of talking about and working toward the lofty goals of "improving the business." With so much that needs to be improved and no easy way to figure out how these different initiatives will work together, we make little progress, and when we do, it is more from luck than from any real deliberate effort at learning or adjusting the plan.

The key, I believe, to creating that higher-order organizing principle, and as recommended by a number of product-centric authors, is the business value streams. By looking at the activities, personas, information products, and the "jobs-to-be-done" across a unit of value being delivered (either for business enabling or of value-added activities), multiple stakeholders and teams can communicate and locate their share of responsibility around key personas and technologies that help or hinder the flow of value. And we do not have to have it all figured out before we begin to make educated guesses and try to change things. Oddly enough, we do it anyway and act as if we have certainty.

I believe an IT business management system will need to play a role in helping teams define and elaborate on which value streams they touch on, who their personas are (i.e. customers, stakeholders, end-users, etc.) and what these personas are trying to do. With that management system, teams across IT, and the business can look at and analyze particular moments of frustration, errors in data, a business process that could be changed, and sometimes automated. We really would be able to know what initiatives are contributing to key targeted improvements and leverage IT as a strategic advantage.

Designing an IT business management system is an exercise in learning the languages of many different stakeholders and using them to reflect back to each other how we understand the purpose and intent of IT. Each stakeholder across the finance, IT and business perspectives bring important and unique insights, and when used together, can allow improved understanding of how the business is currently performing in the design and delivery of IT products and services that support business value streams.