Do You Know What Your Digital Teams Are Delivering?

Your IT Arm May Not Deliver What You Think They Are and How to Change That

What are your digital teams delivering? Most executives and managers who rely on information technologies to operate their business would probably answer “business solutions” or “working systems.” That’s fair—and I wouldn’t expect answers much different from all the business people I’ve worked with in the past decades—but unfortunately incorrect.

By R.M. Bastien | Chartered Managers Canada

Nothing is wrong in expecting troops of tech-savvy professionals to deliver a new customer order management system, for example, or a revamped auto insurance quoting application that has cool image recognition capabilities. But quite surprisingly to most of you, these are not what your digital teams are fundamentally delivering.

The key to understanding what digital teams really deliver is to look at how their performance is measured. Each individual could has performance targets different from all others, so we need to look at the highest level of performance measures.

In most organizations, digital technologies are headed by a senior executive, usually titled as the Chief Information Officer (CIO). If we take the two examples above as what’s expected from the IT arm, it wouldn’t make sense if the CIO’s annual objectives be “Improve by 15% the number of customer order management systems delivered.” That would be nonsense, since there is only one system needed. Similarly, a performance target such as “Deliver the auto insurance quoting application” may sound like a better fit, but in a typical mid-to-large enterprise, this means putting a list of several dozens (when not hundreds) of planned deliveries in your CIO’s annual objectives list, which would be cumbersome.

Logically, most enterprises fall back to a more generic and encompassing measured expectation for their IT arm: “Deliver on-time and on-budget all technology change endeavours.” Such an objective has the benefit of applying to the entire realm of potential uses of digital technology, without knowing in advance all that has to be done in the next year. The catch, however, is that what is metered and serves as a base for gauging performance is now an endeavour. And how are endeavours universally delivered? Via projects, of course, and that’s why corporate IT arms have had a project management practice in place for decades now.

So what IT teams really deliver to you are projects. Of course, each project has its specificities about what exactly the team must deliver. For example, one project has to deal with the types of automobile images to be recognized and another with the list of products the customer will be able to order. But considering that the variety of solutions is so ample and because the ultimate gauge of success is to be “on-time and on-budget,” what has to be delivered becomes secondary from a performance point of view. Anything else related to the output of the project either remains anecdotal or understood only by those who know exactly the details of what is delivered. On the other hand, everyone understands time and money.  In my career, I cannot count the number of times that I’ve heard the phrase “delivering a project” imbedded in conversations in the ranks of people involved in making technology work to support business.  There’s nothing wrong with such an appellation: it just means that that whatever is being delivered, in terms of tangible systems improvements, is not relevant in the conversation; it’s the process of conducting a project that is.

In order to perform the best they can, IT teams gear themselves for effective project or program management. Project management offices (PMOs) are in place. Project costs are diligently tracked and reported. Schedules are put in place and progress is monitored against them systematically.

And all that is just goodness—from a project management point of view, at least. But back to the original question: What do digital teams deliver? Projects. Delivering projects rather than business solutions or working systems however has a negative impact in two areas: business value and system’s quality.

The Assumed & Unknown Business Value

No one would think of starting a technology-based endeavour without envisioning a goal of some improvement in business performance. That’s why business value is on everyone’s lips in the early stages, when tech-based projects are still one-liners on a list of future investments, when cost-benefit analyses are performed and when high-flying cost estimates are compared to predicted returns. If the endeavour seems reasonably paying, monies are then set aside for it.

But your corporate IT arm will not truly get involved until the right conduit is created: a project. When the project starts—often 6 to 12 months after the investment decision—everyone in IT assumes that there is business value behind the investment.

And this assumption can go a long way unchallenged. In decades of tech-project involvement, I have still to see a case where an IT team starting a project would challenge the business performance returns of the endeavour. That’s because they lack the required knowledge to truly understand business value and are not geared for measuring it. And what’s more, delivering projects is their daily bread-and-butter. Why would they want to scuttle the ship?  If sometimes you have doubts about the business value brought by digital investments, then I will not reassure you, because I am convinced, after decades of digital deliveries, that your doubts might be founded.

Being project-oriented not only jeopardizes sound investment value management, it also puts at risk important qualities of the resulting systems.

Neglected Qualities

Projects are by definition temporary endeavours. They have a start date, an expected output and an estimated end date. From a project management perspective, all events that happen before the start or after conclusion simply do not exist. But the resulting digital system, however, will be around for years to come and may be subject to future change projects.

The effect of the project orientation of corporate IT activity on the quality of systems in place is insidious: priorities and decisions are systematically skewed toward project imperatives rather than system imperatives. Quality controls focus on achieving project-scheduled objectives first.

Any quality criteria that have an impact on such things as a system’s maintainability, adaptability or total cost of ownership never receive the same attention as those that could impact project delivery. And since the technical characteristics of systems that make them easier to maintain or to adapt usually require more time and money within the project, these considerations are quickly tossed aside. That’s why digital systems in place in most organizations suffer from a lack of forward-looking engineering and design. Note that it has nothing to do with technology: priority-setting transcend all technologies and fields of work.

Segregation & Measures to the Rescue

These issues have been around in other fields for some time now, and they are not insurmountable for IT.  Understanding the true roots of the problem is a pre-requisite for devising solution paths. Once understood, resolving them requires elementary managerial action. For reasons that are yet to be revealed to me, these simple management solutions have not made their ways into corporate tech teams. The first route is to get rid of conflicting responsibilities within the one and only IT team. The second is to have measures in place that are coherent with accountabilities.

The Single-Desk IT

In this book, we provide details about the conflicting roles that are typically attributed to corporate IT teams and demonstrate why most digital teams have too much on their shoulders. When all tech-related chores and responsibilities are corralled into a team ultimately reporting to a single C-level executive, the team’s behaviours are skewed toward the top-most measures of performance of the whole team. As we saw above, delivering on-time and on-budget still sits at the top of the corporate IT food chain.

But there are accountabilities that should never sleep in the same bed: delivering projects and delivering value, building something and controlling its quality, defining what solutions should be and implementing them. By keeping these under the same corporate IT umbrella, small and big decisions happen day after day that favour one aspect to the detriment of another without effective counterbalancing safeguards.

Measuring What Counts

Once the pie is split to strike a healthier balance, the agreed-upon metrics that will show progress and performance need to be coherent with the accountabilities. Being accountable for everything under the IT sun but being quantitatively measured on only a few doesn’t foster improvement in several key areas. Given the importance today put on delivering change, then key areas like systems asset management, business value management, or quality management cannot be anything better than mediocre. How could it be otherwise? What is not measured is not managed. What is not measured cannot improve. And since the single-counter model for IT involvement in organizations has been there for ages, there has been little improvement.

But let’s be positive: any small improvement is bound to yield substantial advances. If you want to know more about the rock-bottom root causes of corporate IT sub-par performance in some areas, I invite you to attend this seminar entitled “Twelve Truths About Corporate IT,” designed to help non-IT business decision makers quickly understand and solve these issues.

Join us, and learn how your digital teams can start delivering value—not just projects.

About the Author:

R.M. Bastien can be reached at rm@rmbastien.com or via LinkedIn at https://www.linkedin.com/in/rmbastien/

Over the course of three decades, R.M. held multiple roles in the IT departments of midsize to large organizations: programmer, business analyst, tester, database administrator, solution architect, data architect, enterprise architect, systems integrator, as well as several IT management positions, leading teams of IT architects in insurance, travel and transportation, telecommunications and banking.  As an IT project management professional, he delivered projects of all kinds and oversaw the implementation and continuous improvement of project management offices.  He is now helping customers re-think their organizing model to get how more value from information technology with the use of basic organizational strategies.

R.M. holds a bachelor’s degree in management information systems and a research-oriented master’s in business administration. He’s been a certified project management professional (PMP)© for sixteen years.