The Core P3M Data Club was formed to create a data standard for portfolio, programme and project management. This enables us to more effectively deliver business integrated governance for Business as Usual and Change. This means our journey from Main Board objectives, targets and challenges can be delivered through portfolios, programmes and projects in the context of finance, management teams, support and assurance more easily and effectively. This will deliver more strategy outcomes, greater business agility, lower management overhead and efficiency benefits. On from Programme, this document outlines the assumptions we make around how Projects operate in delivering outputs through projects - leading to changes and benefits realisation. We offer a business agenda for Project Boards, and present management information definitions that we believe will support their business agenda. We recognise that “projects is also a way to deliver “business as usual”. From this, we have derived a data model that would support the MI for the whole P3M business agenda and have integrated this with the Core P3M Data Model. For a high res version click here - https://1drv.ms/w/s!AscRj7Bfp6vQgoh_FdtyvxqibhQtHQ?e=mC8LTe Find out more and collaborate here: https://www.linkedin.com/groups/13651399/

1. Page 1
This work is licensed under a Creative CommonsAttribution-ShareAlike 4.0InternationalLicense.

2. Page 2
Project Board
Assumptions
Projectsare writtenaboutextensivelybythe APMandthe PMI andare the subjectof
AxelosPublications“Prince2®”/“Prince2Agile®”andfeature centrally inthe Praxis
Framework. There are otherframeworksinwhichthe projectentityfeaturesbutmay
not be calleda project(e.g.itmaybe calleda Program).In some situations,
accountabilitymaynotbe constructedaroundthe “Project”at all and may be
Service,AssetorProductorientated,andsuchworkmaybe lookedafterby
ManagementTeamsand “Release TrainEngineers”ratherthanProjectManagers.
Thisguidance doesnotattemptto replicate these sourcesof knowledge, orimpose
termssetson people butitdoesbuildonthose foundations offeringassumptions
fromthemand givingspecificsuggestions forProjectBoardinformationtoenable
the ProjectBoard to carry out itsresponsibilitiesandpotentialagendas,MIneeds
and the data implications basedonanexample scenario.
Agenda Dashboard – ProjectBoard
The processof arrivingat actionsanddecisionsforthe Projectis referredtohere asan “Agenda”,as we believethatmuchof itneedsto be concludedata
meeting(ora series) where decisionsare captured,andactionsallocated.The keyinformationthatthe ProjectBoardneedstointerrogate toprovide
effectiveoversightissummarisedinthe AgendaDashboardbelow:
From APMDirecting
Change

3. Page 3
Progressand Status - Thissectionlooksbackwardsandpicksup overall Project
progress/performance/issues,escalationsandexceptions,summaryof cost/resources.
Enablers – thissectioncovers a re-statementorreviewof the overall Projectgoalsand
imperativesstatedasobjectives/challenges(have there beenanychangesinunderlyingdrivers)
and theirstatus,customerfeedback andHealth/Safetymetrics.
Prediction– a lookforwardandpredictionof outputs andconfidence trendsinthe achievement
of those.Thissectionof the dashboardandmeetingincludes areviewof forecasttimeline,
overall costs, resource issues,reviewof risks, andresourcescommitment.
MI Implication
The followingtable offersanexample ProjectBoardorderof Business,givingusanimplicationforManagementInformation (MI) elements.
Generic Description Input Output
RAID Review StatusPjB
Risks/Actions/Assumptions/Issues/Decisions/Depen
dencies
Risks,Actions,Issues,Decisions UpdatedRAID
Data/Process
Review
Exceptionstoprocessanddata compliance withthe
programme.
Process/DataExceptionsList UpdatedRAID

4. Page 4
Generic Description Input Output
Project
Summary
Storyso far. Statuson KeyObjectives(Progress,
RAID).Changes.Environmentchanges.
PID/BacklogOverview.Progresssummary(%/this
manyout of thismany – usingMust ShouldCould
Would(MSCoW),RAID
UpdatedRAID
Project
Review
Identify
Risks/Actions/Assumptions/Issues/Decisions/Depen
denciesneededaround:
 KeyMilestonesanddependencies
 ProductStatus
 Issues,risks, assumptions, dependencies,
changes
 Finance/Spend/Resource
 Quality/quantity
 Benefits
 (Stakeholder) Satisfaction(Scores)
 Confidence (Indicators)
 Trendalerts
ProposedChanges,escalatedissues,risks
ProjectDeliveryPlan –Exceptions.
Statuson KeyMilestones(Progress,RAID,Forecast,
Dependency,EV/Quantity)
Productstatus – completed/todo
Spend(budgetvsspendvsremaining)
Resource (Allocationvspendvremaining)
BenefitProgressandForecast
SatisfactionStatus(governance,team,
stakeholders,customers),
Confidence Status.
UpdatedRAID
(includingrecovery
planif necessary,
Resource
Shortfall/release)
ProposedChangesto
PgB and customers.
Escalationsto
ManagementTeams,
PgB/PortfolioProgress
Group (viaRAID)
Continue/Terminate/Pa
use Decision.
Communications
instructions.
ProjectE&E
Review
EffectivenessandEfficiency.Mattersrecurring,
lessons,reflective output. Innovationstoapply -
What has the projectlearnedthatcan improve
effectiveness/efficiency
Matters arising,lessons/reflections,innovationsto
apply
Recommendationsfor
the
programme/portfolio
intoRAID
Project
Outlook
KeyPlace to lookforwards.What ison the horizon,
new,whatisin flight,whathaschanged,whathas
completed.Trendalerts.Deliverables,quantities
and estimatesatcompletion(resource,cost,dates,
benefits)–EAC
Itemsproposedfor/indelivery(changed,added,
speededup/sloweddown),Itemsproposed
completed/stopped,Priorityimplementation
recommendations
Stages/work
packages/sprintsto
start/continue in
delivery

5. Page 5
Generic Description Input Output
Products/Stages
completed(toclose)
UpdatedRAID
Project
Communicatio
ns
Checkinthat the projectiscontent overall. Review
communicationsforreleasetoPgB/PPGand
stakeholders.
Proposedcommunicationsforrelease Communicationsfor
release
UpdatedRAID
RAID Closure ConfirmNew/Statuson
Risks/Actions/Assumptions/Issues/Decisions/Depen
dencies
ConfirmNew/Statuson
Risks/Actions/Assumptions/Issues/Decisions/Depen
dencies
UpdatedRAID
Resources
Thissectioncontainslinkstodetailedpresentation/backupmaterial tothe narrative above
The detailsof the assumptionsandMI definitions andexamplesof reportsprovidedbynumerousconsultantsandvendorscanbe provideduponrequest.
Example Scenario
In the example scenario, Projectsmaybe governedbya“ProjectBoard”, the constitutionof whichwill be clearandunderstood,andatleasthave an
Accountable personultimately“incharge”of thisAccountabilityNode (i.e.the “ProjectSponsor”).
Where projectsare usedas a meansto deliverBusinessasUsual (BAU- e.g.customerprojects,products/assets) there maybe aslightlydifferentname,
purpose forand compositionof aProjectBoardalignedtothe customeror customerstheydeliverto(e.g.a programme,acustomera portfolio,aproduct
manager,a line manageretc).The exactcompositionof the ProjectBoardwill be determinedwithinthe Project, basedonanorganisation’sguidelines,
whichare assumedtohave come froma bestpractice basis.
Typically,projectshave alifecycle andhave differentcharacteristicsare theyproceedthroughtheirlifecycles,andtherefore have developinggovernance
and data needs. Forexample:

6. Page 6
Phase Characteristic
Start up Ensure Authority,Objectives,Scope,Constraints,QualityExpectationandcontrolsinplace.
Design/AppointProjectManagementTeam,Agreethe ProjectApproach
Agree the ProjectBrief,Initiation Stage Plan(PID,nextstage)
Initiate SupportDevelopingaContract – Documentunderstanding,firmingupscope,quality,objectives,keyproductsandconstraints.
Ensure Decisionmakingclear(e.g.Change management)
Ensure Suitable BusinessCase –Reasons,Benefits,Risks,FinancialCase,Justification
Ensure Planand Cost,Baseline,CommunicationsPlanning.Define howtoachieve ProductQuality - regime,expectations,
acceptance
Agree the PID,Commitnextstage resources
ProjectBoard Take Ownership.
Deliver Authorizationtostartand continue viastage boundary.
- ProjectStatusand Exceptionmanagement
- Re-evaluation,Adhocdirection,guidance,authorisationtoproceed
Coordinationof the work-streams- focusonoutputs,continuedalignment tobusinesscase.Delivery/outcomefocusedstyle–
didactic,taskfocused
SponsorCommunications/Publicity/(LiaisewithProgramme)
Close Ensure effectiveHandingover,stopping,releasing,ending,close out.Ensure lessonscaptured,followonactions captured.
Deal withpeople issuesfromdeliveryacceptance.
Alternatively(derivedfromAssurance andApprovalsforAgile Deliveryof Digital Services - https://www.gov.uk/service-manual/phases:
Stage Characteristic
Discovery A shortphase to start researchingthe needsof the service users,findoutwhatshouldbe measuredandexplore technological
or policy-relatedconstraints.One of the maindifferencesisthe earlyfocusonidentifying high-level requirements,whichare
referredtoas ‘UserNeeds’.

7. Page 7
Alpha A shortphase in whichsolutionsare prototypedtomeetidentifieduserneeds. Testingwithasmall groupof usersor
stakeholdersandgettingearlyfeedbackfeedsintothe designof the service. Developingaprototype providesearlyfeedback,
whichhelpscheckunderstandingof userneedsandtestinitialthinkingaboutsolutiondesign.Oncompletingthe Discovery
and Alphaphases,the teamwill have agoodideaof the services,userneedsandsolutionarchitectureanda planfor‘Beta
intoLive’.
Beta The Beta phase islongerandfocussedondevelopingagainstthe demandsof alive environmentandunderstandinghowto
buildandscale while meetinguserneeds.Thisphase alsoinvolves releasingaversiontotestinpublic.Initially,thismaybe in
the form of a ‘Private Beta’,where the projectcontrolswhocanuse the service byinvitationonlybefore movingtoa‘Public
Beta’,whichisopento all users.Inresource terms,elapsedtime inthe Betaphase isthe largestpartof the life of aservice
before itgoesintofull live operation.
Close The work doesn’tstoponce the service islive. The teamwill iterativelyimprove the service,reactingtonewneedsand
demands,whilstmeetingandexceedingtargetssetduringthe development.
Retirement Eventhe bestserviceseventuallyreachretirementandthisstage shouldbe treatedwiththe same level of care aswas
investedinthe buildingandmaintainingof the service andtransition fromprevioussystems.
Overtime,there are therefore varyingManagement
Informationneedstocoordinate. Forexample:

8. Page 8
In more Agile delivery
domains,the
frameworkcan
accommodate the
Program/Teaminthe
ProjectBoard
concepts.
Traditionally,informationisfoundinITsystems(“Data”),in
words/spreadsheets/presentations(“Documents”) andin
DocuData (“Data” processedata momentintime into
“Documents”)
Informationmanagementandreportingcanbe parochial
and a challenge tooperate/assure qualityover.Hence,
projectscan be difficulttoaggregate intopresentation
formsshareable withportfolios,finance andwider
stakeholdergroups.The answermaybe to implementa
projectmanagementsolutionforthe projectwhichsupports
the entiretyof the projectoperation - butthismay notbe
integratedwithwiderbusinesssystems.Itmaybe
appropriate toadoptcore organisationwiderITsolutions,butthese maynotsupportthe programme effectively(orcreate anoverhead).