Michael Spencer 13 April 2008

UNICEF ERP

Next Steps in Planning

2

Purpose of Presentation

Tasks to be considered in preparing project plan

Suggest some Major Milestones for a plan

Review some issues and risks related to the plan

3

4

1 Awareness

Communication Strategy & Plan Stakeholder Analysis Sponsor Identified The Case for Change

5

Communications Strategy

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

6

Stakeholder Analysis 1Stakeholder

GroupInterests 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

7

Stakeholder Analysis 2

StakeholderGroup

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

8

Communications 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

Existing regular reporting which may be used to communicate

information, plans or achievement, relevant to the project

implementation

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

9

Communications 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

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

10

Communications You may also need to be realistic about challenges and

disadvantages in the deployment and use of the new system

Identify key milestones during implementation which may allow

specific events to be staged

11

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 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 errors

Opportunity to make changes required for other reasons

(IPSAS)

Single system for whole organization will reduce training

and staff orientation costs and ease mobility of staff

SAP is better because – it is based on best practice

It will make UN Reform/Single UN easier - interoperability

Etc.

14

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 CharterKick-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

15

2 Initiating

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

16

Scope Drivers

Implementing agreed current functionality of ProMS

Add improved and changed business processes of ProMS

Accommodating the IPSAS requirements Revision of the accountability framework Talent and leadership development management Organizational performance management UNDAF/One UN/Harmonization Transition itself may require temporary

procedures and functionality

17

Risks around scope

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 IPSAS deadline for go-live implies early scope

freeze, design freeze, development and testing schedule

Other streams less mature Management of scope – change happens

18

Resources/Scope

Any approved scope needs an estimate of resources needed to implement by proposed deadline

Technical resources needed

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

19

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/System Functional area review Consider conversion strategy - history Identify, discuss & document issues and gaps Resolve issues Escalate issues

21

Governance

Project Board Global ERP Manager Implementation Group Field Reference Group IT Team

22

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;

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 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:

25

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;

26

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;

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 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 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; and • develop and implement a rollout strategy that minimizes business

disruption

29

Team StructureSponsor

Project Board

Project Director Admin/SupportImplementation Group

Deployment

Manager

Application

Architect

TechnicalLead

ChangeMgmt Lead

QualityAssurance

Lead

FieldReference

Group

FinanceFunctiona

lLead

FundsFunctional

Lead

ProgrammeFunctional

Lead

SupplyFunctional

Lead

HR/PayrollFunctional

Lead

Key Users in Field, Regions, and HQ

OrganizationalPerformanceFunctional

Lead

TechnicalTeamQA TeamField

Deployment

Group

Communication

Lead

30

User Analysis 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: Defining the system steps needed and assists developers

Defining who can do what - security

Is a key element in preparing training materials

Allows estimation of training needs

Helps indicate the impact of proposed changes on staff

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

Facilitates discussions with users and owners of Business processes to

identify improvements

Licensing needs can be assessedAt this point we need to decide how to approach this area – is full business process documentation needed

31

Exit CriteriaTask 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

32

3 Planning Plan structure – one or many, linked

For example, will technical group maintain their own detailed plan

Application Architecture Making things join up across functional/modules Impacts design, development and testing activities

Human Resources Will plan have all resource costs Will we try to estimate time needed/used

Other Resources Are we tracking full cost SAP used to track actuals

Impact of 1ERP on Regular work of Organization Possible delays when shared staff need to meet organizational

deadlines

33

Planning Streams

Business Processes Training Plan Risk Management Quality Assurance Reports, Interfaces, Conversions,

Modifications, Enhancements Technical Infrastructure User Support

34

There are no good project managers - only lucky onesThe more you plan the luckier you get

35

Business Processes

Examples of Process maps and descriptions

High Level Process Low Level Process

Example of User Analysis User Analysis

36

Business Processes

• 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

Identifying the business processes which will be needed to collect, enter, validate and distribute data, important for a number of reasons:

37

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

38

Process Ownership

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

39

Training Plan

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

40

Training Plan

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

41

Risk Management

• 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

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:

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

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/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

44

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

45

Technical Infrastructure

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?

46

Planning for User Support

Implications for current Help Desk Functional / Business Support Escalation procedures

47

Establish Team

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

48

Exit Criteria 1Task 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 Plan

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

49

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

50

4 Design & Development

Controlling Project Work 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

51

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

forever

52

Team Tasks

Functional Team 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 Team Technical Designs for all Functional Designs, signed-off Development Unit Tests

Key Users Integration testing

53

Team Issues 1

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?

Do we have established project management approaches, strategies, standards and procedures? Should we try to standardise these across team

How 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 UN

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?

54

Team Issues 2

What 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 commitments

How 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 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

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

Training

Functional Team need to be trained before or during design phase

Training Materials will be produced during this phase Challenging in an environment where design changes may

occur and technical development is not complete Could delay start to after design freeze Well documented business processes are useful for

development of training materials IT Staff in the field may need to be trained in this phase Technical and Functional Support need training both in issue

escalation and tracking and system

58

Exit CriteriaTask 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 completedHelp staff trained

Functional Readiness CriteriaTrained support staff

Communications Plan Updated Communications Plan authorized by Board

Deployment Plan finalized Deployment 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

months There are complex relationships between field

offices Phased release or big bang Closed Pilot, Open Pilot and Release to production All of this takes time with high probability of delay Avoid parallel running of two systems during

deployment Coordinate training delivery with go-live office by

office

60

Issues

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

61

http://michaelspencer.home.att.net