Solution Delivery Diagram: A Top-down Product Management Approach (Not just

another deliverable)

BA Team: Product Ownership, Analysis, and Solution Design

BA Bi-Weekly Mini-meeting

Feb 3, 2011

01-2011

SDD – More than just a Deliverable

December and January were the months of tackling the SDD – Solution Description Document/Diagram. Now it’s time to take a couple steps back, and look at what EIM’s PMO is expecting from the BA team on a project that led to the SDD requirement.

The key is to provide Top-Down DirectionIt’s not about the SDD, it’s about driving the entire software development process from an agreed-upon vision of the solution rather than driving the solution from 1000 functional requirements…The SDD simply represents a top-down “compass” that helps drive all other decisions, from architecture to SME sessions. We don’t need to collect 1000 requirements if 700 will build the right solution… A Top-down approach is the best way to prevent over-gathering of requirements or misdirected gathering of requirements.

Top-Down map the forest boundaries before filling in trees Bottom-Up define every tree & wait for a forest to emerge

Every possible detail is recorded, someone or some team then has to synthesize all the details in hopes that a solution emerges... Inherent in this approach is that no 2 people will “synthesize” the details the same way, and too many details make a quick assessment of “do we have the right things defined” impossible.

The big-picture solution is clarified up front, so that everyone from the customer to the implementation team has a very clear idea of the end-goal. Once the high-level solution is agreed upon, the team will “decompose” the vision to determine the details that are required to achieve the vision.

Software hasn’t traditionally followed other design industry Approaches

Conceptualize/Sketch

Model and Prototype Produce Car

Automotive Industry

• Sketch a high-level design, see if it flies with potential consumers…

• Create a model or mock up of the car, work out kinks.

• Determine more detailed specs…

• Build actual car using detailed specs

Software hasn’t traditionally followed other design industry Approaches

Storyboard for plot Finalize Character Sketches Produce Movie

Film Industry

• Storyboard a plot, work out kinks to determine a flow that works… Character traits are in development.

• Add details to characters to match plot…

• Produce Movie

Software hasn’t traditionally followed other design industry Approaches

Sketch/Determine Basics Finalize Designs and Details Produce House

House Building Industry

• Select type of house (basic style that is appealing)

• Select main elements (# rooms, bathrooms, garage)

• Detail the floor plan• Finally work with

contractor who determines all the “how”s

• Build house using detailed specs.

Software hasn’t traditionally followed other design industry Approaches

Record every detail Build to Functional Req’s Emerged Solution Fixes

Bottom-up Development

• Generate giant docs full of all the details.

• Developers must synthesize 1000+ pages of requirements.

• Developers “interpret” and translate into GUIs.

• Endless cycles of change requests once the customer actually sees how their functional requirements emerged into a “solution”.

Software hasn’t traditionally followed other design industry Approaches

Storyboard Solution Define Requirement Details Build the Right Solution

Top-down Development

• Solution Descript. Diagram.• GUI Mocks.

• Focused SME sessions - collect the right requirements only.

• Collect by priority…

• Element of “surprise” is limited.

• Updates occur during building process.

The Product Owner provides Top-down direction

As a PRODUCT OWNER: This means that the first thing we do is seek to understand and create the high-level solution. That really means a combination of a high-level, user-friendly flow (the SDD) and a set of GUI mocks.

• Order Matters – the SDD (and GUI Mocks) should drive iterative requirements gathering sessions.

• Extensive SME sessions need to target specific areas in the SDD/GUI Mocks.• The SDD and Mocks, not the SRS, should drive the huge majority of requirements

gathering sessions. If you can’t draw, you have to at least be able to direct someone who can.

• Requirements Documents should never be finalized before the SDD and GUI Mocks.• Requirements that are collected that fall outside the scope of the SDD/GUI Mocks will

be easier to identify as out of scope, and should be recorded in a separate area of a requirements document.

The Product Owner role moves a BA away from being requirements gatherer to being a product visionary, who first and foremost understand what needs to be built (first things first), and can then use that knowledge to provide the type of leadership that EIM is looking for from the BA team! Moving forward, every project must have someone who is comfortable driving the product from a visionary perspective, in addition to having support for gathering the traditional requirements to support that vision.