UNICEF ERP Next Steps in Planning 3 April

UNICEF ERP Next Steps in Planning 3 April 2008 Michael Spencer 1

Purpose of Presentation n Tasks to be considered in preparing project plan Suggest some Major Milestones for a plan Review some issues and risks related to the plan 2

3

1 Awareness n n Communication Strategy & Plan Stakeholder Analysis Sponsor Identified The Case for Change 4

Communications Strategy n n n n Identify stakeholders Initial meetings with each to raise awareness and explain reasons for a single system Prepare briefing materials for Stakeholders – define broad goals Hold Initial stakeholder meetings – may need field meetings – use existing planned events Explain the governance structures Create meeting schedule for each governance body Identify communications channels to be used (newsletter, emails, meetings, presentations) Hold communications events as necessary 5

Stakeholder Analysis 1 Stakeholder Group Interests Relationship to Implementation Promoters/ Champions People 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 need Contributors of Resources People 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 location People whose work will be affected Will 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 6

Stakeholder Analysis 2 Stakeholder Group Interests Relationship to Implementation Users with accountabilities directly impacted Will 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 reports Those with accountability for delivery of services at regional and country level, maybe in some HQ Divisions (Programme, Supply, DFAM) External beneficiaries Users 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 7

Communications n Consider 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 implementation n Existing regular reporting which may be used to communicate information, plans or achievement, relevant to the project implementation n Think 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 8

Communications n Think 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 community n Individuals 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 9

Communications n You may also need to be realistic about challenges and disadvantages in the deployment and use of the new system n Identify key milestones during implementation which may allow specific events to be staged 10

Sponsor • You may also want to identify a ‘sponsor’ – sponsors ideally have both authority and influence in order ensure project success • A sponsor, for instance, should have the authority to commit the organization’s time, staff, and resources • A sponsor must also be able to influence opinion, to elicit people’s support and cooperation • A sponsor influences stakeholders so that they understand accept the change brought about by the Implementation. 11

Case for Change Why are we doing this project? It is essential to communicate this information broadly 12

Because…. n Interfacing two systems is costly and inefficient and leads to errors n Opportunity to make changes required for other reasons (IPSAS) n Single system for whole organization will reduce training and staff orientation costs and ease mobility of staff n SAP is better because – it is based on best practice n It will make UN Reform/Single UN easier - interoperability n Etc. 13

Exit Criteria Task Deliverable Core Team identified Project Charter Sponsor(s) Identified and Briefed Project Charter Broad Goals/Objectives document produced Project Charter Stakeholders identified and first meeting held Project Charter Kick-Off Meeting High Level Scope identified Project Charter Draft Communications plan made Draft Communications Plan Tentative Governance structure defined Project Charter Decided whether or not to prototype Decision Log/Note of Meeting 14

2 Initiating n n Define Scope Prototyping/Pilot to drive out issues Governance Established User Analysis – decide approach 15

Scope Drivers n Implementing agreed current functionality of Pro. MS n Add improved and changed business processes of Pro. MS n Accommodating the IPSAS requirements n Revision of the accountability framework n Talent and leadership development management n Organizational performance management n UNDAF/One UN/Harmonization n Transition itself may require temporary procedures and functionality 16

Risks around scope n n n Potential scope is very large Scope must be defined before next phase Impossible for all drivers/streams which will be defined later compared to IPSAS deadline for go-live implies early scope freeze, design freeze, development and testing schedule Other streams less mature Management of scope – change happens 17

Resources/Scope n n n Any approved scope needs an estimate of resources needed to implement by proposed deadline n Technical resources needed n Functional resources needed Scope may need to be reviewed if resources available inadequate Quality, on time, on budget – pick any 2 for your defined scope 18

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. 19

Prototype n Conference Room Pilot n n n n Walk through example business processes (with or without application for all steps) Using Paper Prototype/Presentations/System Functional area review Consider conversion strategy - history Identify, discuss & document issues and gaps Resolve issues Escalate issues 20

Governance n n n Project Board Global ERP Manager Implementation Group Field Reference Group IT Team 21

Project Board A 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; 22

Project Manager Global 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; 23

Implementation Group An 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: 24

Implementation Group prepare, 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; 25

Implementation Group Liaise 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; 26

Field Reference Group A 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; 27

IT Team An 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 Pro. MS 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; and • develop and implement a rollout strategy that minimizes business disruption 28

Team Structure Sponsor Project Board Implementation Group Communication Lead Deployment Manager Project Director Change Mgmt Lead Application Architect Field Deployment Group Field Reference Group Finance Functional Lead Admin/Support Quality Assurance Lead QA Team Funds Functional Lead Programme Functional Lead Supply Functional Lead Technical Team HR/Payroll Functional Lead Organizational Performance Functional Lead Key Users in Field, Regions, and HQ 29

User Analysis n Defining the roles that users will perform, which are defined in the Business Process descriptions, and linking these roles to staff positions is key to: n Defining the system steps needed and assists developers n Defining who can do what - security n Is a key element in preparing training materials n Allows estimation of training needs n Helps indicate the impact of proposed changes on staff n This 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 posts n Facilitates discussions with users and owners of Business processes to identify improvements n Licensing needs can be assessed At this point we need to decide how to approach this area – is full business process documentation needed 30

Exit Criteria Task Deliverable Core Team in place Detailed Scope defined Scope Document, Updated Project Charter, Conference Room Pilot completed and documented Full Governance Structure in Place and functioning Project Charter Updated Change Management Activities Identified Change Management Plan Communications Plan further developed Communications Plan updated Communications events completed according to plan Events Log, Note of Meeting Optionally produced a prototype database, conceptual model, example screen shots and distribute it Conceptual Prototype created 31

3 Planning n Plan structure – one or many, linked n n n For example, will technical group maintain their own detailed plan Application Architecture n Making things join up across functional/modules n Impacts design, development and testing activities Human Resources n Will plan have all resource costs n Will we try to estimate time needed/used Other Resources n Are we tracking full cost n SAP used to track actuals Impact of 1 ERP on Regular work of Organization n Possible delays when shared staff need to meet organizational deadlines 32

Planning Streams n n n n Business Processes Training Plan Risk Management Quality Assurance Reports, Interfaces, Conversions, Modifications, Enhancements Technical Infrastructure User Support 33

There are no good project managers - only lucky ones The more you plan the luckier you get 34

Business Processes n Examples of Process maps and descriptions n n n High Level Process Low Level Process Example of User Analysis n User Analysis 35

Business Processes Identifying the business processes which will be needed to collect, enter, validate and distribute data, important for a number of reasons: • It shows who does what • Who is responsible for what • Might help us by showing gaps and missing links in processes • Helps us build a system which meets business needs • Helps avoid conflict and duplication of effort • Helps us know who needs which kind of training • Helps us assign responsibilities to staff and develop job descriptions 36

Business Process Maps/Descriptions • Allows process owners and process experts to be identified • Allows future processes to be designed • Allows As Is processes to be mapped to To Be processes • Allows us to validate the new system designs since we know it supports all existing and necessary business processes • Allows joined up processes, end to end, cross functional and cross module processes to be identified, tested and documented 37

Process Ownership We will need to identify process ownership to get sign off on To Be 38

Training Plan n n n Estimating the target audience is difficult until the business processes and roles are defined The system will change and impact preparation of training materials – training materials development needs to allow for this Geographical 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 needed Timing 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) Language Plan needs to include the project team at an early stage (Initiating) Plan needs to include User Support team 39

Training Plan n Curriculum 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 40

Risk Management Managing 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 occur • Severity and Impact • Susceptibility to control • What the risk may Impact • Which Organisation, unit, partner will be impacted and to what extent • What can be done to avoid or mitigate the risk • How can we measure the status of this risk – estimate the change in key parameters over time • Who 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. 41

A little risk management saves a lot of fan cleaning 42

Quality Assurance n n n QA function strong in IT Division End to end testing – cross module/function Automated if possible Test scripts should be prepared by functional teams These can be based upon business process descriptions and maps Testing by Functional Teams and Key users 43

Custom Development, eg Reports, Interfaces, Conversions • If there are data conversions, new or changed interfaces you need to include this in the plan • In general this is a major area of risk and consumer of resources, especially at testing time • An inventory of reports, Interfaces, data conversions, modifications, enhancements showing sending and receiving systems, formats, estimated complexity, etc for monitoring progress needed • All 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 44

Technical Infrastructure n n Connectivity may impact roll-out This is primarily an issue for ITD but there may be some coordination and resource issues for the Project Manager in certain locations Technical readiness needs to be assessed early in order to plan any upgrades or equipment purchasing Field offices need lead time to get the necessary activities and resources into their budgets – or may be these will be in the HQ budget? 45

Planning for User Support n n n Implications for current Help Desk Functional / Business Support Escalation procedures 46

Establish Team n n n n Accommodation/Co-location? Meeting and Brainstorming space Computers, Servers and other Equipment Working Principles Team Communication Document Repository Document Standards Team Building 47

Exit Criteria 1 Task Deliverable Full Project Office Team in Place Update Project Charter, Contracts or Agreements signed with individuals, supervisors and employers as appropriate Training Plan finalized Training Planned Governance Meetings continuing Meetings Log maintained, all relevant meetings held and recorded Risk Assessment done Risk Assessment document User Support Plan finalized User Support Plan Business Processes documented Business Maps and Descriptions completed Quality Assurance Plan finalized Quality Assurance Plan 48

Exit Criteria 2 Task Deliverable Technical Architecture designed Technical Architecture Plan Communications events completed according to plan Event log maintained Communications Plan Updated Communications Plan amendments approved through governance process Work Plan Completed Work Plan and progress against plan reported 49

4 Design & Development n Controlling Project Work n n n n n Planned and actuals Tracking Issue papers and Issues resolved Change control especially after design freeze Reporting Progress to Board - dashboards Governance Processes Training and Change Management Communication Activities User Support Deployment Plan Development 50

Projects progress rapidly until they are 90 percent complete. Then they remain 90 percent complete forever 51

Team Tasks n Functional Team n n n Technical Team n n Business processes As Is Work with functional units and get sign off on To Be Prepare Functional Designs for To Be, conversions, enhancements, modifications, reports Prepare Position Papers on Issues, Propose solution for Gaps Test scripts Technical Designs for all Functional Designs, signed-off Development Unit Tests Key Users n Integration testing 52

Team Issues 1 n Work will be undertaken in many units across the organization – how will project wide planning and progress reporting be undertaken, evaluate performance, handle dual reporting? n Do we have established project management approaches, strategies, standards and procedures? Should we try to standardise these across team n How are we measuring progress, monitoring and reporting? n Time reporting – in some environments this is a key to measuring resource usage and work, done but it somewhat against the cultures of the UN n We 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? 53

Team Issues 2 n What software 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 commitments n How will the team communicate, schedule meetings, share information – is there a common system/platform for this? n How will the manager handle under performing staff, not necessarily reporting directly to him? n 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 54

Design and Build n Standards for n n n n Business process maps and descriptions specifying design – templates for functional designs for technical design Issue documentation and issue papers Integration Application Architecture Sign off for all documents Design Freeze Change control thereafter 55

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. " 56

Training n Functional Team need to be trained before or during design phase n Training Materials will be produced during this phase n Challenging in an environment where design changes may occur and technical development is not complete n Could delay start to after design freeze n Well documented business processes are useful for development of training materials n IT Staff in the field may need to be trained in this phase n Technical and Functional Support need training both in issue escalation and tracking and system 57

Exit Criteria Task Deliverable Work Plan regularly monitored and updated Work Plan updated, progress reports produced according to agreed schedule All Plan Activities completed on schedule System ready for release Planned Governance Meetings continuing Meeting Log updated, meetings held and recorded according to plan User Support infrastructure ready User Support open for business Technical Architecture tested and ready for deployment Technical Readiness Criteria Communications events completed according to plan Events log updated, Events held according to schedule Training materials completed Help staff trained Functional Readiness Criteria Trained support staff Communications Plan Updated Communications Plan authorized by Board Deployment Plan finalized Deployment Plan signed off by Board 58

5 Deployment n Test Run or not (Jakarta for Pro. MS 1997) n Pro. MS rolled out to 168 field locations in 22 months n There are complex relationships between field offices n Phased release or big bang n Closed Pilot, Open Pilot and Release to production n All of this takes time with high probability of delay n Avoid parallel running of two systems during deployment n Coordinate training delivery with go-live office by office 59

Issues n n n Do 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 points There is a natural tendency to re-invent the status quo Managing Up to Board – facilitate decision making and document implications of decisions 60

http: //michaelspencer. home. att. net 61