Apply to MSS
Join Our Talent Community
This is the second post in our multi-post series on holistic deployment readiness and Healthcare.gov. To read the first entry, please click this link.
Project readiness encompasses the core of what a deployment manager focuses on each day. The purpose of this area is not to try and define a new project management methodology (PMI has already done a fine job of that). With that being said, there are a few key points that I’d like to highlight for a manager who is working on a major deployment; resource management, effective requirements gathering, the art of tradeoffs, and dress rehearsals.
A project is only as the resources staffed to it. But perhaps more important than the quality of resources is the time they have to dedicate to the project. Beware of the situation when you have a major project and all of your key roles are filled by resources split between multiple projects and functions. Two half time resources do not equal one full time resource! As additional resources come into the project, communication channels multiply exponentially. More time is needed for coordination and logistics, less time used for value added activities. Split resources are an unfortunate fact of life for most projects, but be sure to factor that into your project schedule and activities.
One of the first steps in your project, after you have figured out the problem you want to solve and have built your team, is to gather requirements for what the solution should do. It is critical to do this step thoroughly and correctly to prevent problems throughout your deployment lifecycle. If you do not gather the correct needs of your customer, then issues will inevitably arise later on in the project. There are a couple key tactics you can use to gather effective requirements:
Too often a requirements session consists of a technical expert, who knows nothing of the business need and a customer who doesn’t understand the technical implications of their requests, or how to phrase what it is they need. Someone on your team needs to be familiar enough with both sides of your project to bridge the gap between these areas. It is often necessary to conduct knowledge sharing sessions on the business process with your technical resources, and on the system capabilities with the end customers. (This is also another reason to be sure to document your business processes!)
· Ask for problems, not solutions:
Too often teams get hung up in the details of technical requirements. One project I worked with struggled greatly trying to figure out the best way to integrate their new ERP with a legacy reporting tool. They had decided that no end user reporting touchpoints should change in the new system, so all connections should be maintained. When we investigated what that particular reporting tool was used for, it turned out that 1 automated report was sent to a printer each day, called “Barry’s Report”. When we asked what it was used for, we found out that a guy named Barry used it but had retired two years prior, and they had just been shredding the report since then. Understand the right problem, and that can free your team to determine the most cost effective solution to the problem.
Many stakeholders will ask for the moon, figuring if they get 50% of what they asked for they will be ok. Be sure to go through your requirements list and effectively categorize all of the requirements into categories. Ask about the worst possible solution they could live with for 1-3 months after go-live; the absolute bare, survivable minimum. Those are your critical requirements. Then ask what they would need to have included by month 6 or so for the solution to be acceptable, those are your “nice to have” requirements. Anything outside that timeframe is in your “want to have” list. It may be harsh, but when tough choices on the project need to be made, it is better for everyone to know what gets cut first.
There is an old saying a previous manager of mine was fond of, “The ideal project is fast, good and cheap. In reality you are lucky to get one and charmed to get two.” You have to understand what the priorities of your company are and the culture it operates in. If a key feature is taking more time than expected, the proper response may be to delay the project so it can be completed, hire more resources to complete it on time, or move the functionality to a “Phase Two” that will come at some later, unspecified date. There may be times where one of these three is an obvious answer, but more likely it will depend on the specific attitude of the company and the project sponsors. Selecting between these tradeoffs is a critical skill; chasing all three points of the triangle is a recipe for project disaster.
Once you and your team have made it close to the finish line of your project and are ready to flip the switch, don’t forget one last thing. You need to practice first!!!! There are so many unexpected bottlenecks that may occur on a major project go-live that you must nonetheless prepare for. The only way to identify these is to walk through the steps as close to the real thing as possible prior to your go-live date. The Healthcare.gov rollout had two weeks of end to end testing prior to the October 1st go-live date. They weren’t able to conduct sufficient volume testing or functionality testing, and thus delivered a broken system. Football teams don’t run their plays for the first time on game day; and Broadway shows don’t sell out of tickets the first time they put the show on. Don’t assume you can do any differently.
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 2 – Holistic Deployment Readiness & Healthcare.gov: What not to do.” MSS. MSS. Blog. 08 April 2015.
APA: M Lien. (2014, Feb 10). Part 2 – Holistic Deployment Readiness & Healthcare.gov: What not to do.