Life with BizOps

What changes once a BizOps person is involved?  For example, when a new product feature request comes in, what does BizOps do with that request?

• Understand the request — It’s important to first listen.  Document what is the primary stakeholder is trying to achieve.  There is time later to challenge, validate and adjust, so first, just listen and if you must, ask broad general questions to elicit more from the requestor. Is timing critical?
• Re-frame the request — I think it’s important to re-frame any request, as it gives you an opportunity to find the salient need.  Paraphrase the request back in a way that boils it down to the salient item.
• Challenge the request —  Eventually, every request must be challenged.  There are never enough resources, so challenging the need is critical.  Look for hidden agenda’s, as that is sure to derail the effort down the road.
  • How many customers will be gained or retained?
  • How will it impact revenue, or expense?
  • How does this tie back to the strategic imperatives of the company?
  • What happens if this is never done?
  • What can I trim from this request in order to make it happen faster?
  • Why is this being requested, now?
  • Which of your other requests are you willing to forgo in order to make this happen?
  • Are you really the originator of this request, or is it actually coming from somebody else?
• Document the request — Create a BRD (Business Requirements Document) that is right-sized for the request.  If the request can be adequately detailed in 10 words, don’t write 11.  But if it needs 10 pages, don’t make it 9.  Language and details are how we gain a common understanding, so after it has been discussed, write it up so everybody can have a shared understanding.  It will dramatically increase the chance that everybody is happy down the road. Document anticipated benefits in hard numbers, for comparison to actual results
• Research — See how similar companies have solve this problem, or better yet, has it already been solved internally.
• Look to data — Is there existing data to help shape this feature?  Should this new feature generate new data?
• Consider integrations — Systems can no longer be isolated, they must coexist with many other systems.  Make sure you consider how this solution will integrate with existing systems.  Don’t duplicate data, share it.
• Look for quick wins — Decide if this requirement can be met quickly with slight modifications to existing systems, perhaps unknown to the original requestor.  Adding another use case to an existing system is a home-run.  Can BizOps build the solution with the dev team, and save them for more critical functions?
• Connect the dots — Look for opportunities to reduce, modify or even expand the requirements, if the proposed solution can benefit the business in other ways.
• Prioritize the request — Determine how this fits in against other corporate priorities and cross-functional resources.  Use a common five point scale so everybody understands its importance.
• Circulate for comment — Publish/post/circulate the BRD and specifically ask for input from impacted departments.  Impacted departments can be broken down into two groups — those that MUST comment, and those that may optionally comment.  Note this is to simply provide comment (things to consider) from a department perspective, not create a PRD (Product Requirements Document.)  Look carefully for resistance either direct or hidden.  Dig deeper.
• Identify options — Internal builds? External solutions? Pro’s and cons of each option?
• Estimate costs — What will this cost when launched? How about at scale?  Using internal resources?  External?  Long-term commitments? Transactional costs?  Add-ons?
• Choose Option A — Pick the most likely winning solution, and go deeper.  Document options, as you may be back-tracking and trying again.
• PRD — The Product Requirements Document is where you specify all the details of the solution.  It goes beyond the business need, and specifies the actual solution. This needs cross-functional input!
• Prototype the solution — Look for ways to quickly prototype a solution.  Sometimes, the prototype lives on as the solution, but at a minimum, it gives a tangible widget from which to build, beyond the BRD.
• Circulate the prototype — Don’t give a lot of instruction — see how when users do with their own Out of Box Experience (OBE.)
• Implement the solution — Dev processes are a thing on their own, so I won’t cover that here, but would just add that the dev process should not be a throw it over the wall approach — keep cross functional participation maximized. A Functional Document should be included with all the specifics if internal built.
• QA / Polish the As-Builts — Things change along the way, make sure you properly document things as they were built — the solution must be easily understood by the next person that comes along.  Make sure your cross functional constituents are receiving the final product they thought they were buying in to.
• Training — Help people get started in the actual usage.
• Calendar long-term follow-up — Maintain a calendar with trigger points to review the implementation.  This gives you a chance to refine the solution, re-negotiate the costs, re-tool the solution, and even tear it down if no longer needed.