Lessons From Launch

Our project team recently pushed a significant upgrade to a client application that was needed to comply with upcoming Federal Energy Regulatory Commission (FERC) regulations. These changes include a massive overhaul of how utilities track transmission capacity across their grids, and represent an innovative change in grid operations across the country in support of unlocking more capacity in an age of growing demands.

This effort also included other secondary priorities to enable these new features: integrating new services to enable more robust data entry and reduce user error; bringing new stakeholder groups into the fold to guide the direction of the application; retaining and handling of historical data created prior to this upgrade that allow future audits to be a breeze.

This release was the culmination of over a year of discovery, design, and development efforts, all while simultaneously supporting the existing production application. Needless to say, the past year has been quite the ride with a few lessons learned along the way.

Lesson 1: Plan, Plan, Plan

This might seem obvious, but taking the time upfront to scaffold your approach and document your decisions is truly worth its weight in gold. It prevents countless headaches down the line and builds in crucial flexibility. Before putting any metaphorical pens to paper, our project team did its due diligence of whiteboarding our approaches and refining our options, doing our best to document our decisions in artifacts that could be easily referenced during the inevitable technical discussions months later.

Ahead of this project effort, we came together as a team to agree on and introduce a habit of codifying engineering decisions using an Architecture Decision Record (ADR) pattern and put pieces in place to formalize our philosophy for capturing design and experience decisions. Both of these habits enabled informed discussions at every step of the way and provided us with reference points when a previous decision had to be adjusted as new information came to light.

However, it’s not enough to just have a development plan; you also need a clear plan for how you are going to execute the rollout. We began this exercise more than six months ahead of our planned deadline and were happy to do so. When crunch time came, everyone involved was clear on the path forward, reducing last-minute confusion and stress.

Lesson 2: Overcommunicate

I’m a strong believer in the “aces in their places” – meaning each individual team member has something of a specialty – approach to teamwork to avoid the common pitfalls of context switching as well as allowing for a greater sense of ownership over a given feature set. However, this can easily lead to siloed information. This makes it critical to share knowledge out in the open among the entire team, especially in a remote environment where work tends to be done asynchronously.  Even if one team member is the primary expert on a feature, it’s advantageous for everyone to keep their finger on the pulse in case they need to jump in and lend a hand.

Another challenge to overcome: all of the development work behind this upgrade was happening while providing support for the existing production application. With this in mind, frequent touchpoints with each stakeholder group were essential. Even if they didn’t see tangible progress until close to the actual launch, keeping them updated on our progress of what was to come built trust and helped manage expectations.

Different stakeholders hold their stakes at various points in the data lifecycle, and coordination among them was crucial for everyone to understand the entire picture. For example, some were responsible for maintaining the underlying source data, while others used that data to generate resulting application data, and still others consumed the data generated from the application for work in other systems. Ensuring everyone understood their role within the broader ecosystem and how their contributions impacted others was key to a successful launch.

Lesson 3: Embrace Flexibility

Requirement gathering is inherently challenging, and with a yearlong lead time like ours, a change in requirements isn’t just possible – it’s inevitable. Having a plan doesn’t mean it’s set in stone. Instead, it creates mutual understanding among all parties, a solid foundation that can then be built upon and adjusted through informed decisionmaking. A mantra I have written about before and that I believe strongly in is: “Execute a mediocre plan violently.” This doesn’t mean that you should be shooting for mediocrity and being excited about that, but rather that you shouldn’t let perfect become the enemy of good. Come up with a reasonable plan, execute it with confidence, and be fully prepared to adjust your approach as challenges arise along the way.

What happens when you hit an unforeseen roadblock 90% of the way into implementing a feature and have to overhaul your approach? What about when a foundational requirement changes in the immediate lead-up to launch? These scenarios are common. Without flexibility built into your process and a mutual understanding among your team and stakeholders, these challenges can quickly derail a project. Being able to adapt, pivot, and make informed decisions in the face of unexpected changes is a true testament to a well-prepared team.

In the end, reaching a milestone of this magnitude, especially one with such potential to be part of the effort to increase the reliability and capacity of the nation’s electrical grid, was a monumental undertaking. The journey reinforced that while complex challenges demand rigorous planning, success truly hinges on fostering a productive team environment. The lessons I’ve learned during this time are not only applicable to undertakings of this magnitude, but also to any project going forward. By taking the time upfront to develop a plan, communicating constantly, and leaving room for flexibility, you too can become well-equipped to navigate the unpredictable waters of any team effort.