Review crossteam-project-valuation

README.md

@@ -48,13 +48,13 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Standard Base Documentation](patterns/2-structured/project-setup/base-documentation.md) - *New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.*
 * [Issue Tracker Use Cases](patterns/2-structured/project-setup/issue-tracker.md) - *The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.*
 * [Communication Tooling](patterns/2-structured/project-setup/communication-tooling.md) - *An InnerSource project is being used outside the original development team but users are having trouble getting help and getting in touch with the project team. The idea is to setup and document standard communication tooling that allows for discussions to become visible, archived and searchable.*
+* [Cross-Team Project Valuation](patterns/2-structured/crossteam-project-valuation.md) - *It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
 * [Transparent Cross-Team Decision Making using RFCs](patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - *InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.*
 * [Start as an Experiment](patterns/2-structured/start-as-experiment.md) - *Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.*
 
 #### Pattern Drafts (proven, not yet fully reviewed)
 
 * [Assisted Compliance](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
-* [Cross-Team Project Valuation](patterns/2-structured/crossteam-project-valuation.md) - *It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
 * [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
 * [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
 * [Include Product Owners](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/71) - *Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.*

patterns/2-structured/crossteam-project-valuation.md

@@ -4,7 +4,7 @@ Cross-Team Project Valuation
 
 ## Patlet
 
-It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue.
+It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue.
 Here's a data-driven way to represent your project that both articulates its value and amplifies it.
 
 ## Context
@@ -33,25 +33,25 @@ Ascribing value to a cross-team effort is an exercise in quantifying _how much m
 The exact delta in productivity will vary by domain and project.
 There is a common process, though, by which you can create a model to calculate it.
 
-## Explanation
+### Explanation
 
 Assemble a small team of subject matter experts in your domain.
 Using that team of experts, estimate 4 things about each consumer of your project output:
 
-  * How long does it take them to consume your project output?
-  * How long would it otherwise take them to home-roll the value of your project output for themselves?
-  * What percentage of your project output is actually useful for them?
-  * How much time on an ongoing basis (ideally per-use) would they otherwise spend maintaining their home-rolled solution?
+* How long does it take them to consume your project output?
+* How long would it otherwise take them to home-roll the value of your project output for themselves?
+* What percentage of your project output is actually useful for them?
+* How much time on an ongoing basis (ideally per-use) would they otherwise spend maintaining their home-rolled solution?
 
 When making these estimations, it's impossible to know with high accuracy _exactly_ how long any activities take.  That's not your goal.
 Rather than exactness, you should strive to _**set a worst-case bound**_ on these estimates.
 The idea is for the group of experts to be able to say to each other, "We don't know exactly how long it would take, but we can all agree it's _at least_ this much."
 Specifically, you should estimate a *maximum* reasonable time to consume your project output and *minimum* reasonable times for consumers to otherwise home-roll, use and maintain their own solutions.
 
-> One note about cost-to home-roll.  The cost to home-roll a solution is NOT necessarily (very unlikely, in fact) the same as the cost of making a shared solution.
-Oftentimes for the same functionality the modularity and quality involved in buliding a cross-team, shared solution makes it a noticeably higher investment than a quick, hardcoded implementation used just once.
+One note about cost of "rolling your own solution" (home-roll).  The cost to home-roll a solution is NOT necessarily (very unlikely, in fact) the same as the cost of making a shared solution.
+Oftentimes for the same functionality the modularity and quality involved in building a cross-team, shared solution makes it a noticeably higher investment than a quick, hardcoded implementation used just once.
 
-## Formula
+### Formula
 
 Once you have your worst-case bounds you can value your cross-team project output during a given time frame via the simple formula:
 
@@ -63,21 +63,22 @@ Once you have your worst-case bounds you can value your cross-team project outpu
 [Count of New Onboardings] * ([Cost to Home-Roll] * [Percent Useful Functionality] - [Cost to Onboard]) + [Count of Usages] * [Maintenance Cost Per Use]
 ```
 
-## Commentary
+### Commentary
 
 Despite the trappings of rigor, this process does not yield an exact way to measure cross-team project output.
 In-practice, though, it does give a framework by which you can make a sound decision at how to fund this work.
 After having good, reasonable data according to the above explanation, you should fund dedicated development hours toward running the project up to _**at least**_ of the lesser of the following three levels:
 
-1.  The raw hours saved by the formula above.  Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.
-1.  The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to faciliate their work going into a shared location.
-1.  Whatever feels good to you.  One intentional side-effect of having a valuation formula is that it  naturally forces measurement of the key points of usage that provide value to consumers.
+1. The raw hours saved by the formula above.  Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.
+1. The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to faciliate their work going into a shared location.
+1. Whatever feels good to you.  One intentional side-effect of having a valuation formula is that it  naturally forces measurement of the key points of usage that provide value to consumers.
+
 Those measurements can be understood and consumed in their raw form to provide you with a gut-feel idea of how valuable is the project.
 
 Some may be concerned about the lack of accuracy in this valuation approach.  It's okay for this process to not give an exact measurement.  It just needs to be accurate enough to accomplish 2 purposes:
 
-1.  Give a means to represent the value of what is happening to those that are organizing and funding cross-team efforts.
-1.  Help those involved to know what areas of cross-team effort are higher priority to pursue based on their value.
+1. Give a means to represent the value of what is happening to those that are organizing and funding cross-team efforts.
+1. Help those involved to know what areas of cross-team effort are higher priority to pursue based on their value.
 
 In-practice, as long as these valuations are within an order-of-magnitude of reality and one-another, they are sufficiently accurate to fill these purposes.
 They will provide a head-and-shoulders improvement in on-the-ground results over the ad-hoc valuations (and resultant effects) described in the **Problem** section at the beginning of this document.