Biz_Value.md

This document was referenced in a talk delivered at Kubecon EU 2021, titled Achieving the Tipping Point for Open-Source Software: Making the business value obvious for management. Although the talk centered on positioning technology recommendations for OSS, this template could also serve you in introducing any proposed solution to stakeholders and decision makers within your company.

Presenting with data ALWAYS carries more weight

How is this project critical to our business success?

Focus on highest level company goals. These may also be called OKRs (Objective Key Results). If you can't draw a clear line to why this technology decision is important to the company, then you are creating extra work for your leadership to connect the dots.

If this project is approved, what outcome should the company expect upon its delivery?

This is the how you make it happen, tying what you're proposing to an actual deliverable (lower costs, less customer churn, ability to onboard larger customers or expand to a new region/market)

Known risks, and how you expect to mitigate:

Why would this project fail? Have you already done the critical thinking so that I can trust your judgement? Think broader than technology failures. What other risks could be introduced? Costs, ability to attract talent that can support this technology?

Design principles used to guide this evaluation and recommendation were:

This is really important because clarity here ensures alignment. If the premise you worked off of was missing context, this is where these details get surfaced. It also creates shared expectations and identifies potential process gaps/change management that may need to occur alongside the technological implementation. Incorporate stakeholder requiremends, user interviews into a distilled version of this. Quotes help.

Other options considered, and why they were not chosen:

This shows you did your diligence.

Summary of recommendation:

This is where you describe the proposed solution. It allows you to dive a little deeper into the implementation, indicating that you are prepared if granted approvals.

Estimated time: (this is dependent on resources and budget and can be an area where you "negotiate" with multiple options; ie if we push X off and I can have these resources, I estimate delivery by this date)

Estimated cost: incorporate the hard costs, assumed soft costs; compare to the due nothing/status quo

Resources required: think good, better, best; don't set yourself up for failure by underestimating or underreporting requirements