15.3 Solutions Development and Prioritisation
Key Takeaways
- Solutions development determines the optimal solution to satisfy agreed requirements, which is rarely the solution that satisfies every request.
- Prioritisation techniques such as MoSCoW force explicit trade-offs; "Won’t have (this time)" is a decision recorded, not a rejection.
- Optimal means best against agreed criteria — benefit, cost, risk, time, and whole-life value — not technically most impressive.
- A Minimum Viable Product is the smallest release that generates learning about whether the solution is right.
- A Minimum Marketable Product is the smallest release worth putting in front of customers commercially — related to MVP but a different threshold.
What solutions development means on the APM PMQ
Solutions development is how the project turns agreed needs into a chosen solution approach and a prioritised path to deliver it. Learning objective 17 — Solutions development focuses on evaluating and prioritising requirements so the solution is optimal under real constraints, and on different approaches across life cycles, including MVP and MMP in iterative delivery.
A solution is not automatically "build everything stakeholders asked for." Optimal means the best achievable balance of benefits, cost, time, quality, risk, and strategic fit — often by sequencing or descope of lower-value items.
Exam trap: Treating prioritisation as a one-off workshop output with no link to benefits, constraints, or life-cycle style. Prioritisation is a decision system that shapes what gets built when and to what depth.
From requirements to an optimal solution
After requirements are gathered and analysed (LO16), the project must still decide:
- Which requirements are in the committed solution now?
- Which are deferred, optional, or rejected?
- Which solution options (buy, build, configure, process change, hybrid) best meet the justified needs?
- How will trade-offs be governed when not everything fits time and budget?
Evaluating requirements for solution fit
Evaluation tests each requirement or requirement cluster against solution options:
| Evaluation lens | Questions to ask |
|---|---|
| Value / benefits | Does this enable a benefit in the business case? How large? |
| Mandatory constraint | Is it legally, safely, or contractually non-negotiable? |
| Cost to include | Whole-life cost, not only build cost |
| Time impact | Critical path / release timing effect |
| Risk | Delivery risk, operational risk, technical uncertainty |
| Dependencies | Must it come with other requirements to work? |
| Feasibility | Can suppliers/technology actually deliver? |
| Strategic alignment | Fit with architecture, standards, sustainability, portfolio direction |
Evaluation often produces options analysis: for example, configure a commercial package vs custom build vs manual process redesign. The "optimal solution" is the option (and requirement set) that best meets success criteria within constraints — documented with rationale for governance.
Scenario A — option evaluation
A university needs student identity verification. Option 1: custom biometric system (high cost, high privacy risk, long build). Option 2: integrate a certified third-party service (faster, usage fees, less unique control). Option 3: enhanced manual checks at peak only (low capital, high operational cost, poor student experience). Evaluation against benefits (fraud reduction), risk (data protection), time (enrolment deadline), and cost should be explicit. "Build custom because IT likes projects" is not optimal solution reasoning.
Prioritising requirements
Prioritisation ranks or categorises requirements so scarce capacity is spent on the highest-value or most mandatory work first. It is essential whenever the backlog of desire exceeds the envelope of time, money, or risk appetite — which is almost always.
MoSCoW
MoSCoW is a widely used categorisation technique:
| Category | Meaning | Solution implication |
|---|---|---|
| Must have | Non-negotiable for success or compliance; without it the solution fails | In baseline of the release/project commitment |
| Should have | Important but workaround exists short term | Include if capacity allows; strong candidates for early increments after Musts |
| Could have | Desirable if time/cost allows | First items to drop under pressure |
| Won't have (this time) | Agreed out of current scope | Explicitly deferred or rejected; prevents silent reappearance as assumed scope |
Discipline tip: if everything is "Must," MoSCoW has failed. Force real trade-offs with sponsor and users. "Won't have (this time)" is a powerful clarity tool — it documents conscious exclusion.
Other prioritisation approaches
| Technique | How it works | Best use |
|---|---|---|
| Simple ranking | Ordered list from highest to lowest priority | Small sets; quick workshops |
| Weighted scoring | Score requirements against weighted criteria (value, risk reduction, cost, strategy) | Transparent multi-criteria decisions |
| Value vs effort | Plot benefit against delivery effort; prefer high value / low effort early | Iterative backlogs; quick wins |
| Risk-based priority | Elevate items that retire major uncertainty or compliance risk early | Complex technical or regulated contexts |
| Dependency-first | Prioritise enablers that unlock other value | Architecture, data foundations, safety cases |
Prioritisation should involve the right authority: users for usability value, sponsor for benefits and investment trade-offs, specialists for compliance and technical risk. The project manager facilitates evidence and impact; they do not invent business value alone.
Trade-offs in solutions development
Every prioritisation decision is a trade-off. Classic tensions include:
| Trade-off | Example |
|---|---|
| Time vs scope | Hit the regulatory go-live by deferring Could-have analytics |
| Cost vs quality/features | Reduce custom branding to protect testing budget |
| Speed vs risk | Ship thinner first release vs more assurance before release |
| User desire vs operational cost | Extra self-service feature that doubles support complexity |
| Short-term delivery vs whole-life value | Cheap manual workaround that blocks automation benefits later |
Good PMQ answers name the trade-off, state what is sacrificed, link to success criteria/business case, and show governance (who approved the compromise). Bad answers pretend all constraints can be met without loss.
Scenario B — forced trade-off
A charity CRM project has a fixed grant deadline. Must-haves: gift aid recording, GDPR consent, basic campaign lists. Should-haves: advanced segmentation. Could-haves: donor mobile app. When development capacity slips, optimal prioritisation protects Must-haves and testing, defers the app (Won't this time), and may slip segmentation if needed — with sponsor agreement and benefits forecast update. Cutting GDPR consent to "save the app" would be indefensible.
Life-cycle approaches to solutions development
How solution detail is developed and when prioritisation happens depends on life cycle.
Linear (predictive) solution development
In a linear life cycle, solution development typically:
- Invests more in upfront requirements analysis and design
- Seeks a relatively stable solution definition before major build
- Uses formal baselines and change control for later requirement changes
- Prioritises mainly during definition; mid-project prioritisation often appears as change requests or de-scoping under exception
Strengths: clarity for procurement, regulated design freezes, cost predictability when uncertainty is low.
Weaknesses: if user needs were misunderstood, the "optimal" detailed solution may be wrong — change is expensive late.
Iterative solution development
In an iterative life cycle, solution development typically:
- Holds a clear product vision and success criteria
- Maintains an ordered backlog of requirements/features
- Delivers in increments, re-prioritising based on feedback and learning
- Accepts that detailed solution shape emerges through use and review
Strengths: reduces risk of building the wrong full solution; early value and learning.
Weaknesses: needs active product ownership, disciplined prioritisation, and enough architectural guardrails to avoid endless thrash.
Hybrid patterns
Many projects fix non-negotiables early (safety, data model, integration contracts) while iterating user-facing features. Prioritisation then operates inside an envelope of constraints already baselined.
| Life cycle | When solution detail locks | Prioritisation rhythm |
|---|---|---|
| Linear | Relatively early (definition/design) | Mainly upfront; later via change control |
| Iterative | Progressively each increment | Continuous backlog ordering |
| Hybrid | Early for constrained parts; progressive for uncertain parts | Dual: baselined constraints + iterative backlog |
MVP and MMP in iterative life cycles
Two high-yield concepts for iterative solutions development:
Minimum Viable Product (MVP)
An MVP is the smallest solution that can be released to real users (or a test market) to validate learning about needs, value, and solution fit. The emphasis is on learning under uncertainty with minimal build cost — not on a polished full product.
MVP characteristics:
- Includes only what is necessary to test critical assumptions
- May be intentionally thin or even partly manual behind the scenes
- Success is measured by validated learning (usage, conversion, feedback), not feature count
- Informs the next prioritisation cycle: pivot, persevere, or stop
Example: Before building a full fleet-routing optimisation suite, release a simple dispatcher dashboard for five depots to test whether route suggestions are trusted and reduce overtime — the learning goal drives the thin scope.
Minimum Marketable Product (MMP)
An MMP is the smallest solution worth releasing because it delivers enough customer or user value to be marketable/adoptable. The emphasis is on sufficient value for release, not only experiment design.
MMP characteristics:
- Includes the Must-have value proposition for the target users
- Quality and completeness are high enough that users will adopt (support, UX, reliability thresholds)
- May follow one or more MVPs once learning reduces uncertainty
- Aligns to benefits: a release that nobody will use is not marketable
| Concept | Primary purpose | Typical question |
|---|---|---|
| MVP | Learn and validate assumptions with minimal build | What is the smallest release that tests our riskiest assumption? |
| MMP | Deliver a first version users will actually value and adopt | What is the smallest release worth putting in users' hands for real value? |
Exam precision: Do not treat MVP and MMP as synonyms. MVP optimises for learning; MMP optimises for minimum releasable value. In regulated or safety-critical contexts, "minimum" still means meeting mandatory compliance — viability never excuses illegal or unsafe release.
Scenario C — MVP vs MMP confusion
A fintech team labels a buggy payments feature an "MVP" and releases it to all customers. Fraud controls are incomplete. That is not a valid MVP; it is an uncontrolled risk. A true MVP might be a limited pilot with enhanced monitoring and clear success metrics. An MMP would only follow when core payment reliability, fraud controls, and support are sufficient for broader market release.
Scenario D — iterative prioritisation in action
After MVP feedback shows users ignore advanced filters but love saved searches, the backlog is re-ordered: saved-search robustness becomes Must for MMP; advanced filters drop to Could. Solutions development here is prioritisation guided by evidence — the optimal solution path changed because learning changed value estimates.
Putting LO17 answers together
When a scenario asks how to develop or prioritise a solution:
- Restate success criteria and constraints from the business case and context.
- Evaluate requirements/options against value, mandate, cost, time, risk, and feasibility.
- Apply an explicit prioritisation method (MoSCoW or scoring) with real Must vs Won't choices.
- State trade-offs and who authorises them.
- Match approach to life cycle: early lock-in (linear) vs incremental learning (iterative).
- If iterative, use MVP/MMP correctly — learning vs marketable value — within compliance limits.
That chain demonstrates solutions development as managed optimisation, not endless feature accumulation.
In MoSCoW prioritisation, what does "Won't have (this time)" primarily achieve?
How do MVP and MMP differ in iterative solutions development?
A project has high uncertainty about user behaviour but a fixed regulatory deadline for core safety functions. Which solutions development approach is most defensible?