Using the Right Medium Gets Executive Buy In

By Brian Cook

(Back to article)

Suppose your family is in the market for a new house. Your plan is to interview three builders and then choose one to build your new home. You meet with Acme Builders first. The salesperson, Ann, asks some questions about what you have in mind and you describe your ideas. Ann tells you that Acme’s Bainbridge model would be perfect for you. You reply, “Sound good. Let’s take a look.”

Ann says, “Here is the description of the Bainbridge model complete with all available upgrades and options” while handing you a two-foot tall stack of printed materials. You leave—Acme, Ann and the printed materials.

Next you meet Kim at Kelly & Sons. After learning about your house ideas, Kim says that the Sanford model meets your needs. Kim hands you a scroll of large-sized paper while saying, “Here are the complete technical schematics of the Upton model. See, page 1 shows the exterior view with optional elevations; page 3 the floor plan; page 8 the plumbing.”

“We don’t know how to read technical schematics and I don’t see why we should learn how!” you say to yourself as you walk out. “That salesperson wasn’t listening to us,” your spouse says in the car. “We don’t want elevators.”

Then you meet with Harry at Homes ‘R Us. Harry asks what you like in a home. He listens and says, “The Upton model sounds like it might work for you. Would you like to go through one?”

“Finally,” you say, “something we can understand!” as you are walking through the Upton model.

Decision Time

Which of these three builders do you think has earned the right to build your new home? Right, Homes ‘R Us.  Looking at the discussions with the three builders, probably without even being aware of it, your family interacted with them via several mediums. All three builders presented the house they believed would meet the needs of your family, albeit in quite different ways.

What does all this have to do with software, you ask? Well, just as you wouldn’t buy a new home based on written descriptions or technical diagrams why would you expect business stakeholders to buy applications that way? Especially since there is a huge difference in complexity between static houses and dynamic applications that change behavior based on user actions, data values, rules and current state.

Simply stated, we are using the wrong medium to communicate. We need to give stakeholders an experience of the proposed application that they can validate, i.e., place them inside the application so they can directly experience how the application will meet their needs—before coding starts. (And maybe along the way even help stakeholders discover something dramatic—an innovation—when it costs the least to implement it.)

Getting Buy In

Each builder presented a specific house model, the goods, as it were. You do in fact want the goods. You planned these three interactions because you do want a new house. However, wanting goods and being presented goods was not sufficient with at least two of the builders. You needed something more to make an informed decision.

Sophisticated providers of goods realize that people do not usually become customers just because they want the goods they have. Customers buy because they want more than just the goods. They want experiences. Frequently, potential customers are not consciously aware of the experiences they want. They cannot articulate the experience that will sway them to buy the goods they want from a provider.

The first two builders only presented the goods. All they did was describe the goods they wanted to provide. Homes ‘R Us provided an experience—a full-sized Upton. You could walk into it, explore rooms, open doors and drawers, and imagine how you would place your furniture in your very own Upton home. Granted, the model had upgrades you didn’t want. You had to ask repeatedly “Is this included?” The colors and the décor weren’t to your taste. But you could get past that, mostly, as we will soon see.

In any case, as far as you were concerned Homes ‘R Us was by far the best presentation. You experienced yourselves in an Upton model. After a brief discussion, you decide to take the next step with Harry.

Just a Small Change

“We do like this house except for one thing," you say. "The family room is too small.”

“Fortunately," Harry replies, "we offer an option to extend the family room by four feet. It really opens up the room! It feels much bigger.”

Any guess on what is soon asked? Right! “Do you have an Upton with the extension we could walk through?” Why? Because most people need to experience something to understand it. You will never know what a chocolate cake tastes like by looking at a picture of it no matter how many pixels it has!

By providing the experience of a model, Homes ‘R Us earned the right to negotiate to build your house. However, the experience they provided did not answer all your questions. Because the builder’s model does not have the four foot extension, Harry is forced into the position of the first two builders on this point.

Most people cannot process a simple four-foot extension of a static room. Yet the IT industry as a whole expects stakeholders to validate applications with very complex behavior and multiple simultaneous changes. Human brains are not wired to handle this level of complexity. Sometimes, we (eventually) train non-technical stakeholders to grasp technical requirements, but that is the exception.

So, how can we give stakeholders the experience of the requirements?

To be fair, requirements tools that enable the kind of experience we are discussing have only recently become mature enough to consider using. We did not have much choice in how to document requirements. Text (e.g., line item requirements), screen mockups and technical models (e.g., UML diagrams) dominate.

Today, there are tools from various vendors that enable the creation of interactive simulations of requirements. These simulations are completed and viewed prior to the start of coding. Simulations are very useful because they have the characteristic that they either work a specific way or do not work at some point and just stop.

Consider a simple example: an application where a user adds a new customer. When information for a new customer is filled in the user submits it. So far so good. Some stakeholders, however, think the application should present the main screen next because they only occasionally add a customer while others think a default customer form should be presented next because they enter many new customers one after another. Navigating to the add customer screen from the main screen every time will irritate users by slowing them down.

Whichever group you are in, you are likely to think that your view is covered in text or screen mockup requirements because dynamic navigations are often not documented carefully or completely. However, a simulation will either pick one of these two or maybe even a third path. No matter which option is simulated, it is sure to start a conversation among these stakeholders!

This discussion is a good thing. It is one of the main goals in using simulation. Instead of discovering that the application does not meet expectations in user acceptance testing, or even worse, in production, and must be corrected at high cost, we discover this disconnect early in the lifecycle where it can be addressed at the lowest cost.

Now there is the possibility that by making ideas visible a new, innovative solution that meets stakeholder’s needs even better can be found, simulated, validated and implemented the first time the application is deployed. One innovation can make all the difference between an okay project and a truly innovative project that elegantly meets a business need.

Ideally, technical staff will be involved in the simulation creation process as part of high-level design. It is an optimal time for technical creativity—e.g., simulate an existing SOA service (instead of building from scratch) or using a new UI widget (instead of what we always use) to get buy in from other stakeholders who can directly experience how it will work.

If stakeholders have a say in the solution early they are more likely to buy into the choices made. This will help improve application acceptance in the field and increase customer satisfaction ratings.

Simulation is extremely valuable in an outsourced environment, as well. A simulation reduces reliance on words that must be translated and increases reliance on movies that can be taken at face value. Because of the medium itself, a simulation reduces ambiguity by providing a direct experience of the application to be built.


A large part of the reason that business stakeholders are reluctant to engage in requirements is that they do not understand the medium used. Prototypes are a step forward. Simulation takes it further.

A simulation is like a movie that unambiguously shows dynamic interactions. You can deliver a simulation to architects and developers and say “Make it work like this.” Words will still be necessary because not everything can be simulated, e.g., nonfunctional requirements. But the words can be organized so that they are in context of the functional requirements where they apply. If a picture is worth a thousand words, a simulation is worth a thousand pictures.

Brian Cook was a Senior Software and Systems Architect for Zurich Insurance for six years and prior to that an Information Architect, Information Modeler and trainer for Perot Systems for four years. Currently, Brian is President of Cook Enterprise Corporation whose primary mission is to help clients discover, document, simulate and validate processes, scope and requirements visually so they are understandable to nontechnical people. A description of the Building Requirements Consensus Methodology can be found at Brian’s website: www.building-requirements-consensus.com.

“If a picture is worth a thousand words, a simulation is worth a thousand pictures.”