Telling the Value Story with Numbers

(Editor’s Note: This is part four in a series of four articles. Lockhart is a Director at Point Management Group. The previous article was about Measuring Value in Architecture.)

In business, everyone needs to communicate in order to share ideas, collaborate or convince. When discussing technical or platform/product specific subjects, there is an inclination to believe that pure data (often presented in a spreadsheet) will make its own self-evident case. In reality, context is often more important when discussing technology because while the data is the objective data, the audience may not have a technical background, understand what the data means or even know the words you’re using.

Architects have a unique role to play in organizing data and technical detail and aligning it with financial, people and business elements that can be communicated in a cohesive, compelling fashion to various stakeholders. Part of that depends on the specific Architect’s blend of soft skills, to be sure. However, much of the rest of this process follows a pattern that can be rehearsed and reused.

Components

At the highest level, any story must address several items that the audience is asking themselves:

• Why am I listening to this?
• What’s in it for me / my business unit / the company?
• Why should I care?
• What do you need from me?

These are the questions that the story must answer. To do so requires more than just pure data. The story must engage the reader or listener. Every story has a few common elements that help achieve this. For example, characters, a setting, obstacles, tension, change. In the business technology context, the objective is not to write a novel but to effectively articulate the rationale for or against change.

Below are some examples of what this looks like in the context Architects care about.

 

Story Component	Examples	Key Questions to Consider
Setting	Background/Context Strategic/Business Unit Objective Market Condition	What business problem is being solved? Why is this a problem? What aspect of the problem is being solved for? What will you, the audience, get from this?
Characters	Product/Service Program/Initiative/Project Solution Use Case Story Point	What is it? Who uses it? What can the user do with it? Why does the user use it?
Change	Hypotheses/Projections Desired Outcomes Solution Options Counterfactuals	What does the change look like? What is expected to happen? What does success look like? Are there alternatives?
Obstacles	Time Constraints Resource Constraints Financial Constraints Technical Constraints	What is needed in order to deliver? Are these things available? If not, how does this impact the outcome? What can be done to mitigate this impact?
Tension	Market Competition Technical Challenges Internal Politics Vendor/Partner Challenges	Is anyone else trying to do this? What are the technical hurdles? Are the teams working in synch? What else is needed from internal groups? Are there issues with third parties?
Resolution	Actual Outcomes Value Realized New Current State Next Steps	What actually happened vs what was predicted? What Value was realized? How does this help you (the audience)? What do things look like now? What comes next?

 

Each of these components serves a distinct purpose in articulating the message to the audience. Properly delivered with the appropriate level of detail, a story built around these components will answer the audience’s internal questions listed above. It will deliver the message you are attempting to get across and do it in a manner that engages those listening.

Structure

The basic layout of the story in the business technology context has become cliché but remains an effective way to structure the content:

• Tell them what you will be telling them today
• Tell them
• Tell them what it was that you just told them

With that as the general pattern, additional thinking and methodology is necessary to compose the narrative. Architects tend to be good at this.

Here’s what needs to happen in each section for your Value Story to be structurally complete.

1. Tell them what you will be telling them today
   This is the opportunity to establish the setting of the story. Why is everyone gathered here today? What message will you be conveying to them? What will you be asking them to do? What will you not be telling them? This sets expectations up front for the discussion.

   This sometimes takes the format of an Executive Summary in bullets or paragraphs and other times simple text conveying the Context. But either way, this is not merely an Agenda. It must answer the question: What are we going to do (or did already)?

   This section should be short and concise.

2. Tell them
   This is the meat of the story. This is the section where you introduce the characters, what change is occurring, any obstacles or tension, and ultimately what the resolution was. The objective here is to describe what was done, why, and what happened (i.e. what value was delivered).

   Data and analysis are the underpinnings of this part of the story. It is here that you introduce your Value metric and associated data as part of the story. This may take the form of graphs, tables, paragraphs or bullets. Frameworks for data analysis are especially useful at this juncture. These are tools such as a SWOT Analysis, Bubble Chart or a 2×2 Matrix (among others) that clearly illustrate the objective data for all to see. It gives the Architect the opportunity to leverage data to demonstrate Value Delivery (either forecast or actually delivered) in a fashion that is grounded in data and not merely anecdote or wishful thinking.

   However it is communicated, the objective data can exist side-by-side in this section with the Architect’s analysis. It is an important aspect of delivering the message. Yes the audience can view the data themselves and come up with their own interpretation. This may not be a good thing if it confuses the intended message. It is more effective if the Architect provides both the data and some thinking about what the data means: “That’s great, a giant table in Excel with revenue numbers month over month. So what?”

   This is the largest and most complex part of the story. It typically includes Architecture diagrams, models, reports, analyses, and data. It must answer the questions: How are we going to (or did we already) do what we said we’d do? What will it (or did it) cost? How long will it (or did it) take?

   Answering these questions may take some space. Always keep in mind the audience, their business and/or technical knowledge, and whether you’re addressing the Key Questions to Consider for each Story Component.

3. Tell them what it was that you just told them
   After the body of the story is completed, the Architect has the opportunity in closing to reiterate what was said and what, if anything, the asks or next steps are. In this respect there is some part of the resolution to the story contained in this section. The objective here is to summarize what was just said and answer the audience question: what do you need from me?

   This frequently takes the form of a bulleted summary of the story. Again taking the format of what was done, why, and what happened. It serves to reinforce the message. Additionally, anything that is needed from the audience that was introduced in the first section should be reiterated here at the end.

   This section should also be short and concise.

The Value Story crafted by the Architect must convey often complex information in a clear fashion as well as bring meaning to raw data in a way the audience can understand. With this 3-section approach, encompassing the Story Components and answering the Key Questions, a compelling narrative can be composed that articulates the Value Architecture has delivered. In capturing, codifying and conveying the aspects of any solution or effort, Architecture is actively demonstrating the Value it brings to the table.

Conclusion

Architecture is a business discipline. As such, Architects are often found throughout an enterprise. The profession is not limited to drawing network diagrams or defining software architectures. Architects are deeply involved in understand the reasons for change, the structure of that change and the outcomes of that change. Articulating Value is one part of this discipline.

Improving outcomes is the objective of Architecture. It is achieved by capturing, codifying and conveying complex information in a fashion that can be readily understood by an audience.

There is tremendous Value in this activity, both qualitative and quantitative. The fact is, wherever there are Architects there is a higher chance of Value Delivery. Stronger Architecture results in better outcomes.

Articulating this contribution in a Value Story is something Architects should understand and become proficient at. Spreading the message about the Value that Architecture can bring and telling that story in a data-backed fashion will ultimately drive better outcomes across the enterprise.

Apropos the presentation of the value story: Eoin Woods and Nick Rozanski, in their book, provide us a set of templates that attempt to provide the stakeholder the architecture in a form that would be of interest to her/him. Would it make sense to mention that here in some form?   https://www.viewpoints-and-perspectives.info/ [s.1]