“Are you freaking kidding me!” (I didn’t say freaking). That’s the response I had after toiling for almost a year on a problem to discover it could have been solved in a week.
While I was an engineer with Cerner, a health system VP came to my team with an urgent requirement, “Here is a list of enhancements we need as soon as possible!” I scurried out and went through my routine of defining all the steps needed for each item, meticulously detailing each stage with the number of hours it would take and the sequence in which it needed to be completed. The project manager and I then inserted these figures into MS Project and viola – the project will take 10 months, begin with a build phase, move into testing on month 7, training on month 8 and we will be ready to go-live on month 9.
We successfully hit all our dates and, feeling very proud of ourselves, declared victory. A few months later, I visited the hospital and spoke to one of the physicians using our new code, fully expecting to receive overwhelming adulation for what was clearly outstanding work. Instead, she proceeds to tell me that, “now that we are using it, it’s clear that all we really needed was a couple of new order sets to eliminate the searching.” <<insert expletive>>. It’s not the physician team’s fault. They were asked what was needed to address their needs and they provided it. That list of needs morphed into a full-blown custom application, 90% of which was never used. Toss it in the can… Now, what if we could learn what was really needed earlier on in the project? Insert Agile.
Agile is a framework built on 4 core values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
What happens here is that learning is built into the work, not deferred until the end, after everything is built. This is important when you have uncertainty and need to “try different things out”.
Why agile is better for EHR optimization projects.
Optimizations involve numerous features. As optimization requests roll in from different departments, a method must be followed to capture, prioritize, and weigh against the other requests. Scrum (a commonly used agile method) achieves this through 4 artifacts:
Project Vision – 1 page document describing business need, justification, success criteria, project prioritization and any known constraints or assumptions
Product Backlog – Ranked list of optimization requests to be delivered with points assigned to each feature.
Team Board – The agile team will use a board that allows the team to track which of the features from the product backlog are included and their progress to completion
Burn Down – A graphical representation of work left to do versus time. The chart used to track the project duration by measuring the amount of outstanding work. This is used to predict when all the work will be done or “burned down”
Optimizations are uncertain. Requests for enhancement to the EHR are built on assumptions or theories by the requestor. This leads to features that may not yield any real value. The Agile methodology addresses this uncertainty by moving the learning up in the cycle and conducting a retrospective analysis of the features introduced in each iteration. This allows for feature changes or reversions to occur in the subsequent iterations. By rigorously analyzing the value of each feature and then quickly adapting to what was learned, the Agile method allows for discovery and faster delivery of value.
Priorities change. Requests originate from different departments and stakeholder groups. What is important this quarter could change in the next as the health system changes over time. This fluctuation of priorities is handled nicely with Agile’s ranked product backlog. This is a prioritized list of features to be delivered. This list is revisited at the start of every iteration and can be added to and reprioritized at that time. The backlog is prioritized through various ranking schemes. Some of these include:
The MoSCoW Method – Classify each feature as Must Have, Should Have, Could Have, Won’t have (this time)
Monopoly Money – Each feature has a cost representing the total budget. Sponsors are given monopoly money representing the budget and asked to distribute to each feature
Kano Analysis – Classifying features as performance needs, basic needs or excitement needs
Optimization projects need to deliver value early and continuously. Each iteration (or sprint) in an Agile project typically runs 4-6 weeks. Iterations are comprised of a selected set of features, retrieved from the backlog, that will be included. Features can then be grouped and released into the environment based on the organization change adoption velocity. Features are grouped in these packages:
Release = a group of iterations or sprints introduced together into live
Sprint = Time-boxed period under which the team will do work
Epic = a large group of related features
Optimization projects can be long. If optimizing the IT systems is a never-ending endeavor, how do we “projectize” the work? If the project runs on too long, team members can get fatigued and tire of the seemingly endless barrage of requests. We need a way to keep the team motivated and avoid the fog of monotony. The agile method does this by breaking the work into smaller, consumable iterations (or sprints) with consistent structure, but variation in the deliverable. This provides a sense of accomplishment across the team members at the completion of each release. The structure of a Scrum team consists of 3 roles: The Product Owner, The Developer, and the The Scrum Master participating in 5 meetings
Release Planning Meeting - Review the vision and business objectives and establish the number of iterations.
Sprint Planning Meeting - Part one is a review of the product backlog items the Product Owner will ask the team to forecast and deliver. Part two is where the team decides how the work will be built
Spring Review Meeting – Held at the end of each sprint where the team shows which Product Backlog items they completed during the sprint. This might take place in the form of a demo of the new features.
Daily Scrum - Each day of a sprint, the team holds a daily scrum meeting. Each team member reviews what they accomplished in the prior day, their plans for the current day and any impediments. These scrum meetings are strictly time-boxed to 15 minutes.
Sprint Retrospective - In this meeting all team members reflect on the past sprint and check three things: what went well during the sprint, what didn't, and what improvements could be made in the next sprint.
As we move past the era of massive electronic health record implementation projects and into the age of EHR optimization projects, adoption of an Agile method should be included in an organization's delivery methodologies – driving incremental value to the health system at an increased pace.
Don Ellis is an Agile Certified Practitioner, Certified Program Manager, Cerner Certified System's Engineer and Epic certified management consultant. He provides project management and advisory services to E&A clients around the world. He can be contacted at firstname.lastname@example.org