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


Recent Posts

See All


bottom of page