Plan for Success or Plan to Survive

1
Plan for Success or Plan to Survive?

• Darcia Pope
• Regional Director, IMIS Enterprise Services

2
Three Lessons Learned

• Projects where plans
• Are designed only for survival are not successful
• Begin with the end in mind will result in better
  organizational benefits
• Integrate project management and change
  management methodology are more effective

Over 70 of major change projects fail to fully
deliver the desired results
3
Agenda

• RBS project background
• What is planning for survival?
• What is planning with the end in mind?
• Why an integrated approach?
• Lessons learned
• Questions

4
Regional Business Systems Mandate

• A single business system solution that will
  enable the ability to improve business processes
  and better leverage our people in order to
  deliver quality care

People
Business
RBS
Technology
5
Why a Single Business System Solution?

• Increasing requirements for common business
  practices and consolidated information
• Health region consolidated
• Inadequate business systems
• Varied and duplicate processes
• Limited consolidated reporting

6
Unique Multi Authority Partnership

• Joint licensing with PeopleSoft across
  authorities
• Created immediate opportunities to
• Collaborate to develop and implement PeopleSoft
• Integrate best practices into a shared work
  product
• Leverage experience / expertise with a shared
  project structure
• Foundation for longer term opportunities
• Enhance partnership processes
• Invest together in other IT initiatives
• Increased ability to evolve with changes in
  health care
• Partner with other Health Authorities

7
RBS Scope
PeopleSoft
ESP and Procura Upgrade Loki Implementation

Finance 8.4
AccountsPayable
SCM 8.4
HCM 8.3
Inventory
GeneralLedger
HumanResources
Payroll
SystemModules
HumanResources
Payroll
Time Capture
Time Capture
Purchasing
Asset Mgmt
ePro
8
Shared Development Phased Go Lives
9
What is Planning for Survival?

• Planning where the focus emphasizes
• Being on time and on budget rather than quality
• Completing tasks on time rather than focusing on
  impact.
• The use of external resources as pair of hands
  rather than as mentors to develop internal
  capability

10
On Time on Budget

• Most projects begin with defined drivers, a
  budget and target completion dates
• Our project plans and resource strategies were
  developed to meet these requirements
• We leveraged internal people where possible
• Strategies were influenced by what we could
  afford
• Timelines were based on burn rate
• Constant scope management required as new
  organizational requirements were identified

11
Completing Tasks First Priority

• Our tight timelines and fixed budgets influenced
  our strategies
• Focus on product development
• Rigid testing cycles and sign off deadlines
• Higher tolerance to go live with testing issues
• Limited impact assessment, consultation and
  communication with users
• Reluctance to involve specialists (i.e. trainers)
• Issue resolution and decision making were
  influenced by deadlines rather than by impact
• Limited rigor assessing readiness

12
Pair of Hands

• We tried to recruit the best in the
  organization to participate in the project
• As subject matter experts and process owners
• Limited technical resources due to concurrent
  initiatives
• Unable to recruit internal change agents or
  experts
• Internals pulled between project and operations
• We had limited experience implementing large IT
  project
• Therefore, relied heavily on external resources
  with extensive experience, but mostly in a
  tactical role
• Minimal opportunities or strategies for knowledge
  transfer
• Significant costs associated with externals

13
What is Planning with the End in Mind?
Optimization
P RODUCT IVI TY
Organizational Readiness
Stabilization

Current State
Go-Live
TIME
14
Why Plan with the End in Mind?

• Clearly defined and accepted success criteria
  will determine
• Strategies for recruiting resources
• Degree of change management
• Required timelines and finances
• Issue resolution and decision making processes
• Acceptance and sign off processes
• Partnership guidelines
• Will maximize collaboration, efficiency, and
  quality

15
Planning for Go Live

• Some Typical Strategies
• Communicate end state and project plans/progress
• Train users on how to use the system
• Ensure effective project management
• Sponsors oversee project plans and issues
• Provide project support post go live
• Probable Results
• Drop in productivity with eventual return to
  current state levels

16
Planning for Stabilization

• Some Typical Strategies
• Understand and document business process gaps
  between current state and end state
• Involve stakeholder to create gap solutions
• Test gap solutions in parallel testing
• Include gap solutions (process/roles) in training
  
• Involve users in testing, training, and support
• Probable Results
• Increased willingness and ownership to address
  issues and stabilize system and operations

17
Planning for Optimization

• Some Typical Strategies
• Integrate systems with optimal processes
• Take time to align organization with new
  processes
• Train people to use the system in support of
  optimal processes
• Develop internal expertise to implement and
  maintain the optimal processes
• Align sponsorship to optimal end state
• Probable Results
• Final productivity will exceed current level

18
Why an Integrated Approach?

• Project management and change management need to
  be integrated to ensure
• Project activities are executed in a way that
  build stakeholder support (i.e. users involved in
  testing)
• Systems and processes are aligned
• Project plans align with organizational
  priorities
• Any new requirements are appropriately planned
  for
• Ownership is defined and reinforced at all stages
• There is high user and stakeholder acceptance of
  the plans, product, processes and end state

19
Integrated Implementation Approach
Project Initiation Vision, funding, sponsorship,
scope, strategies, plans, people
Sustainment Stabilization, optimization
Project Execution Design, development, testing,
conversion, support
20
Project Initiation Lessons Learned

• Clearly define success criteria, vision,
  strategies and boundaries
• Assess and build leader support for end state
  before launching project
• Recruit internal project resources based on
  sustainment structure
• Ensure plans in place for increasing internal
  capability
• Recruit sponsors by stakeholder group not just
  functional area
• Ensure adequate funding and time for all
  strategies, including user involvement, process
  mapping, knowledge transfer

21
Project Execution Lessons Learned

• Ensure project management team is committed to an
  integrated approach
• Actively involve users in design, testing,
  training, communication, issue identification /
  resolution, and support
• Assess risks and readiness continuously using
  various means
• Reinforce defined responsibilities for decision
  making, sign off, performance management through
  PM processes
• Use face to face communication supported by
  print, web, etc
• Develop hands-on integrated training linked
  to post go live support mechanisms

22
Sustainment Lessons Learned

• Develop and test key sustainment processes during
  project execution (i.e. maintenance of training
  or of key tables)
• Define key metrics and means for measuring post
  go live stabilization
• Ensure funding and plans in place to support any
  out of scope work
• Manage retention of knowledge and key resources
  at all stages of the project
• Begin transition to sustainment early
• Assess lessons and ensure they influence future
  projects

23
In Closing

• My new role provides an opportunity to ensure the
  lessons learned are applied to future projects
• Enterprise Services allows for coordination and
  integration between project initiation, project
  management, and change management
• Ultimately, we strive to plan and implement
  projects for long term success, not short term
  survival

24
Questions