top of page

Architecting Your Business (Part 6)


The Prioritization Model is designed to provide a holistic understanding around change and (designed properly) provides clear and unbiased guidance for informing decisions for investing in change (guiding and optimizing portfolio-based investments = ALL investments). Given the complexity and scale of measures involved in building a holistic Prioritization Model, tools are a necessary aid. This is not something a BI (Business Intelligence) solution can easily pull off, given the complexity of relationships and data that needs to be culled from the Capability Heat Map.


In the next post, I will dive into the

Capability Heat Map (Biz Driven)

  • Prioritization Model used to identify gaps (Top Down)

  • Aligned with Strategy (inferred for now)

  • Aligned with Scorecard (Efficiency, Value Delivery, Quality, Agility)

Instead of referring to projects or "items" in an Agile Backlog, or enhancements, or resolutions for issues and/or defects, we'll use the term "initiative" since it provides abstraction from the size of any planned effort and offers a more flexible way to organize, refactor, and rationalize activities into one or more portfolios. Further, the Initiative Map allows us to assign a more in-depth set of attributes (we'll call Metadata) and it allows us to create a more "interesting" (a richer set) of relationships between initiatives and other business objects (referenced above and below). Each node in the map refers to a specific initiative ID (within a portfolio repository = tool). Initiative Map (Stakeholder Driven)

  • Metadata used to attribute a portfolio

  • Process for breaking initiatives into smaller units of work (items)

  • Structural attributes to align items into Products, Value Streams, etc.

Requirements are typically captured in spreadsheets and/or repositories and linked back to one or more sets of documents and business artifacts. We'll introduce a new model for capturing and managing requirements in a Graph DB, since it provides superior handling of relationships between requirement objects. Requirements objects can include (but are not limited to): Customer Needs, Business needs, compliance needs, features [multiple levels], user stories, process flows, events, decisions, data inputs, data outputs, reports, and one or more sets of measures). Aligning all of this using a conventional traceability matrix is too difficult to change and does not scale. Further, impact assessment is far easier and more efficient when storing requirements in a Graph DB. Requirements Map

  • Metadata used to align Capabilities, Capability Heat Map

  • Feature Decomposition (Functional & Non-Functional)

  • Customer Journeys, Jobs (To Be Done) J2BD, Outcomes

Product Map

  • Products & Services Breakdown

  • Align with Feature Matrix (Functional & Non-Functional)

Organization Map

  • Functional / BU Breakdown

  • Mapping of Org Areas to Capability Map

Stakeholder Map

  • Product owners

  • Domain owners

  • Customers

  • Consumers

 
 

コメント


lVEG Logo.png

© 2020 by The Value Enablement Group, LLC. 

West Deerfield Township Deerfield Illinois United States

agility, innovation, value, sustainable growth, digital transformation, sustainability, digital customer journey, architecture, BizDNA, strategy, roadmap, modeling, adaptability, knowledge, policy

  • White LinkedIn Icon
  • White Twitter Icon
bottom of page