Apply to MSS
Join Our Talent Community
Healthcare.gov is likely the most famous and therefore most scrutinized technology deployment in the internet era. This gives a fantastic opportunity to study what went well, and what didn’t. Unfortunately, there are not many positive takeaways we can learn from the Obamacare rollout. However, that is good news for those of us who want to learn how to avoid their mistakes! It is very easy to find a white-washed case study that glosses over issues and spreads kudos like jelly. A full accounting of an extremely rocky deployment, warts and all, is invaluable to learning what to do and not to do. What will follow is a multi-part series detailing steps to take to succeed in your deployment, with examples of where the Healthcare.gov deployment fell short. I am a very trusting person, but I will always be doubtful towards an optimist project manager (see quotes within the article here). The best project managers I have worked with inspire their teams and can help their stakeholders visualize success. These same project managers stay laser focused on the potential hurdles and do their diligence to understand what changes will be required to overcome these challenges. On the other hand, optimists are sure they can make up lost ground or that bugs will be fixed in time.
The most important principles to share about effective deployment readiness is to define success, keep score, and don’t move the goalposts.
At first glance, this would seem to be an easy step. My system went live on time, on budget, and it works! If only it were that easy. In reality, there are four key areas that must be addressed to ensure a project is successful. I will be covering each of these topics in more detail in future posts.
· Project Readiness: This is the core functionality that project managers focus on. Defect management, scope management, user acceptance testing all live in this bucket.
· Process Readiness: Process describes how the work will get done from beginning to end. The most critical part here is to look at all of the impacts of your change, not just the direct replacement. No one will care if your expense reporting system works if you broke the general ledger process and the books cannot be closed that month.
· People Readiness: This is what is often described as “the soft stuff”. Training, communications, executive sponsorship all need to be defined and addressed in advance. If your system works but people don’t know how to use it, then the reality is that your system really doesn’t work.
· Sustainability: Let’s say you have a rock star project management team that delivers a great project that works for your business processes and is readily accepted by your people. What happens next? The team moves onto the next project, however someone else needs to make sure the improvements that were made stick!
To truly know if you are ready, success must be defined across all of these areas. What % of defects are acceptable? How many processes must be documented to the task level? What % of users must be trained at go-live? How many on-going support staff must be in place? These questions need to be answered for a project to be successful. When looking at the Healthcare.gov rollout, they had set targets for overall signups; very focused on project readiness. As for People, Process, & Sustainability? Not so much.
Note: Be very careful with incentive & penalty clauses for on time delivery of your system. This has the potential to go live on your date, whether your system works or not.
Once you have defined what is important for your project to succeed, it is time to start measuring success! To do this, a holistic deployment dashboard (as shown in fig. 1) is a great tool to utilize. Identify 3-5 key metrics for each area that you want to track. A few key points here:
1. Avoid Paralysis by Analysis If your project success is determined by an aggregate roll up of 150 metric, it may feel like you are being more rigorous. In reality, you a drowning out the signal of your project with noise of data. Secondly, you will spend more time collecting data then actively managing your project. Third, your team won’t know what is important to strive for and hit to drive project success. If you pick the right metrics and manage them appropriately in the 4 deployment areas, the rest will follow accordingly.
2. Measure Progress You can often see the optimist project manager report “n/a” for a metric or not started for a measurement. The metric you select should have visible progress throughout your project. Training for example is a typical activity that gets pushed out until near the end of a project. The team will still need to create a training plan, develop materials, and schedule training sessions all prior to actually conducting training. You should track how far along you are across the total project work stream, not just the most visible parts. This will better allow for course corrections as needed through the project lifecycle.
3. Publicize The project performance and its tracking should be public knowledge. The team should know where they are and what needs to be done to get a project across the finish line. Your project steering committee needs to see what areas the project may be struggling in and how to support and provide resources.
I’ll use training as an example again. I have myself, built countless project plans that included 6-8 weeks for training. But then, development hits a hurdle and we lose a week. Then our testing uncovers a new bug and we lose another 3 weeks. A week gets lost due to low productivity over the holiday season and all of a sudden I need to find 5 weeks out of the project because our sponsor “will not tolerate delays”. So 6-8 weeks of training becomes 1-3 weeks of “compressed” training that the sponsor is sure will be fine because the organization “is used to change and will learn on the job”. I understand that project plans are just forecasts, and all forecasts are wrong. But when you deviate from your success criteria in terms of scope delivered, support provided, or processes supported, you introduce a huge amount of risk when you do so. (I can’t stress this part enough. When you change your success criteria, document it! You will thank me later.)
The costs of delay are often thrown around as a threat to not miss the date. Of course no one wants to calculate the costs of a failed deployment because that might reflect poorly on their own performance. Don’t be an optimist! Add up how much failure costs and have an honest conversation about the pros and cons of a change to your success criteria before you make the decision. The Obamacare rollout pruned its scope massively, pushing out the small business marketplace a year and delaying the requirement of employers to provide insurance until 2015. It determined that the October 1st individual marketplace date was a “must-hit” and so it went live, whether it was working or not. One wonders if they would rather have delayed that an additional month then going live with a system that enrolled only 26,794 people in the first month.
Mike Lien, PMP, is a Consulting Manager who is an expert in managing large scale process improvement projects at MSS. To find out more about how MSS can help your organization manage major deployments and changes, contact us at email@example.com.
MLA: Lien, Mike. “Part 1 – Holistic Deployment Readiness & Healthcare.gov: What not to do.” MSS. MSS. Blog. 08 April 2015.
APA: M Lien. (2014, Feb 3). Part 1 – Holistic Deployment Readiness & Healthcare.gov: What not to do.