Lessons Learned Retrospective from our TriZetto QNXT Implementation

This year we are upgrading to the next major version of QNXT. It is another large implementation effort. This week I prepared for a “lessons learned” session with the upgrade team. Here are my impressions on what we did right, and what we aspire to do better
Commit Resources

• We allocated dedicated resources to the QNXT implementation program which was important for a program of this size
• The program manager took a hard line on not letting any resources go – which was great because an effort of this size requires a full commitment
• What didn’t work - anything lower than a 100% allocation to the program. In our environment, everything is an urgent number one priority. So if you were an individual who was 50% allocated to the program, what that really meant is that you were 100% allocated to two number one priority efforts. The QNXT upgrade program is of the size and complexity that focus and concentration by all parties involved is required

Pay For Performance

• We paid out a performance bonus for key milestones in the program: design freeze, entrance to model office, go live and stabilization. Meeting these milestones was hard. And in the 11th hour we still had work to do to make our targets for every milestone.
• Everyone’s level of effort was a 10 of out 10. I think the performance bonus worked. It provided an added incentive to get the job done

Get Feedback From the Business Users Early

• We started the design phase on January 1, 2008. We started testing on July 1, 2008 and ran testing through January 31, 2009. What that means is in the worst case – the business defined their need in January of 2008, and we didn’t show them a solution until 12 months later to collect their feedback. Any by that time – their needs changed.
• The way we need to operate from the beginning is exactly how the QNXT implementation program ended. We should have short cycles 4 to 6 weeks, where we implement shorter more focused design, build and testing phases
• At the start of the program we broke down the work and allocated teams by function: interfaces and extracts, enterprise data warehouse, web, reports migration, configuration. At the end of the program, when we were nearing go live, we reorganized by subject area: eligibility, premium billing, customer service, claims/finance – so we could focus on bringing one subject area live at a time. For the upgrade, we should break this work down by subject area from the beginning and save our selves the time of reorganizing later. Our functions (interfaces and extracts, configuration, etc,.) will still exist and they will cut across the subject area teams

Sit Together

• We put our entire web team (the only project track which finished on time) in one room
• I don’t think we can put a price on the collaboration that will happen naturally when people sit together. We had business analysts working side by side with developers and testers. If we could have had the business subject matter experts there it would have been even better.

Three Rules About Testing

• Rule #1 Test with real data
• Rule #2 if you can’t test with real data, see rule #1
• Rule #3 automate your tests

Automated testing will allow us to run more cycles faster and thereby yield a higher quality deliverable in a shorter amount of time

In order to automate testing, we need to get to a more granular level of detail in our business process flow documentation.


Other Notables

• Track actual time on deliverables
• Start knowledge transfer and ownership turnover early
• Automate everything we can automate