06 Methodology

Approach and Methodology

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

Use When

• Use this skill to draft or revise the approach and methodology section of a proposal.
• Load it when the evaluator needs to see how the assignment will actually be delivered.

Do Not Use When

• The task is unrelated to the proposal methodology or work approach.
• The user only needs supporting domain knowledge rather than this section.

Required Inputs

• The ToR, RFP, advert, or assignment brief.
• The selected proposer profile and any relevant procurement or sector context.
• Deliverables, constraints, schedule assumptions, and any required frameworks.

Workflow

Stop or block the workflow when a required input, permission, or acceptance basis is missing. Recover by revising the scope, obtaining evidence, or returning the narrowest qualified draft before proceeding.

1. Read the assignment materials and define the delivery problem this section must solve.
2. Load the proposer profile plus any relevant procurement, sector, and supporting domain skills.
3. Use the structure below to design a tailored methodology with clear phases, deliverables, controls, and logic.
4. Check the methodology against the work plan, team, and financial assumptions.
5. Verify that the section is specific, credible, and evaluator-aware before finalizing.

Quality Standards

• Keep the approach assignment-specific, concrete, and delivery-focused.
• Use British English and East African professional tone unless the bid format requires otherwise.
• Prefer named methods, explicit deliverables, and realistic controls over generic process language.

Anti-Patterns

• Releasing the section with an unresolved mandatory input. Fix: block release and name the evidence owner.
• Hiding a contradiction with another proposal section. Fix: reconcile the source sections before drafting resumes.
• Treating an unavailable check as passed. Fix: mark it not assessed and return a qualified draft.
• Do not submit a recycled generic methodology with no tie to the actual brief.
• Do not describe activities without deliverables, sequence logic, or client value.
• Do not make commitments the work plan, team, or budget cannot support.
• Do not name methods without evidence flow. Fix: state inputs, action, decision, output, and acceptance.
• Do not hide client dependencies. Fix: assign inputs, approvals, due dates, and recovery.

Outputs

Evidence Produced

Capability and Permission Boundaries

Read and search are required; any edit or external action remains within the explicit authority and permission boundary stated below. Analysis is read-only by default; drafting requires authority. Methodology does not authorise production changes, client decisions, fieldwork, data access, spending, or certification.

Degraded Mode

Without complete scope, evidence, schedule, or team data, return a bounded outline, assumptions, and clarification list. Do not claim feasibility or acceptance.

Decision Rules

Worked Example

For an ERP bid, sequence discovery, posting-rule design, configured prototype, migrated-data rehearsal, UAT, cutover, and first close, each with finance-owner approval and recovery conditions.

QC Story, PDCA, compliance screening, and review

For each phase, expose the problem, baseline, target, evidence, countermeasure, owner, acceptance test, and recovery path. This makes the methodology auditable rather than a list of activities. Use PDCA for pilots, M&E, change, and implementation: pre-register the expected signal and guardrail, measure actual behaviour or delivery evidence, then standardise, revise, pause, or stop.

Before release, run a compliance screen against every ToR/RFP instruction, eligibility rule, mandatory form, page/file rule, deadline, separation of technical and financial content, conflict/confidentiality boundary, and evidence claim. Record source, status, owner, reviewer, and unresolved consequence. Run an evaluator simulation after the screen and after material revisions; a persuasive narrative never cures a missing mandatory response. Read references/proposal-compliance-and-qc-story.md for the reusable matrix.

References

• Proposal skills router for repository-wide routing and mandatory quality gates.
• ../profiles/SKILL.md for proposer selection and voice.
• ../sectors/SKILL.md for procurement and sector routing.
• ../premium-client-proposal-strategy/SKILL.md when the assignment targets premium clients, executives, enterprise buyers, affluent markets, strategic growth, pricing, sales, or high-ticket transformation.
• ../website-design-proposal-strategy/SKILL.md when the methodology includes website design, redesign, SEO, content architecture, ecommerce, landing pages, portals, web frontends, launch, training, or support.
• ../service-design-proposal-strategy/SKILL.md when the methodology includes journeys, service blueprints, co-creation, support redesign, citizen/customer experience, or touchpoint improvement.
• ../customer-service-and-maintenance-proposals/SKILL.md when post-launch support, SLAs, maintenance, incident response, or optimisation are part of delivery.
• ../sales-discovery-and-objection-handling/SKILL.md when methodology assumptions or evaluator objections need to be anticipated.
• ../proposal-storytelling-and-evaluator-journey/SKILL.md when phase logic needs a stronger narrative, storyboard, or design-rationale explanation.
• ../references/technical-strategy-credibility-checklist.md when the methodology includes SaaS, AI, software, cloud, APIs, integrations, architecture, or operations.
• Root and local references/ files for persuasion, delivery excellence, and analytical frameworks.

This is the technical heart of the proposal. It is where the firm explains how it will actually do the work — not just what it will deliver. A strong methodology is specific to this assignment, not a recycled generic framework.

What to Gather Before Writing

• The full scope of work from the ToR
• The deliverables required and any specified formats or standards
• Any methodology or framework the firm wants to apply
• The overall timeline available for the assignment
• Any constraints: connectivity, client staff availability, legacy systems, budget
• The assignment type — ICT system implementation, management consulting, capacity building, assessment, or other

Structure

Conceptual Approach

One to two pages describing the firm's overall philosophy for this type of assignment. Explain:

• The framework or methodology being applied and why it suits this assignment
• How this approach differs from a standard or generic approach
• What risks this approach specifically manages

This is where to introduce any proprietary methodology, branded framework, or structured process the firm uses. Name it clearly and explain what it means in practice for this client.

Logic Tree Methodology Construction

Based on Barbara Minto's Pyramid Principle (as applied in Freed's Writing Winning Business Proposals), methodology design should follow a logic tree approach rather than a linear narrative:

• Each methodology phase should be a single action that expresses a result — that is, a deliverable. A phase is not a vague category of effort; it is an action that produces something the client can review.
• Actions should be as specific as possible. Not "gather data" but "identify resource requirements for each implementation option." Specificity signals competence and builds evaluator confidence.
• Each group of actions at one level must be MECE — Mutually Exclusive and Collectively Exhaustive. No two phases should overlap in scope, and taken together they must cover the entire assignment. If there is a gap, something is missing. If there is overlap, the logic tree needs restructuring.
• Every action at every level must contribute to achieving the top-level objective. If a phase or sub-activity does not clearly serve the assignment objective, it should be removed or reframed.
• Build the logic tree FIRST, then sequence into phases. Do not write phases linearly from start to finish. Instead, identify the full set of actions needed, group them logically, verify MECE compliance, and only then arrange them in a time sequence. This prevents the common error of front-loading familiar activities and leaving gaps at the end.

Phase-by-Phase Plan

Break the assignment into clear phases. For each phase, write:

Phase [N]: [Name] — [Duration, e.g., Weeks 1–3]

• Objectives: what this phase achieves
• Key activities: the specific work done, with enough detail to be credible
• Key deliverables: what the client receives at the end of this phase
• Client inputs required: what the client must provide for this phase to proceed

Standard phases for ICT system assignments:

1. Inception and Planning
2. Requirements Analysis
3. System Design
4. Development and Configuration
5. Testing and Quality Assurance
6. Deployment and Go-Live, including release controls, rollback, observability, and incident readiness where the system will enter production
7. Training
8. Post-Implementation Support

Standard phases for website design and development assignments:

1. Inception, commercial goals, and stakeholder alignment
2. Website strategy, audience, analytics, and competitor review
3. Content, SEO, and information architecture
4. UX journeys, wireframes, and prototype validation
5. Visual design system and responsive template approval
6. Development, CMS/configuration, integrations, and analytics setup
7. QA: accessibility, performance, security, SEO/schema, browser/device, forms, and content checks
8. Launch: redirects, DNS/hosting, backups, Search Console/Bing, social previews, and go-live report
9. Training, handover, support window, and optimisation backlog

Standard phases for service design assignments:

1. Framing, outcomes, actors, and service-success measures
2. Current-state journey research, touchpoint inventory, support-log review, and stakeholder interviews
3. Service blueprint covering frontstage experience, backstage processes, data, policies, systems, and handoffs
4. Co-creation workshops with users, frontline staff, managers, and technical or policy owners
5. Prototype and validation of the riskiest service moments
6. Target service model, implementation roadmap, training, content, governance, and measurement plan
7. Pilot support, issue handling, and continuous-improvement backlog

Standard phases for DevOps, CI/CD, cloud, SaaS, or PHP/LAMP assignments:

1. Inception and value-stream mapping
2. Current-state delivery, release, and operations assessment
3. Pipeline, branching, testing, security, and deployment diagnostics
4. Observability, incident response, and reliability review
5. Target operating model and roadmap design
6. Pilot implementation or quick-win hardening
7. Knowledge transfer, runbook handover, and improvement backlog

Standard phases for SaaS implementation and SaaS product-development assignments:

1. Inception, Discovery, and SaaS Strategy Gate — pain chain, value at stake, ICP, Critical Event, tenant model and isolation decision, integration discovery, data residency and regulator map.
2. Control Plane Build — tenant onboarding automation, tenant management, identity, billing integration, per-tenant observability, cost attribution, audit logging.
3. Application Plane Build — configuration, integration build, tenant-context propagation, data partitioning, performance and scale testing under realistic multi-tenant patterns.
4. Trust, Compliance, and Operations Hardening — SAST/SCA/DAST, independent penetration test, compliance evidence pack, BCDR design and test, incident response runbook tested.
5. User Acceptance, Pilot, and Go-Live — UAT entry gate, pilot cohort, 30-day pilot review, cutover plan with rollback, cutover, stabilisation.
6. Adoption and Value Realisation — customer success engagement, lifecycle communications launch, 30/60/90-day adoption and value reviews, QBR cadence established, first expansion conversation.
7. Optimisation and Ongoing Operations — continuous improvement backlog, quarterly tenant-cost-attribution review, annual tier-pricing review, annual security and compliance refresh, renewal and expansion proposals.

For SaaS implementation engagements, use ../saas-implementation-methodology/SKILL.md and ../references/saas-implementation-methodology-blocks.md for the full block library, and ../references/saas-multi-tenant-architecture-block.md for the architectural credibility paragraphs that open the section.

For SaaS, ERP, POS, school, clinic, NGO, inventory, payroll, payment, or marketplace systems that must produce bookkeeping records and financial reports internally, also use ../embedded-accounting-engine-proposal/SKILL.md. Add an accounting-engine workstream covering chart of accounts, posting-rule design, mapping configuration, opening-balance migration, parallel run, reconciliation gates, month-end close simulation, accountant validation, and first-close support.

For any proposal that must show how project funds, client accounts, donor money, budgets, procurement payments, taxes, financial reports, audit evidence, or financial controls will be handled, use ../accounting-finance-advisory/SKILL.md and its references/world-class-finance-accounting-section.md. Add a finance/accounting workstream covering funds flow, budget governance, approval controls, source-document evidence, reconciliations, tax/statutory treatment, reporting cadence, audit file, and financial close-out.

For AI-on-SaaS engagements — where the deliverable is a multi-tenant SaaS that contains AI features (RAG, copilots, agents, AI analytics, AI-assisted decisioning) — use ../ai-on-saas-combined-methodology/SKILL.md and ../references/ai-on-saas-methodology-blocks.md. The combined methodology layers an AI plane (model gateway, model registry, eval harness, RAG indexes per tenant, red-team harness, drift watch) on the control plane and application plane; gates AI workstreams in every phase; and introduces binary AI acceptance criteria (golden-set pass, hallucination ceiling, abstain-correctness, cost-per-call, tenant-isolation probe pass). For the AI risk register and Responsible-AI commitment, use ../ai-on-saas-risk-and-responsible-ai/SKILL.md.

For agentic engagements — where the deliverable is one or more AI agents (LLM systems that plan, call tools, decide, and act on the buyer's behalf), or a multi-agent system, or an agentic layer inside a SaaS product — use ../ai-agent-methodology/SKILL.md and ../references/ai-agent-methodology-blocks.md. The agent methodology runs eight phases (Discover → Action-Catalogue Design → Architecture for Autonomy → Build → Shadow → Supervised → Agentic → Operate); gates each phase with binary agentic acceptance criteria (task-success, intervention rate, irreversible-action incidents, audit-log completeness, kill-switch time-to-stop, red-team pass); commits autonomy per action class; and engineers a quarterly kill-switch drill. Load alongside the AI-on-SaaS combined methodology when the agent lives inside a SaaS product. For the agent risk register and Responsible-AI Agent Commitment, use ../ai-agent-risk-and-responsible-ai/SKILL.md.

For AI, SaaS, and software strategy assignments, include an early strategy-quality gate: diagnosis, guiding policy, coherent actions, assumptions to test first, operations model, and speed-cost-impact trade-offs.

Standard phases for management consulting assignments:

1. Inception and Scoping
2. Current State Assessment and Diagnostic
3. Analysis and Opportunity Identification
4. Solution Design and Recommendations
5. Implementation Planning
6. Implementation Support (if in scope)

Adapt these to match what is actually required in the ToR. Not every assignment needs every phase.

P-I-P Structure for Each Phase

Every methodology phase should use the Persuasion-Information-Persuasion structure:

• P (opening) — Why this phase, out of all possible approaches, is right for this client's specific situation. This is the "selling" rationale that distinguishes a strategic methodology from a generic one.
• I (middle) — What will be done: specific actions, tools, techniques, and data sources.
• P (closing) — What will result: deliverables produced, benefits to the client, how this phase feeds the next.

Without P-slots, a methodology is a list of activities with no selling power. Compare:

• Generic: "Phase 1: Inception and Desk Review. The team will review existing documents..."
• P-I-P: "Phase 1 begins with a structured desk review because [client]'s existing documentation — including [specific documents from ToR] — provides a rich baseline that reduces the need for costly primary data collection. We will review [specific items], applying [specific analytical framework] to map current state against [benchmark]. This phase will produce a Current State Assessment Report and a validated Inception Report, giving [client] an early diagnostic before fieldwork begins."

The P-I-P structure forces the writer to justify each phase (not just describe it) and to articulate the value of its deliverables (not just list them). Every phase description in the proposal should follow this pattern.

Hypothesis-Driven Methodology

The consulting standard for structuring analytical work is hypothesis-driven:

• State an initial hypothesis based on the ToR and available information. This shows the evaluator that the firm has already begun thinking about the problem, not waiting for the contract to start.
• Structure each phase as a test of hypothesis branches. Each phase should be designed to confirm, refine, or refute specific elements of the hypothesis.
• Show how evidence from each phase narrows the analysis. The methodology should make clear how early findings feed later phases, progressively reducing uncertainty.
• Converge on root cause and recommendation. The final phases should synthesise evidence into actionable conclusions.

Proposal language example: "Our initial hypothesis, informed by [source], is that [problem] is driven primarily by [suspected cause]. Phase 1 will test this through [method]. If confirmed, Phase 2 will develop [solution]. If our analysis reveals alternative drivers, we will adapt our approach accordingly — our methodology is designed for structured flexibility."

This approach demonstrates intellectual rigour and signals that the firm will not simply execute a checklist but will actively think through the problem.

Three Project Types and Objective Verbs

Based on Freed's framework, consulting assignments fall into three types, each requiring different objective verbs, deliverables, and results language:

Many development consulting assignments combine types (e.g., Insight + Planning in one engagement). Each type requires its own objective, and the methodology should show a clear decision point between the insight phase and the planning phase. Do not blur the boundary — evaluators look for evidence that the firm understands what kind of work each phase entails and what kind of results can realistically be promised.

Deliverables Summary Table

A table listing every deliverable, the phase it falls in, the due week, and the format.

What, Why, How for Recommendations

Every recommendation in the final deliverable must include three components:

• What — the specific recommendation, led by an action verb. Be precise: not "improve training" but "establish a quarterly skills assessment cycle for all field officers, with results linked to individual development plans."
• Why — evidence from the analysis, external precedent, or benchmarking that supports this recommendation. The evaluator (and ultimately the client) needs to see that recommendations are grounded in evidence, not opinion. Reference specific findings from earlier phases, comparable interventions in similar contexts, or recognised standards.
• How — implementation steps, responsible parties, timeline, and resource requirements. A recommendation without a path to implementation is an observation, not advice. Include enough detail for the client to act on it or to commission implementation support.

This structure ensures that the methodology does not stop at diagnosis but carries through to actionable, evidence-based guidance. When writing the methodology, signal that the final deliverable will follow this structure — it reassures evaluators that the firm's outputs will be practical, not academic.

Quality Assurance

Describe the internal quality process: peer review, client sign-off gates, version control, and how feedback is incorporated. Apply the Done-Done standard — every deliverable must be complete, checked, proofed, formatted, and ready to present before submission to the client. Keep this concise — two to four bullet points, but signal rigour:

• "Every deliverable undergoes our Done-Done quality process: peer review, editorial review, and a final quality gate before submission to the client."
• "We apply the six-point solution validation framework — testing every recommendation for feasibility, acceptability, sustainability, scalability, risk, and value."

Project Management and Governance

Describe:

• How the project will be managed day to day
• Reporting frequency and format (weekly status reports, steering committee meetings)
• Issue escalation path
• What the firm needs from the client in terms of a counterpart or focal point
• Pre-briefing protocol: "Before formal presentation of findings, we conduct individual briefings with key stakeholders to ensure alignment and address concerns" (the prewiring technique)

Risk Management

A short risk table identifying the top five to eight risks, their likelihood and impact, and the specific mitigation action.

Knowledge Transfer and Sustainability

Every methodology should include a knowledge transfer component, not as an afterthought but as a deliberate design element in every phase. Apply the Structure-Focus-Design-Embed framework — the Embed phase is where most consulting engagements fail:

• Pair working with client counterparts during every phase
• Formal training sessions at key milestones
• Documentation of all processes, tools, and frameworks used
• Handover plan ensuring the client can maintain and extend outputs independently

Signal this in the methodology: "Our approach embeds knowledge transfer in every phase, not as a separate activity but as a way of working. The client's team will be equipped to maintain and extend all outputs independently after the engagement concludes."

Support, Maintenance, and Service Recovery

For website, software, SaaS, AI, service-design, and transformation assignments, include a support and maintenance subsection when post-launch operation matters. State:

• support channels, cover hours, severity levels, response targets, and escalation path
• what is included in warranty, maintenance, optimisation, hosting, licence, and enhancement work
• incident communication, client update cadence, workaround handling, and closure verification
• handover artefacts: runbook, admin guide, content guide, training materials, support register, and improvement backlog

Reference Library

Read the relevant reference file when a methodology requires detailed frameworks or delivery excellence standards beyond this SKILL.md.

Tone Rules

• Five to ten pages — this section should be the longest in the technical proposal
• Specific to this assignment — evaluators notice when methodology is generic
• Reference ToR deliverables by name in the phase descriptions
• Every phase must have at least one named deliverable
• Apply SCQA within each phase: open with what the reader accepts (Situation), introduce the challenge (Complication), raise the question this phase answers (Question), then present the approach (Answer)
• Follow east-african-english standards throughout