by Charles Sybert –
Processes that seemed impossible to digitize just a short time ago are rapidly making the leap to full automation. Smart executives spend a significant amount of mental energy keeping abreast of these changes and determining which can provide the best ROI. Often, it is tempting to skip straight to analyzing the benefits of a new platform or service without giving proper weight to implementation costs, challenges, and degree of difficulty. The Program Management capability is the glue that connects plans to reality delivering the planned value. This blog reviews some key highlights, tips, and tricks to level up your organization’s program delivery.
Program Initiation
The old saying goes, measure twice and cut once – and this principle applies as much to building software as it does to building homes. Foundational processes and approaches need to be established before the team can be onboarded to start delivering. Before setting up details such as the communication plans or defect tracking tools, take a step back and frame the program’s value and align the program deliverables to the business by defining two key aspects of any program: the North Star and the Guiding Principles.
Define your North Star
The North Star for a project is more than a goal. It should be something impactful, inspiring, and meaningful to the company that participants can use to steer their decision making at all levels. For example, replacing the policy administration system can be the program’s goal, but is not something the team can rally around to deliver. An example of a North Star is “creating a modern digital experience for the customers and agents, enabling them to work smarter and faster”. With this as their guide, the team has a better understanding of how the project will change the fabric of the company. If a proposed change adds layers of complexity, or involves manual steps, it’s easy to see that it’s not well aligned to the North Star. A North Star needs to be something assertive, articulate, and describe a lofty ambition in order to be meaningful.
Define Guiding Principles
After the North Star has been created, the next step is to define guiding principles for the team. These principles help the team make decisions and drive outcomes as the project lifecycle progresses. The goal is to have less than ten principles that are broad yet meaningful and designed to guide action without being so low level that they appear to be requirements. Continuing the policy administration system replacement example from above, some of the guiding principles might include:
- Focus on self-service
- Strive for 100% automation of every process
- Focus on ease of maintenance and regulatory updates
- Enable reporting of every action within the system
- Drive actions from dashboards
- Minor changes to supporting systems
- Build a foundation for future-phase AI/ML value additions
Delivery Planning
After understanding the business drivers and articulating the program’s core values, the next step is to map out the program’s delivery plan. As a starting point, define the high-level program scope. This will be a key input to a milestone plan, focusing on providing business value incrementally. To address inevitable in-flight changes, the delivery should take place in a nearly continuous, iterative fashion. The art of nearly continuous delivery – managing customers’ expectations when viewing in-progress work – can be aided by the use of guideposts and an impact-value approach.
Define Guideposts
Before the development begins, take some time and lay out the guideposts for the delivery. Each guidepost is a high-level view of the work plan – stories, cards, processes, boxes, or your preferred work unit – for delivering functionality. Authoring guideposts is a balancing act between providing enough detail to illustrate the value of each deliverable but at a high enough level to provide a roadmap of the entire program when the guideposts are strung together. A set of guideposts is not a detailed business requirement, a technical design, or a screen rendering. It is an artifact that maps out the overall system capabilities and needs, telling the anticipated story of the program.
The outcome of this exercise is to provides an end-to-end view of the system’s capabilities and expectations for the final delivery. Using this, technologists can understand the impact on data, API requirements, and down/upstream procedures and gain insight into the required technical designs. This helps architects quickly identify collisions of data or unrealistic expectations around capabilities that need to be reimagined, given the constraints of the application landscape and technology stack. Making changes during the guidepost phase can save an exponential amount of development, testing and delivery rework. For example, there may be a request to incorporate previously purchased third-party data, but an investigation may have shown that the package doesn’t contain critical fields used by the new policy system. In this case, an assessment of updating the data set or replacing it with a new subscription service.
Design Impact-Value Deliveries
In projects of any significant size, a multiple-pass approach will be required to achieve minimum viable product (MVP) and will continue through subsequent delivery phases. One of the most challenging aspects of program delivery is shepherding the business toward a reasonable scope for each phase, particularly the first.
There are two complimenting keys to overcoming customer objections and scope-stuffing: impact-value deliveries and trust building. When the delivery architects have a deep understanding of the customer’s business and the project North Star they can design work units that enable the process by providing standalone functionality that builds upon itself. When the customer buys into this vision, it allows for an environment where each fast iteration provides something truly valuable – a building block that stands alone and simultaneously facilitates the next step. It may be necessary to create multiple versions of this delivery ordering at an early stage – allowing the customer to participate by voting with other stakeholders provides all parties with a sense of ownership. “Their” plan becomes “the team’s” plan.
Once the deliveries have been collaboratively designed, the next step is to build a track record of success. With each small (but impactful) delivery, the customer’s confidence increases – along with their comfort level at spreading functionality out to future phases. If the delivery partner can be trusted to make the interim milestones leading to MVP, they can be trusted with phases 2, 3, and so on into the future.
Deliver Iteratively
This trust building takes place during the next phase – delivery. The marriage of all of the teams efforts in planning and the work of a knowledgeable, professional development and test team turns the plans into reality. Clearly documented and visible processes will keep the team on task while generating data that can visually demonstrate progress toward the ultimate goal: timely delivery with the highest quality.
Illustrate Progress
Using a project management tool like JIRA or Azure DevOps will provide the necessary metrics to show dashboards so that everyone, from the quality engineer to the CEO, can understand how their efforts impact program success. Using the previous guideposts, the development team can focus their efforts on implementing the functionality, given the current state of the application. The tools facilitate an iterative, constantly progressing view of the work that automatically updates in real time (when the team updates them according to your process).
Build Relationships
With any delivery, there will always be defects, misses in requirements, or technical challenges that need to be resolved. Traditionally, these fall to the technology team to solve as they have the perceived expertise, but that view is incomplete as it is missing the business’ point of view and knowledge. At the start of the program, set up a twice weekly meeting between the business leadership, technical leadership, and the project team. The agenda should remain open to the top progress impediments or any questions the team may have. Repetitive exposure will create an environment where the free exchange of ideas, challenges, and gain understanding is built across the team. These meetings can become healthy sessions through the code, demonstrating screen behavior, showing the current system and other project level data rather than long formatted power point decks. Collaboration is the goal, not one-way progress reporting. The team will know it’s succeeding when the sound of laughter overpowers the sound of gnashing teeth.
Conclusion
Program delivery is part science (hard statistics around goal accomplishment, timeliness and quality) and part art (steering all parties in a productive direction, overcoming fear and uncertainty, and designing outcomes that benefit all parties). As a program manager you will be active at every level of the work from the corner offices to the trenches of the daily standups. Taking a structured approach – starting with a North Star – will provide you with a blueprint for success.
Learn more about our Insurance outcomes.
