For the last 12 months, I had an incredible opportunity to live and breathe an enterprise-level software system upgrade that impacted all major functional areas of a local healthcare organization. My functional title was Project Coordinator handling reporting and assessing progress but my role was to be the “connective tissue” between business stakeholders, operational resources, and technical teams. For over 12 months we drove the various workstreams to a successful launch in June of this year. Now complete and operational, here are my top 5 takeaways from this effort:
1. Truth (in communication) builds trust. Building the 10,000 ft level narrative is essential early and ongoing because it builds trust and maintains confidence - business and operations partners are normally wary of anything IT, so building trust is huge. It is best built with consistent messaging about why the upgrade is happening and transparency without judgement around issues that arise - unwavering messaging at the right level that reflects what’s really going on and being discussed. When messaging risks/issues, this is a true opportunity to build trust. If you can accurately explain the issue, root cause, and path to resolution, especially technical challenges, it is a win for the program. Our litmus test for something that needs more investigation/exploration is if it doesn’t easily fit into the narrative.
2. Reporting must reflect the right project outcomes. In a program like this there were lots of opportunities to track stats and progress for various workstream efforts. We found that it's important to keep in mind what message we were trying to send when building out dashboards or metrics because we wanted them focused on answering the right questions. For example, a burndown chart doesn't make sense if the units of work differ in size or effort. Finally, this work is time consuming - if you can automate dashboards or report-outs, that is the dream, but the mantra "garbage in, garbage out" holds true. If you're relying on many people for inputs it can get messy. Leave as little as you can up to personal interpretation if you have decentralized report data entry. Playing backend quality control is much less efficient.
3. Be mindful of the “Stakeholder” experience. If engaged in ways they are most familiar with, stakeholders will emerge as allies. As we learned more about organizational structure we adapted stakeholder communications and engagement based on differences in interdepartmental structures. We built flexible communications - easy-to-update matrices and distribution lists as opposed to static org charts and other visuals. Also, don't assume communication will be sent down the chain the same way in different functional areas. Learn the styles of each and flex your communication approach accordingly.
4. One project, one scope. Scope creep happens in every program, and a clearly defined program is imperative; however, related business challenges that might be outside of an IT program scope can still jeopardize go-live and therefore are still program risks worth tracking. Understanding the overall bucket of work (even if it's not your bucket) is critical to program success. Take the time to sit down with distal stakeholders, understand their scope of work, and ensure timelines align.
5. Daily reminder to "assume positive intent". Upgrades are stressful times, sometimes pitting operations vs. business vs. end users…. We all end up in our bubbles from time to time and it is easy to forget that we're all doing our best. I learned to reinforce that anyone who assumed malicious intent or time-wasting was taking the easy way out and assigning blame, which was not cool. We worked to address assumptions like these early on and avoided larger discord as things got closer to go-live.
There are many other lessons, but the above reflections will stay with me always. What resonates with you? Reach out if you'd like to discuss further, and best of luck with your next enterprise-level software system effort!