Choosing a PPM Tool at Lumen Media Group
Lumen Media Group is selecting a PPM tool. It has 450 potential users in five countries, a mix of predictive and agile delivery (about 60% agile) and PPM maturity assessed as emerging. The landscape includes three spreadsheet portfolio trackers, an enterprise finance system and a collaboration tool already used by agile teams. A vendor demonstration impressed the CFO with AI forecasting. The proposed licence is £280k over three years plus £120k implementation. The P3O has no tool administrator and no defined data model. Two previous tool implementations failed: one was abandoned after nine months; the other became a reporting-only tool used by 30 people. Agile teams say any tool must not force stage gates; the PMO wants mandatory gates. The CFO wants a decision in six weeks, before the vendor's discount expires.
1. Advise on tailoring and sequencing. How should the P3O approach process, data and tooling across predictive and agile delivery?
Read the worked answer
Process and data before tool. A tool codifies whatever operating model exists. With no defined data model and no administrator, buying now would automate inconsistency. Define the target operating model first: what decisions the tool must support, what data is authoritative, who owns each data element, and how portfolio, programme and project layers relate. Then derive requirements, then evaluate vendors.
Tailor by delivery method, not by ideology. Design a common portfolio layer - prioritisation, funding, benefits, risk, resource capacity, reporting - that applies to all work regardless of method. Beneath that, allow method-specific execution: stage gates as decision points for predictive work, and flow and backlog metrics for agile teams. Gates should be proportionate decision checkpoints, not mandatory ceremonies imposed on agile teams. This resolves the PMO-versus-agile dispute by separating portfolio governance from delivery method.
Tailor by maturity. Emerging maturity means start small: two or three use cases, one portfolio or region, a limited user group. A 450-user rollout at this maturity repeats the previous failures.
Tailor by geography. Five countries means data protection, access, language and time-zone requirements must be in the requirements, not discovered at rollout.
Sequence: operating model and data model (weeks 1–6); requirements and weighted evaluation (weeks 4–8); proof of concept with real data (weeks 8–14); pilot with success criteria (months 4–6); phased waves with spreadsheet decommissioning at each cutover. The vendor's six-week discount is a commercial pressure, not a delivery constraint; negotiate an extension or accept that a rushed decision repeats history.
2. Define the requirements and decision criteria the P3O should use, including total cost of ownership and adoption.
Read the worked answer
Functional requirements: portfolio prioritisation and scenario modelling; financial and timesheet integration; resource capacity and demand; risk and issue; benefits tracking; configurable reporting and dashboards; agile boards and flow metrics; demand intake and workflow; assurance and gate management; document and configuration control; role-based access across five countries.
Non-functional requirements: usability for occasional users; integration with the finance system and the existing collaboration tool; data quality and validation; security and data protection; reporting performance at 450 users; configurability without code; support model and vendor responsiveness; exit and data portability.
Total cost of ownership: licence £280k plus implementation £120k, plus a funded administrator (0.5–1.0 FTE), integration, training, data migration, annual uplifts and eventual exit. Compare against the current cost of three spreadsheet trackers, manual reporting effort and failed implementations. The headline £400k is not the TCO.
Adoption criteria: usability test with real users, proof of concept on real data, training effort, and a realistic adoption curve. Set weighted criteria, for example operating-model fit 30%, usability and adoption 20%, integration 15%, TCO 15%, vendor viability and support 20%. Require a proof of concept and reference customers with a similar agile-predictive mix. Treat the AI forecasting demonstration as unproven until tested against Lumen's own data - at emerging maturity, forecasting is a distraction from data quality and adoption. Document the scoring and the rationale so the decision survives scrutiny.
3. How should the P3O structure the rollout and governance to avoid repeating the two previous failures?
Read the worked answer
Governance first. Appoint an accountable business owner at executive level, a product owner from the P3O, and a funded tool administrator before contract signature. Establish a user group with representation from agile teams, PMs, finance and each country. Agree change control for configuration so the tool does not drift into a reporting-only compromise.
Contract for adoption, not delivery. Milestone payments tied to acceptance criteria, adoption targets and data quality; a proof-of-concept exit clause; capped annual uplifts; defined support response times; and clear data ownership and exit terms. Do not pay the implementation fee on go-live alone.
Phased rollout with gates. Pilot one portfolio or region for three months with explicit success criteria: active users, data completeness, reporting timeliness, user satisfaction. Hold a stop/go review at pilot exit and at three months post-wave. Expand only when the previous wave meets its criteria.
Data discipline. Cleanse and migrate only what is needed; define data owners and quality KPIs; do not migrate historical data that nobody will use. Poor data is the most common reason tools become reporting-only.
Decommission the old. Retire the spreadsheets at each cutover with a named owner and a date. If the old route stays open, users will take it, and the tool will be used by 30 people again.
Adoption and benefits. Role-based training, named champions, and a dashboard of adoption measures reported to the sponsor. Baseline the benefits - reporting effort, data requests, time to produce portfolio reports - and review them at 3, 6 and 12 months. Publish lessons at each wave closure so the organisation sees that this implementation is being managed differently from the previous two.