2.1 Stakeholder Needs & Sourcing Plans (Task 1-A-1)
Key Takeaways
- Separate stakeholder needs (must-haves tied to business outcomes) from wants (preferences that can be traded) before writing a sourcing plan
- Map stakeholders by influence and interest so you engage decision-makers early and keep influencers informed without letting noise drive requirements
- Translate validated needs into a sourcing plan covering scope, timing, budget envelope, risk, and success metrics—not just a shopping list
- Use a clear intake and governance path so requests are prioritized, conflicted requirements are resolved, and maverick buying is reduced
- Task 1-A-1 is heavily tested (~5 scored questions)—expect scenarios that punish jumping to suppliers before clarifying what the organization truly requires
Stakeholder Needs & Sourcing Plans (Task 1-A-1)
Exam focus: ISM Task 1-A-1 asks you to assess stakeholder needs and organize them into sourcing plans. Expect roughly five scored questions that test whether you clarify requirements before shopping, distinguish needs from wants, and use intake/governance instead of ad-hoc buying.
Sourcing does not start with a supplier search. It starts with understanding what the internal customer and the organization actually require, why they require it, and how those requirements fit budget, timing, risk, and policy. Candidates who skip this step often pick the wrong method, over-specify the RFP, or award to a supplier that cannot deliver the real outcome.
Needs Versus Wants
A need is a requirement that must be met for the business outcome to succeed—safety, regulatory compliance, functional performance, capacity, or a non-negotiable service level. A want is a preference: brand, aesthetic, nice-to-have features, or a preferred supplier with no objective advantage.
Practical test: if removing the item would cause the project, process, or compliance obligation to fail, it is a need. If removing it changes comfort or preference but the outcome still works, it is a want. Document both, but only needs become mandatory evaluation criteria. Wants become scored preferences or negotiation chips.
Scenario: Engineering requests “Brand X servers only” for a data-center refresh. Digging in, the need is certified interoperability with the existing hypervisor, 99.99% uptime, and a four-hour parts SLA. Brand X is a want—unless Brand X is the only path that meets those criteria after market check. The sourcing plan should state the performance and support needs; brand can be preferred but should not silently become a sole-source without justification.
Stakeholder Mapping
Stakeholders are anyone who influences, decides, uses, pays for, or is affected by the purchase. Map them by influence (can they approve, veto, or block?) and interest (how much do they care day-to-day?).
| Stakeholder type | Typical role | Engagement approach |
|---|---|---|
| Decision-maker (high influence / high interest) | Budget owner, VP, project sponsor | Early discovery; sign-off on needs and plan |
| Influencer (high influence / lower interest) | Legal, IT security, quality, finance | Structured reviews on risk, policy, and controls |
| User (lower influence / high interest) | Operators, end users, plant staff | Requirements workshops; validate usability |
| Observer (lower influence / lower interest) | Adjacent teams | Periodic status; no veto power |
Common trap: treating the loudest requester as the only stakeholder. Finance may care about total cost of ownership (TCO), Legal about indemnity and data privacy, Operations about changeover downtime, and Sustainability about Scope 3 reporting. Missing an influencer late causes rework—or a failed award.
Clarifying Questions That Surface Real Needs
Use structured discovery, not a blank “what do you want?” email:
- What business problem must this solve, and how will success be measured?
- What happens if we do nothing, delay three months, or cut scope by 20%?
- Which requirements are regulatory, contractual, or safety-driven versus preference?
- What interfaces, standards, or incumbent systems constrain options?
- Who must approve spend, supplier risk, and go-live—and by when?
Capture answers in a requirements brief that stakeholders can confirm. Ambiguous phrases like “best quality,” “as soon as possible,” or “industry leading” are red flags—convert them into measurable criteria.
Organizing Needs Into a Sourcing Plan
A sourcing plan is the bridge from validated needs to execution. It is not a purchase order and not a full category strategy (that deepens later). At foundation level, the plan should organize:
- Scope and requirements — mandatory needs, desirable wants, volumes, service levels, and out-of-scope items.
- Timing — need-by date, lead-time risk, and decision milestones.
- Commercial envelope — budget range, cost model (unit, TCO, subscription), and savings or value targets.
- Supply-market posture — known incumbents, likely competition level, make-or-buy flags, and geographic constraints.
- Risk and compliance — safety, quality, cybersecurity, ESG, single-source exposure.
- Success metrics — how the business will judge the outcome after award.
- Approach hypothesis — likely processing method (spot, contract release, bid) to refine in Task 1-A-4.
Keep the plan proportionate. A $2,000 spot tool purchase needs a lightweight checklist. A multi-year facilities services buy needs a formal plan with governance gates.
Intake and Governance
Without intake discipline, stakeholders bypass supply management, fragment spend, and lock in poor specs. Effective intake typically includes:
- A single request channel (portal, form, or shared intake) with minimum data: need description, timing, budget estimate, and requester/sponsor.
- Triage by value, risk, and complexity—route low-risk catalog buys differently from strategic projects.
- Thresholds for competitive bidding, legal review, and executive approval.
- Conflict resolution when stakeholders disagree (e.g., engineering vs. finance on feature cost).
- Feedback loops so requesters see status and learn why “wants” were challenged.
Governance is not bureaucracy for its own sake. It protects the organization from noncompliant spends, protects supply professionals from being blamed for late discovery, and creates an auditable trail of why a requirement was accepted or deferred.
Exam Traps Candidates Miss
- Jumping to a preferred supplier before documenting needs and alternatives.
- Treating stakeholder wants as mandatory evaluation criteria.
- Writing a “sourcing plan” that is only a supplier shortlist with no scope, timing, or success metrics.
- Ignoring silent stakeholders (Legal, IT, Quality) until after award.
- Confusing intake governance with negotiation tactics—this task is about clarifying and organizing demand, not closing the deal.
When a vignette presents conflicting internal voices, the best first move is almost always clarify and prioritize needs with the right stakeholders, then document them in a plan—before market outreach deepens.
An operations manager insists on a specific brand of packaging film "because we have always used it." Engineering confirms three films meet tensile strength, food-contact, and line-speed requirements. What is the best supply management response under Task 1-A-1?
Which element most clearly belongs in a foundation-level sourcing plan rather than only in a casual email request?
Legal and IT security have high influence but limited day-to-day interest in a software purchase. How should they be engaged?
A plant submits ten urgent one-off buys each week through side emails, bypassing the intake portal. What governance action best addresses the root problem for Task 1-A-1?