BAPO
Decomposing a high-level strategy is hard. Immediately we want to know “When is it going to be done?” and “How much is going to cost? (In effort, time, and/or actual $$$)” It’s a fair question to ask because in tight times we want to make sure we aren’t wasting effort (and $$$). We spend days and weeks debating who to move to which team and calculating budgets requests to increase staffing. We document the product requirements and create designs. We build against the requirements and designs. In our perfect world this waterfall of idea to execution flows flawlessly.
In reality issues arise which cause teams to pivot, change timelines, and change priorities. The technical solution is more complicated than we assumed, stakeholders expected different deliverables than what the team built, stakeholders push to change scope, etc.. all cause issues. As the project drags on stakeholders begin to lose faith, engineering struggles with the technology, and product teams have to massage an imperfect solution into the expected use case. Then someone asks the dreaded question, “Why did we do this in the first place?”
So how did we end up in this situation where we had a great idea but failed to meet our expectations? How did we lose faith in the idea, in the technology, or in the team? How could we have avoided being so mis-aligned?
We started with the wrong question. We jumped right into answering staffing and cost questions without aligning on the business impact of the strategy. We assigned people without understanding what we are building and thus who should be included. We didn’t establish a process for delivering iterative value back to the stakeholders.
A person smarter than me introduced me to the BAPO framework. BAPO is a framework which describes the order in which you should make decisions when tackling a strategic direction. It postulates that organization is the LAST decision that a company should make. Decisions need to start with understanding and aligning on the business impact, define the architecture to be built and the process to execute, then finally how to organize. Only once the business impact, architecture, and process are understood can you determine the right organization to build to support it.
The basics of BAPO:
- B usiness Impact - Is the impact of the strategy well understood and agreed upon? Are leaders aligned on the direction at the highest level and believe the direction is the most impactful.
- A rchitecture - Is the technical architecture of the solution defined?
- P rocess - Do we know how we are going to deliver? Are milestones defined and agreed upon from both the stakeholders and the delivery team?
- O rganization - What is the right team structure and composition to put in place? Is more than one team needed?
When teams run into issues I often assess their issues against the pillars of BAPO. For instance, if engineers aren’t clear on what to build next I look for architecture/tech designs to exist. If the milestones aren’t agreed upon between stakeholders and the delivery I will push to align and clarify the business impact. Having BAPO as a frame of reference helps me articulate what is necessary for a strategy to be successful.
The BAPO framework forces me to ask “Why?” so that I can gain clarity to make informed decisions. I find it a useful tool which helps re-orient conversations. It helps teams avoid “cart-before-the-horse” scenarios and drives more logical decision making.