Avoiding IT do-over’s

Jeffrey Stewart
Dec 26, 2018 · 6 min read

Sooner or later most companies are faced with the IT task building a new system. What makes this task daunting are the operational consequences of not getting it right.

by Jeffrey Stewart and Victor Gordon

The authors note that there are three foundational questions that business management and their IT partners need to jointly analyze to avoid having to, live with a suboptimal system that drags down the organization, or embark on a costly “do-over”.

As one of the authors recalls, “Years ago I was playing a board game with my then 8-year-old niece. She made her move and when she saw my move she realized with horror her mistake. She loudly proclaimed “Do-over!” and with a speed and dexterity I didn’t know she possessed and before I could react, she quickly moved the pieces back and happily changed her move.

If only IT do-overs, once a system has been deployed, were as easy were as easy as in a board game.

Companies are often faced with a similar situation with IT solutions. Once deployed, shortcomings become glaringly obvious.

Common unanticipated issues include: difficult to use interface, lack of system flexible, limited scalability, high maintenance costs, and metrics that don’t match business needs.

Too often management has to consider the pain of living with a system that does not measure up to the operational realities of the business (Technical debt) or start from scratch.

(See more on 7 causal factors of technical debt in the companion article “7 Factors Leading to Technical Debt and IT Do-Over Pitfalls”)

We have found three key foundational questions that, if jointly planned and managed from the outset with IT business partners, can greatly prevent the pain of ‘bad IT’ or need to consider IT do-overs.

These include established:

• Key stakeholder/business outcomes,

• High-level architecture design choices

• After launch lifecycle resource support plan


What are the Key stakeholder/business outcomes?

The first step is to clearly articulate the desired business outcomes and the benefits associated with these outcomes.

In short, this is a listing of what the organization is trying to achieve with the system. It provides a tangible and measurable future state that cats a North Star for all to follow.

Often it can also be beneficial to describe in detail what the system is not or more plainly — out of scope.

This document can be indispensable in maintaining focus on what is important throughout the development process

Although careful development of business outcomes seems self-evident, experience has shown this is rarely done in enough detail to provide all parties involved with the information needed to aid in evaluating benefits and trade-offs of system decisions.

Also, a common pitfall of this step is to consider the establishment of business outcomes as a one-shot deal to be tossed over the fence for the IT folks to ‘do their thing’.

The key questions that can assist in development include:

• Why do we want to augment this business function?

• What happens if we do not do this process automation?

• How will automation capture or create value or improve outcomes?

Answers to these questions can help galvanize or orient the team in developing creative ways of meeting the company’s intent for the system.

They can also greatly enhance prudent decision-making that weighs the benefits against the downsides such as completion delays, increased project and or support costs, etc.

Be careful to not brush off important, difficult to change decision AND do not spend too much effort on easy to change decisions.

“If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that — they [Type 2 decisions] are changeable, reversible — they’re two-way doors.” Jeff Bezos — Forune Magazine


What are the high-level architectural design choices?

Architectural design articulates how are we going to deliver business outcomes.

A partial list of system components illustrates the challenge of configuring an effective system architecture.

This includes decisions on topics such as hardware, software, cloud services, web portals, servers, security, internet/intranet information flows, etc.

Choices must be then made on how to configure these components into an effective, scalable, affordable and reliable system.

Three key high-level architecture questions that must be answered before the detail work can be effectively completed include:

1) Is the choice based primarily on what tools and techniques we now know, not what best?

  • Am I using the programming language because we used it on the last project?

2) Will the design choice be maintainable in potential longer-term needs?

  • Expediency instead of balancing long-term viability

3) Does it support Values and Principle of successful systems selection, design, and implementation?

  • Simplicity

What are the after launch lifecycle resource requirements?

The after launch costs associated with a new IT system is frequently underestimated.

The initial upfront costs can be thought of as the tip of the iceberg.

For example, software maintenance can make up 75% of the costs of ownership.

Understanding these costs for the entire system can provide clear operational context necessary for clarifying or modifying decision choices.

Key questions to review to bring these costs to light include:

• What are the anticipated costs for infrastructure maintenance and licensing?

• Can the system be cost-effectively updated (future flexibility)?

• Will the technical expertise to manage a system be available in the future?


Using the Foundational Questions to Optimize the IT System

Once the above analysis is completed, it can be used to guide the organization in developing a system that fulfills the business need.

Unfortunately, in many cases, companies complete the above steps in a waterfall fashion.

Once completed it is tossed over the fence for the next team to deal with.

The real value of this exercise derives from reviewing various issues through the three perspectives — outcomes, architecture and required resources.

For example, projecting certain outcomes such as real-time sales reports may not seem as attractive when the operational costs are considered.

This may prompt architectural changes to bring the costs in line to what the company can afford.

It could also prompt a reevaluation of the need for that functionality as cost realities call into question, is it really being worth it?

Conducting this type of analysis with a broad range of business partners and IT personnel also provides an efficient method to infuse these plans with organizational context and knowledge.

System cost and performance trade-offs can be made with clarity and purpose and most importantly minimize unintended consequences.


Conclusion

Admittedly it is difficult to thread the needle in developing systems that, satisfy business needs, are designed well, and are affordable in the long run.

However, by using the three question presented in the article with the appropriate stakeholders throughout the development process, it is possible to uncover many of the issues that are hidden until the system is deployed.

This allows the organization to optimize choices and avoid mistakes in the safety of a conference room — much the same as taking back move on a game board!