Lessons Learned in Maine Technology Projects

1
Lessons Learned in Maine Technology Projects

• Jim Lopatosky
• Information Technology Director
• Health and Human Services
• Maine State Government

2
Avoiding Pitfalls in IT Projects

• Focuses on Maines MMIS Implementation
• In reality, these problems have occurred in other
  projects as well, including smaller efforts.
• Challenges and opportunities are very similar.
• Size (scope, budget) and Visibility bring the
  problem initiatives to the forefront.

3
MMIS - Out with the old

• Why something new? Legacy does not mean forever
  more. The system was
• Based upon 30 year old business practices.
• Based upon almost 30 year old data requirements.
• Used 30 year old technology (Cobol68).
• Couldnt modify for areas like HIPAA Compliance
  without major rewriting.

4
And in with the new

• Basic timeline
• Aug 2001 MMIS development and IVV contracts
  awarded
• Aug 2002 - MMIS development contract amended with
  scope and schedule changes (larger and longer).
• Jun 2003 and Apr 2004 - More contract changes.
• Early Jan 2005 IVV vendor released.
• Late Jan 2005 Partial Implementation, claims
  trickle through
• Feb 2005 Interim Payments begin
• Apr 2005 Governor demands action, CIO named
  owner of the project (start of IT Consolidation)
• Jun 2005 New leadership assumes responsibility
  for project recovery (including yours truly as
  first agency IT director in new OIT)

5
Some of the impact

• Backlog of suspended claims was at over five
  times the normal weekly processing.
• Interim payments over half a billion dollars.
• Adjudication rates around fifty percent.
• Poor information to providers on paid claims
  (RAs).
• Still not HIPAA compliant.
• Of course, the States and the provider
  communitys frustration level had peaked.

6
Thinking back

• Opportunities missed in many areas
• Non-Technology
• Leadership and Direction
• Project Management
• Partnership between Business and IT
• Collaboration, Coordination, and Communication
• Technology
• System Development
• Scope Management
• Testing
• Implementation Choices
• And more ?
• But, we learned

7
Leadership and Direction

• First and foremost, set the tone that openness
  and honesty are key.
• Dont be afraid to hear the ugly truths.
• Cannot address what isnt real.
• Listen to the team. Decisions were made without
  accurate information.
• Ensure that leadership is not pulled into the
  weeds or details. Often, they lose sight of
  direction. This includes the IVV vendor.
• Regular project assessments necessary
• Step back to get the overall picture. Adjust
  course as necessary.
• Fittingly, we use the analogy of a trip to
  California.

8
Disciplined Project Management

• Skills were available (in house or rented)
• Competing pressures replaced the disciplined
  approach to use this tool, this practice
• Actions
• Established overall PMO
• Rebuilt project work-plans
• Established better issues and risk management
  tactics

9
Business and IT Partnership

• This relationship is crucial. Think about it
• Is there an IT decision that doesnt have a
  business impact?
• Is there a business decision that doesnt have an
  IT impact.
• Through this project (and others), the most
  successful are those where both business and IT
  stay engaged.
• Steering Committees are more than informational.
  These should be forums for discussing barriers
  and issues, and potentially direction changes.
• Important by product - the project teams will not
  feel abandoned. Rather, they feel supported.

10
Collaboration, Coordination, and Communication
(3 Cs)

• Teams were working hard, 100mph
• Duplicate efforts, hard getting responses out of
  people.
• Teams were too much into the details.
• Actions
• (New) PMO Coordinated all major activities.
• Get the right people in the room to solve
  problems.
• Application Helpdesk created as a relief valve
  for problems tracking.

11
more on the 3 Cs

• As a result of getting better at Collaberation,
  Coordination, and Communication, a fourth C
  surfaced
• Contention
• (Limited) subject matter experts were often
  pulled into multiple directions, requiring better
  coordination (and communication)
• Developed a program where SMEs would mentor
  others, used for most complex issues.

12
Scope Management

• Scope creep what a surprise
• Good-hearted people were trying to be helpful
• Unfortunately, lack of managing this elongated
  the schedule.
• Missing was also the updated documentation, and
  tracking of these changes, including
  requirements, testing changes, etc
• Actions
• Developed a list of known items, prioritized.
• Instituted a formal change process that captured
  new changes, prioritized as well.
• Application Helpdesk and Triage team was a feeder.

13
Contract Management

• The State struggled with the balance of being a
  good partner and hold the vendor accountable.
• The State also struggled with holding itself
  accountable to the contract terms.
• It really boils down to working with the vendor
  to stay focused on the project at hand.

14
System Development

• Formal documentation and acceptance of
  requirements were missing
• This significantly impacted testing, as it became
  impossible to build solid test plans.
• Properly setting up testing environments
• System only had a small test environment, that
  was not the same as production and missed many
  components necessary for complete tests.
• Implemented UAT, E2E, Patch.

15
Testing

• There is just no substitute for good testing.
• Building test plans to align with documented
  requirements.
• Regression testing to ensure new releases and
  patches of software dont break the operational
  version.
• Testing to ensure application works as well as
  incorrect usage doesnt disable the system.
• In order to do this, moved from patching daily to
  more structured releases.

16
Implementation Choices

• What will it be?
• Phased by groups of impacted stakeholders
• Parallel testing with cutover when validated
• Light switch and pray for best
• Phased approach for functionality

17
Other Factors

• Resources Dedicated vs shared.
• Staff assigned to project often were still
  assigned their operational tasks as well.
• This added to the contention for resources.
• Inadequate training and preparation for State
  users and providers.

18
Other Factors

• Build from scratch instead of transfer or COTS
• Successful with other efforts
• New player on block for MMIS
• Paving cow-paths
• 30 year old business processes should have been
  reviewed, possibly reengineered.
• Design of integrating with other systems left
  many limitations.
• Eligibility flow through legacy system
• A picture is worth a thousand words.

19
(No Transcript)
20
Closing thoughts

• Sure, there was a lot that went wrong. But, there
  was also a lot that went right.
• Quick recognition of failings, followed by
  focused planning and action set the tone.
• The State, our vendors, and the provider
  community partnered together to stabilize the
  situation.
• And, the system is in a much better place now

21

• Thank you