A platform story reference guide

Image by FelixMittermeier from Pixabay

Scaling a biotech organization requires you to communicate a vision, a design and a plan to an organization full of people with diverse backgrounds and mindsets.

In the past two posts I explored how stories can help you do this by communicating different pieces of a larger “universe” packaged in a compelling form.

As I’ve had different opportunities to tell stories like this, I find that one of the hardest parts is to decide which part of the universe to package into a given story.

And even when I figure it out, there are always questions about the parts of the universe that I left out.

So I started keep a list of these components – first a mental list, then an actual list – both as a way to collect my thoughts and to make sure I don’t leave them out next time.

In this post, I want to share this list so others can use it too.

How to use this reference guide

This list is meant to be used before you make your first slide – possibly even before you know what your presentation/communication is about.

First, ask yourself “why”: What are you trying to accomplish with this story?

Second, look at the list and decide what parts of the picture your audience needs to understand in order for you to accomplish this goal.

In particular, you should pick components that can be formed into a compelling story structure.

And keep in mind that the same component could appear in different parts of different stories:

Building a data lake (a subproject in your universe) could be the action of a story about how you need to better organize your data.

Or it could be the tension of a story about how you’re going to build it.

Or it could be the context in a story about how you need to expand your data engineering team.

As the last step, look at the concepts adjacent to your core story and decide what other things your audience is likely to ask about.

For these secondary components, you can either add them in to cut off the question before they ask it, or put them in an appendix that you can skip to when they do.

There are probably still things missing from this list – If you notice any, please let me know in the comments.

Overview

Because this list is long, I’ve split it into three sections, though they’re closely interconnected:

Vision: Why are we building this, and what will the organization look like when it’s done?

Plan: How do we get there from where we are now?

Process: What do we need to do to carry out the plan?

This does not include stories about Execution – how things are going as you actually carry out the development process.

That could be a future post if there’s interest.

But there’s already plenty to cover in just those three sections.

Each section starts with a diagram that shows (very roughly) how each component follows from others, then a short description of each component.

While I describe the components in more or less logical order, you may want to present them in a completely different order – whatever fits the structure of your story.

In fact, you may want to think in terms of completely different components depending on your own style and the particulars of each situation.

This is just meant to help start your thinking.

Vision

The goal of this section is to define where you’re going and lay out the strategy to get there.

Here, I define strategy as the deliberately chosen criteria for making decisions.

How will you choose goals and objectives? How will you prioritize issues? What kinds of solutions will you consider? How will you decide to build vs. buy?

Each person has their own implicit decision-making criteria.

This section should give everyone explicit shared criteria.

If you can get this right, you won’t need to make all the decisions up front, because everyone will agree on how to make the decisions at the last responsible moment.

External Context: What’s happening outside your larger organization that will shape your decisions?

Organizational objectives (or internal context): What’s happening inside the organization, and what high-level objectives are you trying to contribute to?

Context developments: What has recently changed in terms of the external and internal context?

Opportunities: What is missing today that could prevent the organization from meeting its objectives? (To get your audience’s attention, and create a sense of urgency, call these “gaps”, but be careful what you wish for.)

Why now?: How have the context developments created new circumstances that we need to address today?

Current expertise: There are many different ways to approach any opportunity. (A software company approaches health care problems very differently than a hospital does.) What kinds of solutions is your organization good at?

Target expertise: Are there types of solutions that your organization wants/needs to get better at? (This may overlap with organizational objectives.)

Target Future State: This is a description of what things should look like if your organization has effectively responded to the opportunities, given everything above. This is sometimes called the vision, but the term “vision” can also have a broader meaning. So I’m using very specific wording.

Value: Why is the target future state desirable? This will often be obvious to the audience, but sometimes you need to be explicit – particularly for an audience with a very different background.

Alternative future states: Other options you considered for the target future state.

Why not: It should be clear why the chosen target state is better, but again it doesn’t hurt to call it out explicitly.

Stakeholders: Who will be involved in this future state and the process of getting there? Make sure everyone agrees on who needs to be kept in the loop, and in what capacity.

Objectives: This component breaks down the target future state into a list of high-level outcomes that need to be achieved.

Gaps & Challenges: What is missing today that will make it difficult, or need to be addressed to meet the objectives?

Strategic Framing: Often there are non-obvious ways to think about the objectives, gaps and challenges that make a daunting and seemingly insurmountable situation seem promising. This is a good candidate for the epiphany of your story.

Strategy: This is it. This is why you’ve put everything above together. If you did your job right, everyone should be nodding their heads when you lay out the decision making criteria that is obvious from the strategic framing.

Alternate strategies: As with the target state, it’s worth calling out the other strategies that you considered and decided against.

Why not: As well as why you decided against them.

Project Objectives: Based on this strategy, you can often group the objectives into smaller projects that can be approached in parallel by different groups.

Metrics: How are you going to evaluate progress on each objective, and each project?

Time expectations: Given the context above, how soon do these objectives need to be completed?

Risks: In all the steps above, you’ve made decisions, and many of them were based on assumptions and partial information. What are the risks that will come up if those assumptions are wrong, or there are unforeseen circumstances?

Mitigation: These are steps that may or may not be called out in the strategy and objectives, that are explicitly designed to let you recover in the case where one or more risks are realized.

Plan

Once you’ve all agreed on a strategy – the criteria for making decisions – it’s time to begin making those decisions.

This section tells the stories of how those decisions lead to a plan.

Items in this section follow from the Strategy, Project Objectives and Time Expectations from the Vision section.

Goals: Goals are not that different from objectives, but I think of them as much more specific. While objectives should be written in terms of the external context, goals should be SMART.

Existing Assets: What does the organization already have that gets you part of the way to a goal?

Deliverables: These are the things that are left between the existing assets and the goals.

Decision questions: These are the decisions you will need to make.

Information questions: Thanks to the clearly delineated strategy, the only thing missing from being able to make these decisions is information. What questions would get everyone to agree on the right decisions?

Decisions: Once you’ve put the answers to the information questions together with the strategy, these are the decisions that you’ve made.

Team: The individuals who will be responsible and accountable for delivering the solution. What they know. What they’re good at. What they’re not so good at.

Design: This is where you put together the decisions with the opportunities and constraints defined by the team to explicitly describe the design for meeting the goals.

Challenges: What are the hard parts? Where is the team going to be spending the most time, and what should everyone keep their eye on?

Risks & Mitigation: You’ve made more decisions, based on more assumptions and unknowns. Your audience will be thinking about them. Make sure they know you’re thinking about them too.

Subprojects: Now that you have a clearer idea of the plan, you might want to break things down even more. For big projects, you may need to do this a few times.

Value: Sometimes it can be unclear how each subproject contributes to the overall goal. This is particularly a problem when different audience members are used to thinking about different parts of the overall problem. This is where you make that explicit.

Owners: Who is accountable for each piece of the plan? Each subproject? If everyone is accountable, no one is.

Estimates: How long should each subproject/goal/deliverable take? You may want to include estimates based on different levels of resources, such as if you had additional team members.

Additional Headcount: Given the difference between the time estimates and the time expectations, you may be requesting additions to the team, or may have already decided to move people.

Additional resources: This is the same, but for things other than headcount: consulting services, new software, bigger monitors, …

Timeline/road map: This is where you bring together the goals, subprojects and estimates into a single place where you summarize how you’re going to get where you’re going.

Process

Now that you’ve communicated on the design and the timeline, there are still a lot of details before the rubber hits the road.

In this last section, you dive into exactly how you’re going to carry out the plan.

This section builds off the timeline/roadmap, subprojects, owners and teams in the Plan section.

Functional teams: What teams that represent a particular expertise or function will play a role, and what will this role look like?

Cross-functional teams and sub-teams: How will the project teams coordinate across functions, either as a whole or as sub-teams?

Checkpoints: These are the points at which the projects will report on and re-evaluate their progress. These may be dictated as much by external timelines as by the project. For example, board meetings or company town-halls may be good checkpoints.

Deadlines: When do particular goals or deliverables need to be completed, due to external factors? This is a good place to discuss, and agree on, how much the projects should be tied to specific deadlines vs. given the flexibility to adjust to unknowns.

Commitments: When are particular deliverables and goals expected to be completed? These may correspond with checkpoints, or not. Scope of intermediate deliverables may also be adjusted to coincide with checkpoints.

Communication patterns: This is where you describe how you will communicate progress, updates and changes both at and in between checkpoints. Often stakeholders have much higher expectations for this than the people doing the work. So this is where you explicitly set those expectations.

Governance: Even more decisions will need to be made throughout the process. This is the place where you describe how those decisions will be made, and who will play the different roles in the process.

Incentives: In an organization, everyone should be working towards a common goal. But in practice, there are often other factors that impact the work people do, such as what they want to learn, what they enjoy doing, what they want to be known for, and what they expect to be promoted for. It can be tricky to discuss this explicitly, but it’s worth at least thinking about whether some aspects of this should be called out.

Culture: There are many definitions of “culture”. My favorite is that culture is how individuals make decisions when management isn’t watching. But for any definition, culture may have an impact on the process, and the flexibility you have to control the process. This is the place to call out any of these impacts.

Mindset: A number of factors, including culture and incentives, determine how individuals in the organization feel at any given moment. This is where you can explain how the different aspects of the plan may impact the aggregate mindset, and how the mindset may impact the plan.

Processes: What are the one-time or repeated processes that will be pieced together to carry out the plan?

Technology: What software/hardware/etc. will be needed to support these processes?

Skills/Education: What will members of the teams need to know in order to complete the plan, whether or not they already know it?

Releases: How will the components of the plan be packaged into incremental changes, and what will be included in each one? These should line up more or less with the deadlines, commitments and the timeline, and may go into more technical detail about each step.

Conclusion

There are probably a few things I missed on this list, but hopefully there were also some things that you hadn’t thought about before.

In particular, if there were things that you’ve taken for granted that all your stakeholders agree on, it may be worth checking – you never know what you might’ve forgotten to communicate.