teamsd

name

teamsd

description

Drives pre-sale solution design using IBM's Team Solution Design (TeamSD) methodology — produces the standard TeamSD work products (Project Definition, System Context, Non-Functional Requirements, Use Case Model, Architectural Decisions, Architecture Overview, Component Model, Operational Model, Viability Assessment, etc.) and walks the user outside-in through Plan → Pre-Sale Solution Design (EXPLORE, DEVELOP) → Support Implementation & Confirm Value phases. Use when the user asks to design a solution using TeamSD, write a Solution Design doc, build TeamSD work products, walk a case study, apply Buying Behaviour/BTT to choose work products, fill in SystemContextTemplate/TeAM-Template/Architectural Decisions templates, or mentions terms like TeamSD, Team Solution Design, UMF, CVM, SA4TeamSD, TeAMethod, iRAM, Solution Design work product, Viability Assessment, or the MyBank case study.

TeamSD — Team Solution Design

Use this skill to drive an IBM Team Solution Design (TeamSD) engagement. TeamSD is a pre-sale methodology: the goal is to produce a coherent set of work products that describes the client's problem, the proposed solution, and the proof it is viable — just enough detail to assure the client their requirements are understood and the solution will address them.

Core mental model

Three phases aligned with CVM:

 Plan ───► Pre-Sale Solution Design ───► Support Implementation & Confirm Value
(VALIDATED) (QUALIFIED → WON)           (COMPLETED → NEW OPPORTUNITIES)
            │                            │
            ├ EXPLORE Options & Approach ├ IMPLEMENT Client Solution
            └ DEVELOP and Agree Solution └ CONFIRM Client Value & Experience

Nine core work products (memorize these):

1. Project Definition (ENG 343)
2. System Context (APP 011)
3. Non-Functional Requirements (ART 0507)
4. Use Case Model (ART 0508)
5. Architectural Decisions (ART 0513)
6. Architecture Overview (ART 0512)
7. Component Model (ART 0515)
8. Operational Model (ART 0522)
9. Viability Assessment (ART 0530)

Three design principles govern everything:

• Outside-in — start at System Context, work inward to components and nodes.
• Iterative — activities drive the process, not tasks/work products. Revisit as new info arrives. Every decision traces back to a requirement.
• Varied level of elaboration — pre-sale depth is "Basic/Conceptual" or "Prescriptive/Specified", not delivery-grade. Adjust by Buying Behaviour × BTT.

Workflow

For any solution-design request, follow these steps in order:

1. Frame the engagement. Ask the user (concisely) for: client + industry, opportunity nature, Buying Behaviour (Value for Money / Trusted Supplier / Innovation Partner), BTT estimate (1–5), and any existing inputs (Account Plan, Opportunity Plan, prior architecture). Use the guidance matrix in references/work-products.md to pick the work product set and elaboration level. Announce the plan before generating artefacts.

2. Plan phase (if not already VALIDATED). Produce Business Direction (BUS 411), Current Organization Description (ORG 001), Technical Environment (ART 0506), Standards (ARC 310). Start CVM Opportunity Plan or Project Definition. For large/transformational scope, use the Transformation Roadmap sub-activity (Client Challenge + Strategic Roadmap).

3. EXPLORE activity — drive to QUALIFIED. Produce iteratively: Project Definition → System Context → NFRs → Use Case Model (+ Requirements Matrix / Subject Area Model if needed) → Architectural Decisions → Viability Assessment.

4. DEVELOP activity — drive to WON. Produce: Architecture Overview → Candidate Asset List → (Service Model if SOA) → Component Model → Operational Model → Identify Delivery Approach (updates Project Definition) → Estimation Report → Refine Viability Assessment → Evaluate Integrated Solution (TDA/ITR/PBA as warranted) → Propose Solution.

5. Support Implementation & Confirm Value (if asked). Transition to Implementation → Monitor Pilot → Harvest Assets (update WPs; log to iRAM-equivalent) → Evaluate Success (CVA-R/CVA-T) → Explore New Client Issues (feeds back into Plan).

Detailed step-by-step guidance with questioning patterns per work product is in references/workflow.md.

Key rules

• Project Definition + Viability Assessment are mandatory for every engagement and every peer review. Do not skip them.
• Architectural Decisions is the hub — every significant choice lands here with Category/Topic, Principle/Policy, Explanation, Relevant Requirements, Motivation, Implications.
• System Context treats the proposed system as a black box. Every external connection must have protocol, format, frequency, volume.
• Each AD must trace to a requirement. Each NFR should trace to a use case or business goal. If you cannot trace it, ask the user or log it as an assumption in Viability Assessment.
• Do not over-produce. For BTT 1–2 / Value for Money, skip Requirements Matrix, Subject Area Model, Service Model, Estimation Report. For BTT 4–5 / Innovation Partner, produce the full set at Prescriptive/Specified elaboration.
• TDA / ITR / PBA only for BTT 4+ or cross-LOB/geo. Do not invoke formal reviews for small deals.
• NFR checklist has 17 categories. Walk all of them; mark "none" explicitly where no requirement exists.

Reference files

Load as needed:

• references/methodology.md — what TeamSD is, relation to CVM/UMF, 10 principles, philosophy, roles, Buying Behaviour + BTT.
• references/phases-and-activities.md — full phase → activity → task tree, milestones, entry/exit criteria.
• references/work-products.md — every work product with ID, purpose, content model, the Buying Behaviour × BTT guidance matrix, and the dependency diagram.
• references/workflow.md — step-by-step design workflow with questioning patterns per work product and iteration triggers.
• references/mybank-example.md — the canonical MyBank reference case (Trusted Supplier, BTT 3) with worked examples of all nine core work products.

Templates and examples (assets)

Use these when producing deliverables in the user's requested format. Read .doc/.dot/.ppt via the docx / pptx / pdf skills as appropriate — do not try to parse binary Word/PowerPoint directly.

Templates:

• assets/templates/TeAM-Template-2004.doc — master Solution Design template (covers all work products)
• assets/templates/SystemContextTemplate.doc — System Context (APP 011)
• assets/templates/umf_architectural_decisions.dot — Architectural Decisions (ART 0513), Word template
• assets/templates/Template for case study 1_1.ppt and 1_2.ppt — case study 1 deck
• assets/templates/Template for case study 2.ppt — case study 2 deck

Worked examples:

• assets/examples/MyBank_Opportunity_Plan.pdf — CVM-side Opportunity Plan preceding TeamSD work
• assets/examples/MyBank_Opportunity_eMail.pdf — client exec's invitation

Integration with other skills

• Diagrams (System Context, Architecture Overview, Component Model, Operational Model): use drawio or deeparchi skill.
• Word deliverables (Project Definition, System Context, Architectural Decisions): use docx skill.
• Presentation decks (case study, proposal summary): use pptx skill.
• Reading opportunity plans / PDFs: use pdf skill.

Tailoring heuristics

• Small internal project without a client → still use the nine core WPs, but most can be short paragraphs or bulleted lists. Keep Project Definition, System Context, NFRs, AD, Viability Assessment. Skip CVM-specific items (Opportunity Plan, Account Plan).
• User says "just give me an architecture" → do EXPLORE work quickly (abbreviated PD/SC/NFR/AD), then DEVELOP (AO/CM/OM). Always log at least the key decisions in AD.
• User shares a case description → map it to the MyBank pattern (see references/mybank-example.md). Identify actors, external systems, NFRs, key decisions, and risks.
• Student / self-study mode → walk through each work product Socratically; prompt the user to fill in; provide MyBank-style example alongside.