Using the Question Game for Business/IT Alignment

One of the most important enduring challenges facing CITOs is making sure that the technology portfolio is aligned at all levels with the needs of the business.

One of the most important enduring challenges facing CITOs is making sure that the technology portfolio is aligned at all levels with the needs of the business. In my view, there is no secret to this. Alignment comes from awareness. Awareness comes from a sincere quest on the part of the CITO and the business executives to understand each other. Out of that awareness, the best possible portfolio of applications and infrastructure can be created and gradually tuned and improved.

While there is much written about the topic of alignment, I think most of it is overthought. As William Penn said about government:

There is hardly one frame of government in the world so ill designed by its first founders that, in good hands, would not do well enough; ….. Governments, like clocks, go from the motion men give them, and as governments are made and moved by men, so by them they are ruined too. Wherefore governments rather depend upon men than men upon governments. Let men be good, and the government cannot be bad; if it be ill, they will cure it. But, if men are bad, let the government be ever so good, they will endeavor to warp and spoil it to their turn.

I believe the same is true of systems for business and IT alignment. We need not have an arcane methodology, but rather sincerity, humility, and good intentions.

That said, I propose a simple system for achieving alignment called the Question Game. I suspect if we CITOs can learn to play this game, we will be able to achieve and maintain alignment in a meaningful way.

But to understand what the game is and how it works, I first must set the stage.

Lost in Translation

Nigel Green and Carl Bate, two consultants from Capgemini, made a profound observation about how business and IT interact when attempting to solve problems in their book, Lost in Translation.

Bate and Green pointed out that when business executives sit down to explain what they need to IT staff, the conversation quickly goes off track. Here’s a typical pattern:

• The business staff starts explaining their problem and what they want.
• The IT staff listens for a bit and starts brainstorming.
• The business staff, which is not expert at setting forth requirements, runs out of ways to describe its needs.
• The IT staff fills the gap with proposals for how to use computing mechanisms and infrastructure to solve the problem.

Then, with an inadequate description of the needs, the IT staff builds an inadequate solution.

Green and Bate’s solution to this problem is to create a new language that separates the technology from the description of what the system should do. They suggest that the business explain the Values, Processes, Events, and Content in the system they want along with analyzing how the dimension of Trust influences the behavior of everyone involved. The VPEC-T framework gives the business execs rich languages to express their desires. Then the IT staff can take this description and figure out the right implementation.

Green and Bate are onto something with the idea providing a simple language to the business to express its needs. But in my view, I think the language can be made simpler.

Can Agile Help?

Agile methods are often seen as a way to improve the alignment between the software created by the IT department and the true requirements of the business.

Agile methods address the challenge of alignment by essentially giving up on the requirements process. In agile, requirements are set forth in a minimal fashion using simple mechanisms like stories. Requirements are essentially assumed to be wrong until validated through implementation and use. You then incrementally build a more thorough solution.

I think that the simplest way to express the value proposition of agile is this: You get a huge payoff for being suspicious of your requirements and doing experiments to validate them through prototypes.

Agile methods can have profoundly positive effects on organizations that are stuck and getting nowhere in building useful software. But there is something missing from agile: design.

Harold Hambrose, CEO of the design firm Electronic Ink and author of Wrench in the System, argues that agile methods have failed if they are measured by appropriate standards. I pointed out that agile methods often get companies out of the emergency room. Companies who are getting nothing useful done can be saved by agile. By using scrum and agile development practices, companies start delivering working software that makes a difference.

Hambrose responded by saying that without design, you rarely accidentally find your way to the right system that has the biggest impact. His argument boils down to this: While software that doesn’t suck may be an improvement over software that never got completed, it is of little value compared with software that was consciously designed to have a significant business impact.

Hambrose said that Electronic Ink’s practice is increasingly focused on fixing enterprise software implementations that never fulfilled their promise. By taking a bunch of steps back, rethinking the problems, applying design, Electronic Ink is able to change processes and software to create the sort of results intended all along. His book is well worth reading.

In my view, the best outcome is to create a design for a system, and then implement it and improve it using incremental methods like agile. In other words, use agile in a way that is informed by design.

How the Question Game Addresses the Business Design Problem Facing CITOs

Both Green and Bate in their theory and Hambrose in his writing address a design problem that I believe is too small. The real problem is one of business design.

The challenge for CITOs is to lead a process of business design in which the direction of the business is informed by the proven competence in an organization and by the potential for new skills, activities, and processes, which, if supported and enabled by technology, could create new products and services or improve existing ones. This is true leadership.

But how do you get there?

First of all, slowly. There is no magic bullet. A CITO must seek to increase his or her awareness and the awareness of everyone else in the company. The IT staff must become more intimate with the business. The business must become more intimate with what is possible.

If you read Walter Isaacson’s biography of Steve Jobs, there was no process to be found beside massive iterations. Jobs wore out all of his friends taking them on tours of the prototype Apple store in the warehouse. Engineers and designers were driven crazy by Jobs incessant badgering when they thought they had finished. Of course, Jobs got away with this because he was king and was devoted to Design. Job’s methods may have created great products, but they also created bad feelings at times.

I think we can imitate Jobs in a polite way by using a simple tool for the business to express its needs: Questions.

The Question Game

I think the key to business and IT alignment and the deeper challenge of business design is for the business to state its needs by setting forth questions. The process of declaring important questions must be continuous. My proposal is to make this process a game that I call the Question Game. Here’s how the game would work:

• The CITO performs a survey of every line of business and the C-suite and asks them to set forth the questions that they most need to be answered in order to improve their performance.
• The CITO would collect the questions and organize them according to their relevance to lines of business and key processes. It is likely that some questions will be applicable to many processes.
• The business would then be asked to review the question and assign two rankings. One would be the dollar value of the answer to the question. The second would be a ranking of the importance of the question relative to the other questions. The idea of the importance ranking is to surface questions that are important but don’t have a direct economic value.
• At first, the question game would focus at a high level and would be played by the C-suite and heads of lines of business. But in subsequent iterations, it could be played at all levels of an organization.

Now imagine what the CITO would have when the first round of the game was over. The CITO would have a strong indication of exactly how to help the business.

The CITO could then quickly see if there were a way to answer the questions that were high value and high importance. If the budget were needed, it would be easy to find it, given that the business value of answering the question has been established.

In other words, the Question Game frames the scope of the business design problem. The CITO won’t of course know everything needed to execute a design after a round of the game is done. The CITO will have to react in the following ways:

• Look at the business processes related to the questions. Are they optimized? Can the be better supported? Should they be redesigned?
• Look at supporting systems that are related to the questions. Can they be reconfigured or adapted to answer questions?
• Look at the what new technology makes possible. Can investments in infrastructure or applications help answer lots of questions?

Remember that the questions can be about information or about automation. “How can I know” questions are about information. “How can I do” questions are about automation.

After the CITO performs the research in response to the questions, there will be a variety of projects. Some will simple, like creating and providing a report. Others will be difficult. For these, a business design team should be formed so that some sort of design of the solution can be created. Then, of course, you must implement the design.

The question game can be played at any level of the enterprise. It can also be played with respect to the value of existing systems. For example, wouldn’t it be interesting to know which questions are answered and activities performed by each of your applications? By looking at the dollar value and importance of the questions answered, you could see if applications were covering their costs.

Of course, there are lots of ways to distort the question game. But playing the game raises some vital questions such as:

• How do we assess value of our investment in technology?
• Where should we focus our efforts on process improvement and use of additional technology?
• Where should we prune our portfolio and get rid of applications that are no longer providing valuable answers?

The question game should never stop. Once a company is familiar with it, everyone should be encouraged to submit new questions as they think of them. This process of raising questions, researching them, and responding in concert with the business will solve the problem of getting business and IT aligned.

Author: Dan Woods

My mission: Find technology for Early Adopters. Follow me on Twitter @danwoodsearly and on LinkedIn www.linkedin.com/in/danwoodsearly/. I am a CTO, writer, and consultant. For tech vendors, I help explain their technology. For users, I help find, select, and deploy new solutions that have explosive business value. I love to speak and share ideas.