4 1 Awareness Communication Strategy & Plan Stakeholder Analysis Sponsor IdentifiedThe Case for Change
5 Communications Strategy Identify stakeholdersInitial meetings with each to raise awareness and explain reasons for a single systemPrepare briefing materials for Stakeholders – define broad goalsHold Initial stakeholder meetings – may need field meetings – use existing planned eventsExplain the governance structuresCreate meeting schedule for each governance bodyIdentify communications channels to be used (newsletter, s, meetings, presentations)Hold communications events as necessary
6 Stakeholder Analysis 1 Stakeholder Group Interests Relationship to ImplementationPromoters/ChampionsPeople who may have been instrumental in initiating the implementation, are convinced of the need and the benefits of the implementation, may have strong ideas about the solution, and have a strong interest in the successful outcome.Should be active in the establishment of the need for the project, will already understand the business needContributors of ResourcesPeople who may themselves be potential implementation resources or who are managers of units providing implementation resources, and are likely to be concerned with balancing implementation needs against the need to continue their normal work and meet their unit’s deadlines. This group are likely to have a need to define exact timing of commitments and the amount of time their staff are needed for implementation activities as well as for training. Are likely to demand detailed reporting of status and plans, and future resource needs. A staff involvement matrix could be prepared to show who will be involved and when as a means of dealing with concerns of this group.Units impacted by the implementation, may be in field office/regional/HQ locationPeople whose work will be affectedWill have hopes and fears about the impact of the implementation, may have concerns about alignment of The system with existing systems, will be concerned with the amount their role will change and how fast it will change. Should be targeted the communication plan.Not necessarily directly concerned with the implementation, except indirectly, may be future users, as providers of data or users of information, will be in all field locations and some HQ
7 Stakeholder Analysis 2 Stakeholder Group Interests Relationship to ImplementationUsers with accountabilities directly impactedWill be concerned with their ability to understand the issues around the implementation and will have larger picture and strategic issues in mind, will be particularly concerned with possible disruption to staff work loads, normal operations, and budgets. Will be concerned with risk of failure and ineffective use of funds, may be sceptical of technology centric projects. Will need regular status reports, plan updates and implementation management reportsThose with accountability for delivery of services at regional and country level, maybe in some HQ Divisions (Programme, Supply, DFAM)External beneficiariesUsers of the products of system. May include people with expectations about the contribution of the implementation to broader organisational goals at Global or regional level, such as UN reform.UN HQ, Regional Offices having expectations about reporting, Donors, those preparing donor reports and managing donor relations
8 CommunicationsConsider an event which can be used to provide orientation to stakeholders with a simulation of use of the system – stepping through some realistic scenarios with data constructed for the purpose or borrowed from another implementationExisting regular reporting which may be used to communicate information, plans or achievement, relevant to the project implementationThink about internal communication within the team to keep them aware of progress and issues and organise events as appropriate – you may need to standardize on the tools used – it needs to include the field members of the team
9 CommunicationsThink About use of Change Agents/Leaders - these are people within the broader user community who may have special interest in the system and the purpose of the implementation, who could be a means of communication between the Project Team and the user communityIndividuals or groups affected by the implementation since they play an important role in the achieving implementation and then sustaining the system and thus the success of an implementation. The Communication strategy should clarify myths and misconceptions and reduce fear and anxiety toward the new system in this community
10 CommunicationsYou may also need to be realistic about challenges and disadvantages in the deployment and use of the new systemIdentify key milestones during implementation which may allow specific events to be staged
11 SponsorYou may also want to identify a ‘sponsor’ – sponsors ideally have both authority and influence in order ensure project successA sponsor, for instance, should have the authority to commit the organization’s time, staff, and resourcesA sponsor must also be able to influence opinion, to elicit people’s support and cooperationA sponsor influences stakeholders so that they understand and accept the change brought about by the Implementation.
12 Case for Change Why are we doing this project? It is essential to communicate this information broadly
13 Because….Interfacing two systems is costly and inefficient and leads to errorsOpportunity to make changes required for other reasons (IPSAS)Single system for whole organization will reduce training and staff orientation costs and ease mobility of staffSAP is better because – it is based on best practiceIt will make UN Reform/Single UN easier - interoperabilityEtc.
14 Exit Criteria Task Deliverable Core Team identified Project Charter Sponsor(s) Identified and BriefedBroad Goals/Objectives document producedStakeholders identified and first meeting heldKick-Off MeetingHigh Level Scope identifiedDraft Communications plan madeDraft Communications PlanTentative Governance structure definedDecided whether or not to prototypeDecision Log/Note of Meeting
15 2 Initiating Define Scope Prototyping/Pilot to drive out issues Governance EstablishedUser Analysis – decide approach
16 Scope Drivers Implementing agreed current functionality of ProMS Add improved and changed business processes of ProMSAccommodating the IPSAS requirementsRevision of the accountability frameworkTalent and leadership development managementOrganizational performance managementUNDAF/One UN/HarmonizationTransition itself may require temporary procedures and functionality
17 Risks around scope Potential scope is very large Scope must be defined before next phaseImpossible for all drivers/streams which will be defined later compared to IPSASIPSAS deadline for go-live implies early scope freeze, design freeze, development and testing scheduleOther streams less matureManagement of scope – change happens
18 Resources/ScopeAny approved scope needs an estimate of resources needed to implement by proposed deadlineTechnical resources neededFunctional resources neededScope may need to be reviewed if resources available inadequateQuality, on time, on budget – pick any 2 for your defined scope
19 To the project manager, the glass is twice as big as it needs to be. To the optimist, the glass is half full. To the pessimist, the glass is half empty.To the project manager, the glass is twice as big as it needs to be.
20 Prototype Conference Room Pilot Walk through example business processes (with or without application for all steps)Using Paper Prototype/Presentations/SystemFunctional area reviewConsider conversion strategy - historyIdentify, discuss & document issues and gapsResolve issuesEscalate issues
21 Governance Project Board Global ERP Manager Implementation Group Field Reference GroupIT Team
22 Project BoardA Project Board consisting of the following Directors – PD, DPP, DFAM, ITD, DHR, Supply, PARMO, and CMU – will be established and chaired by Deputy Executive Director. The terms of reference of the project board will be to authorize the ERP work plan and budget; manage the overall progress on the implementation of the ERP work plan through monthly review meetings; and make business decisions based on the recommendations of the Implementation Group;
23 Project ManagerGlobal ERP Project Manager who will work closely with senior management to determine the scope and business requirements of the single application ERP that meets the needs of all stakeholders, including field offices, regions and headquarters.This person will be responsible for overall project implementation, including management of the budget and work plan. As chair of the Project Implementation Group, he will also liaise with the project managers of other UNICEF projects and initiatives that impact the single ERP to ensure their activities are coordinated and their requirements are incorporated, while not adversely affecting the global rollout plan.The project manager will also conduct workshops; manage the governance process; devise the implementation and rollout plan; coordinate the communications and training strategy; and manage the risk management plan;
24 Implementation GroupAn Implementation Group consisting of the following Deputy Directors - PD, DPP, DFAM, ITD, DHR, Supply, PARMO, and OIA – will be established. It will be chaired by the ERP manager and will report to the Project Board. The terms of reference of the Implementation Group will be to:
25 Implementation Groupprepare, in consultation with the field reference group and the IT team, a two year work plan and budget to roll out SAP as the "One" ERP application, based on agreement from each of the business users (programme, finance, supply, human resources, funds management, reporting) on what will be included in each of their respective modules in SAP;once authorized by the Project Board, implement the work plan by working closely with the field reference group and the IT team to make sure that each of the component SAP modules, within the "One" ERP application, responds to the needs of UNICEF globally and supports the delivery of results for children;
26 Implementation GroupLiaise with the Project Board set up to drive the other key initiatives on organizational change to ensure that where possible the outputs from these boards are included in the design of the SAP modules;work closely with the Organizational Learning and Development Section (OLDS), the field reference group, and the IT team in the development and rollout of training materials;
27 Field Reference GroupA Field Reference Group consisting of members of each of the business users –programme, finance, information technology, human resources, supply, and funds management – will be established to work closely with the Implementation Group. The terms of reference of the Field Reference Group will be to:help the Implementation Group to prepare the work plan and budget so that the needs of all users are incorporated into the "One" ERP application;work with the Implementation Group to make sure that the work plan is implemented by providing inputs into the module designs and providing feedback as the modules are developed;support the rollout of SAP to the country offices;
28 IT TeamAn IT Team led by the SAP managers and consisting of the systems and programme analysts will:devise a systems development methodology and work plan;design and customize the SAP modules based on the requirements of the business users in accordance with an integrated work plan;conduct thorough system and integrated testing;ensure ProMS and reporting requirements remain aligned with SAP during the rollout process;architect, build and test the hardware and telecommunications infrastructure required to ensure adequate system performance for SAP business users worldwide;devise and implement a robust disaster recovery plan; anddevelop and implement a rollout strategy that minimizes business disruption
29 Key Users in Field, Regions, and HQ Team StructureSponsorProject BoardImplementation GroupProject DirectorAdmin/SupportCommunicationLeadDeploymentManagerChangeMgmt LeadApplicationArchitectQualityAssuranceLeadTechnicalLeadTechnicalTeamField DeploymentGroupQA TeamFieldReferenceGroupFinanceFunctionalLeadFundsFunctionalLeadProgrammeFunctionalLeadSupplyFunctionalLeadHR/PayrollFunctionalLeadOrganizationalPerformanceFunctionalLeadKey Users in Field, Regions, and HQ
30 User AnalysisDefining the roles that users will perform, which are defined in the Business Process descriptions, and linking these roles to staff positions is key to:Defining the system steps needed and assists developersDefining who can do what - securityIs a key element in preparing training materialsAllows estimation of training needsHelps indicate the impact of proposed changes on staffThis may be done by means of the business process descriptions to give us a list of the roles that must be performed, map the roles onto individual users or postsFacilitates discussions with users and owners of Business processes to identify improvementsLicensing needs can be assessedAt this point we need to decide how to approach this area – is full business process documentation needed
31 Exit Criteria Task Deliverable Core Team in place Detailed Scope definedScope Document, Updated Project Charter, Conference Room Pilot completed and documentedFull Governance Structure in Place and functioningProject Charter UpdatedChange Management Activities IdentifiedChange Management PlanCommunications Plan further developedCommunications Plan updatedCommunications events completed according to planEvents Log, Note of MeetingOptionally produced a prototype database, conceptual model, example screen shots and distribute itConceptual Prototype created
32 3 Planning Plan structure – one or many, linked For example, will technical group maintain their own detailed planApplication ArchitectureMaking things join up across functional/modulesImpacts design, development and testing activitiesHuman ResourcesWill plan have all resource costsWill we try to estimate time needed/usedOther ResourcesAre we tracking full costSAP used to track actualsImpact of 1ERP on Regular work of OrganizationPossible delays when shared staff need to meet organizational deadlines
33 Planning Streams Business Processes Training Plan Risk Management Quality AssuranceReports, Interfaces, Conversions, Modifications, EnhancementsTechnical InfrastructureUser Support
34 There are no good project managers - only lucky ones The more you plan the luckier you get
35 Business Processes Examples of Process maps and descriptions High Level ProcessLow Level ProcessExample of User AnalysisUser Analysis
36 Business ProcessesIdentifying the business processes which will be needed to collect, enter, validate and distribute data, important for a number of reasons:It shows who does whatWho is responsible for whatMight help us by showing gaps and missing links in processesHelps us build a system which meets business needsHelps avoid conflict and duplication of effortHelps us know who needs which kind of trainingHelps us assign responsibilities to staff and develop job descriptions
37 Business Process Maps/Descriptions Allows process owners and process experts to be identifiedAllows future processes to be designedAllows As Is processes to be mapped to To Be processesAllows us to validate the new system designs since we know it supportsall existing and necessary business processesAllows joined up processes, end to end, cross functional and crossmodule processes to be identified, tested and documented
38 Process OwnershipWe will need to identify process ownership to get sign off on To Be
39 Training PlanEstimating the target audience is difficult until the business processes and roles are definedThe system will change and impact preparation of training materials – training materials development needs to allow for thisGeographical spread of users – how do your ensure quality, organize logistics, recruit and obtain release of local talent, coordinate training with other activities and events (Roll Out Manager may be neededTiming of training in a phased roll-out (it should be near to go-live, there may be delays, changes during roll-out, which will impact training materials and delivery)LanguagePlan needs to include the project team at an early stage (Initiating)Plan needs to include User Support team
40 Training PlanCurriculum and scheduling – complex with phased roll-out with many roles performed by some staff – who needs which training, minimising duplication, groups training subjects around staff needs rather than simply mapping them to roles (staff perform many roles)Materials and media – need to explore strategies (Computer based, web based, e-learning, classroom, self-guided, etc.)Time and Resources – staff and offices are usually expected to seamlessly accommodate training with no impact on programme delivery; they may be expected to provider trainers
41 Risk ManagementManaging risk is the Project Managers responsibility. A risk is not a problem: a problem is a situation that has already occurred; a risk is the recognition that a problem might occur. By recognizing potential problems, the management can attempt to avoid or minimize a problem through proper actions. The key characteristics of Risks are:Probability that they will occurSeverity and ImpactSusceptibility to controlWhat the risk may ImpactWhich Organisation, unit, partner will be impacted and to what extentWhat can be done to avoid or mitigate the riskHow can we measure the status of this risk – estimate the change in key parameters over timeWho is the primary responsible person for managing this risk to mitigate risk(s)?A Risk watch list should be created and maintained by the Project Office.
42 A little risk management saves a lot of fan cleaning
43 Quality Assurance QA function strong in IT Division End to end testing – cross module/functionAutomated if possibleTest scripts should be prepared by functional teamsThese can be based upon business process descriptions and mapsTesting by Functional Teams and Key users
44 Custom Development, eg Reports, Interfaces, Conversions If there are data conversions, new or changed interfaces you need to include this in the planIn general this is a major area of risk and consumer of resources, especially at testing timeAn inventory of reports, Interfaces, data conversions, modifications, enhancements showing sending and receiving systems, formats, estimated complexity, etc for monitoring progress neededAll the relevant activities need to built into the project and test plans. The design, development and testing of the related functions and interfaces will involve technical, functional and key users
45 Technical Infrastructure Connectivity may impact roll-outThis is primarily an issue for ITD but there may be some coordination and resource issues for the Project Manager in certain locationsTechnical readiness needs to be assessed early in order to plan any upgrades or equipment purchasingField offices need lead time to get the necessary activities and resources into their budgets – or may be these will be in the HQ budget?
46 Planning for User Support Implications for current Help DeskFunctional / Business SupportEscalation procedures
47 Establish Team Accommodation/Co-location? Meeting and Brainstorming spaceComputers, Servers and other EquipmentWorking PrinciplesTeam CommunicationDocument RepositoryDocument StandardsTeam Building
48 Exit Criteria 1 Task Deliverable Full Project Office Team in Place Update Project Charter, Contracts or Agreements signed with individuals, supervisors and employers as appropriateTraining Plan finalizedTraining PlanPlanned Governance Meetings continuingMeetings Log maintained, all relevant meetings held and recordedRisk Assessment doneRisk Assessment documentUser Support Plan finalizedUser Support PlanBusiness Processes documentedBusiness Maps and Descriptions completedQuality Assurance Plan finalizedQuality Assurance Plan
49 Exit Criteria 2 Task Deliverable Technical Architecture designed Technical Architecture PlanCommunications events completed according to planEvent log maintainedCommunications Plan UpdatedCommunications Plan amendments approved through governance processWork Plan CompletedWork Plan and progress against plan reported
50 4 Design & Development Controlling Project Work Governance Processes Planned and actualsTracking Issue papers and Issues resolvedChange control especially after design freezeReporting Progress to Board - dashboardsGovernance ProcessesTraining and Change ManagementCommunication ActivitiesUser SupportDeployment Plan Development
51 Projects progress rapidly until they are 90 percent complete Projects progress rapidly until they are 90 percent complete. Then they remain 90 percent complete forever
52 Team Tasks Functional Team Technical Team Key Users Business processes As IsWork with functional units and get sign off on To BePrepare Functional Designs for To Be, conversions, enhancements, modifications, reportsPrepare Position Papers on Issues, Propose solution for GapsTest scriptsTechnical TeamTechnical Designs for all Functional Designs, signed-offDevelopmentUnit TestsKey UsersIntegration testing
53 Team Issues 1Work will be undertaken in many units across the organization – how will project wide planning and progress reporting be undertaken, evaluate performance, handle dual reporting?Do we have established project management approaches, strategies, standards and procedures? Should we try to standardise these across teamHow are we measuring progress, monitoring and reporting?Time reporting – in some environments this is a key to measuring resource usage and work, done but it somewhat against the cultures of the UNWe are likely to accumulate a large number of documents. How will we manage the repository of documents/information/data developed throughout the life of the implementation? Are there any common standards or technical solutions?
54 Team Issues 2What software are we using for project management? How does it relate to institutional systems that may also contain some work plans (SAP) which need to reflect relevant budgetary commitmentsHow will the team communicate, schedule meetings, share information – is there a common system/platform for this?How will the manager handle under performing staff, not necessarily reporting directly to him?Are there issues of reward and bonus payments, means of encouraging team members in non-financial ways and particularly where staff already have other assigned tasks
55 Design and Build Standards for Integration Application Architecture Business process maps and descriptionsspecifying design – templates for functional designsfor technical designIssue documentation and issue papersIntegration Application ArchitectureSign off for all documentsDesign FreezeChange control thereafter
56 The first 90 percent of a project schedule takes 90 percent of the time. The last 10 percent takes the other 90 percent of the time."
57 TrainingFunctional Team need to be trained before or during design phaseTraining Materials will be produced during this phaseChallenging in an environment where design changes may occur and technical development is not completeCould delay start to after design freezeWell documented business processes are useful for development of training materialsIT Staff in the field may need to be trained in this phaseTechnical and Functional Support need training both in issue escalation and tracking and system
58 Exit Criteria Task Deliverable Work Plan regularly monitored and updatedWork Plan updated, progress reports produced according to agreed scheduleAll Plan Activities completed on scheduleSystem ready for releasePlanned Governance Meetings continuingMeeting Log updated, meetings held and recorded according to planUser Support infrastructure readyUser Support open for businessTechnical Architecture tested and ready for deploymentTechnical Readiness CriteriaCommunications events completed according to planEvents log updated, Events held according to scheduleTraining materials completedHelp staff trainedFunctional Readiness CriteriaTrained support staffCommunications Plan UpdatedCommunications Plan authorized by BoardDeployment Plan finalizedDeployment Plan signed off by Board
59 5 Deployment Test Run or not (Jakarta for ProMS 1997) ProMS rolled out to 168 field locations in 22 monthsThere are complex relationships between field officesPhased release or big bangClosed Pilot, Open Pilot and Release to productionAll of this takes time with high probability of delayAvoid parallel running of two systems during deploymentCoordinate training delivery with go-live office by office
60 IssuesDo not underestimate resistance to change (organizational culture, personal, group)Manage manifestation of resistance (demotivated staff, lack of engagement, missed deadlines, sabotage)Avoid diluting high level decisions when low level detail is defined during design and discussion with staff identified by business owners as focal pointsThere is a natural tendency to re-invent the status quoManaging Up to Board – facilitate decision making and document implications of decisions