Early on in my career as TPM I have realized that a program has almost no chance of success unless there is an early and strong alignment with the business leadership team. The executive leadership team makes key decisions about prioritization and subsequent funding of the any program that is being initiated. The resources are limited, there is only so much a business can take on and so is the leadership teams’ attention span. There are million things that cross their desks on a daily basis, they don’t have time to dive into technical nuances of every single project proposal. If they don’t see something that can move the needle in a major way, they move on to the next thing.
The first time I was asked to write a proposal for a project I wrote a short description of what is does. We are building a system that will add automation to some part of workflow by ingesting data from 4 different sources, doing some processing and producing data that can be used to make more accurate capacity planning decisions. I asked a few of the engineering tech leads to take a look. After making a few minor tweaks, they thought it was clear enough in explaining what the project intents to produce. I was happy as a clam and asked my manager at the time to also take a look. My manager also thought it was clear and should help our team in making capacity planning decisions. We decided to add it as an item into our OKR planning document to be reviewed by the executive leadership. I thought we got ourselves a layup and the project will be approved for us to begin putting together a team and start the design process.
To my surprise I found that the project fell below the red line for approval. I was frustrated and complained to myself while driving home that day. These folks just didn’t get what we are trying to do, they just chose to look on the surface without understanding the actual value this project would deliver, I mean what kind of leadership team is this?
Then I realized, the problem is not with the leadership team, the problem is with me. I should not expect someone to see the hidden business value behind a bunch of technical detail. The business value should be front and center. The technical detail is the how of what we are doing, is not the what or the why. Automating something is not a business value. Saving engineering hours by removing toil, reducing the end-to-end timeline of capacity delivery and ultimately improving availability, performance, resilience and our customer experience are the business values.
I went back to work and started writing the proposal from scratch.
Part 1. Vision.
- What are we building in a short sentence.
- Make network capacity requirement estimation timely and easily consumable with zero manual toil.
Part 2. Business Objectives.
- Why are we doing this work. Here we need to have a very good understanding of who are customers are, what are the jobs they are doing and what are the pain points in the way these jobs are being performed today. What are the shortfalls in the existing processes and tools.
- Reduce the manual toil – Save X number of engineering hours
- Improve the time to deliver capacity estimates by X %
- Improve the precision of estimates
- by streamlining the correlation of several sources of data (sources of truth – SOT)
- Improve transparency
- by displaying the results on the dashboard accessible by the relevant teams.
- Reduce availability incidents occurrence by X%
- via automatic notifications and filing work items, when available network capacity goes below a predefined threshold.
Part 3. Mission Statement.
Build a system that periodically ingests several sources of truth to provide capacity estimates, notification and work intake for the engineering and operations teams.
Part 4. System Architecture.
At this point a very high level overview of what the system will look like. This architecture high level overview should make the following four questions super clear:
Who will use the system – customers. (NetOps Teams, Capacity delivery, etc)
What the system will do. It’s core components. (Backbone connections enumeration, Peering connections enumeration, Typical Usage, Peak Usage, Available Capacity (based on peak usage), Available capacity change over time)
How the system per work. Data ingestion pipeline, data processing, data persistence, data presentation, etc
Where the system will run, where the data will be stored, presented, etc.
Another valuable piece of the puzzle at this point is a rough estimate of the level of effort. It’s clear we don’t have any details and it will be the delivery team that will ultimately know what it takes to build, test and deploy our system, but we can provide some ballpark estimate. Has a similar system been build in the past, do we have an idea of the complexity of the major system components. No need to be precise at this point. Do we think it will take a team of 5 developers a month or we need 5 scrum teams and a full year. This helps the leadership team understand something about the level of investment we are asking for.
When every part of our architecture is aligned with achieving our vision, business objectives and mission the alignment becomes extremely easy.
All we need in order to achieve alignment with our leadership team is their agreement on our vision and business objectives. Is this important for the business now? If the answer is yes, here is how we are planning to deliver on those values.
As long as everything we do in our architecture can be directly traced to the business value delivery we are golden.
Remember: Vision (what) —-> Business Objectives (why) —-> Mission Statement (How) —-> Architecture (Blueprint)