Lean Report Development

Recently, I participated in a group goal with a few colleagues to pilot Agile and Lean techniques in non-software contexts. I thought I’d share this case study applying PMI’s Lean Lifecycle to developing a research report since it came up in a few discussions this week.

In 2019, I was assigned project manager of a multi-year effort researching adapting smart grid digital transformation practices for nuclear plant modernization with a team across two continents. A key deliverable was an annual research report on the team’s findings. For the first two years, we followed a traditional, waterfall project management methodology. In 2021, we implemented a more agile approach patterned after PMI’s Lean Lifecycle: this resulted in a much better experience.

The standard process for developing those reports follows:

Following standard waterfall project management methods? - the focus is processing an entire report draft, getting a single review and comment cycle to stakeholders, and then getting it through final edit and layout. During report drafting, stakeholders get regular status updates and are subjected to information requests at random.

This process has the following issues:

• Increasing Risk with Time: Risk ramps up as stakeholder expectations linger until initial draft is available, but doesn’t ramp off until the stakeholder comments are incorporated.
• Deadline Stress: Most research reports show up to the editors at the end of the year. This wave puts a lot of stress on everyone involved: leading to a greater chance of quality issues and delays
• Limited Stakeholder Feedback: External stakeholders have a short time to review an entire report near the end of the process: limiting both the feedback and the ability to respond
• Issues Management Challenges: Issues accumulate through the life of the project as more sections are “finished” and parts of single sections can hold up the entire project.
• Version Control Mishaps: As the body of work grows, version control becomes exponentially more difficult as the report is being handled as a single file

For 2021, we implemented a more agile process to create that year’s report

Adopting a more agile approach? - the focus shifts to finishing sections: engaging stakeholders in a continuous flow. These fully completed sections are integrated into a document that’s ready to publish sooner.

First, an internal team made up of the project manager, editor and subject matter experts (SMEs) develops an outline. After the outline is shared with management and external stakeholders, sections from the outline feed the backlog in a Kanban board.?

This starts the process:

• SMEs draft sections based on what they can write most quickly…not how it will be sequenced in the report.
• Following a team and peer review, the section is then edited, formatted, and laid out to publishing standards
• As part of a weekly update, the external stakeholders receive an email with sections to be reviewed and an updated outline
• Following external review, the team incorporates comments into the section and the section is integrated into the document.?
• As each section is added, there’s a consistency check and updates to the front matter and appendices.

After the sections are completed and integrated, the final report goes through with the final review and layout. Team members “pull” based on some basic “work in process” (WIP) controls (i.e. drafting one section at a time, using external review as a “buffer”, etc.)

We saw the following advantages using this process:

• Increased Quality: Greater product quality through more stakeholder input being incorporated earlier.
• Lower Costs: Lower overall product costs gained mainly through more efficient use of SME’s time (drafts available earlier, quicker meetings, and faster issue resolution)
• Increased Stakeholder Satisfaction: Greater stakeholder satisfaction through earlier alignment and more effective incorporation of feedback.
• Lower Risk: Project risk level drops early. After the first few sections are finished, a completed deliverable is only a week’s worth of work away. Challenges stay isolated at the section level - never endangering the final deliverable
• Greater Creativity: Greater creativity within the project team. Measure: there were more changes to the outline in the Agile approach as opposed to previous waterfall reports.
• Easier Version Control: Consistent use of Box and keeping most of the churn to the section level avoided versioning mishaps. The final report was also kept better controlled.

Of course, in this life…there are no solutions - only trade offs. Here are some of the new challenges:

• Change Management: Senior SMEs were used to a linear process and expressed discomfort with an iterative process - especially being limited to one section at a time. As PM, I did not “enforce” WIP limits in order to be as accommodating as possible and work on selling them on the fundamentals.
• New Tools: Real-time file sharing through Box made this possible. This meant that each team member had to align best practices using Box (commenting, using Box drive and leveraging Box’ native versioning) and that involves coaching and sticking to a standard of operation.
• Increased Editor Costs: Our editor was engaged throughout the project as opposed to one shot at the end. The increased costs were more than offset by the savings in SMEs’ time

Here some adjustments I’d make to the approach for the next time:

• Engage the editor right after drafting. Getting the sections formatted and edited before the team review builds quality in earlier and allows the SMEs to do technical, as opposed to grammatical, review.
• Don’t name sections by number. Section numbers will change as the team moves stuff around, splits sections and adds new sections. Instead, refer to sections that look like the title of Friends’ episodes (e.g. “The Section about APIs”, etc.)
• Welcome backlog items smaller than sections at the outset. As the report was draft: the team submitted ? page ideas. These still made it to the Kanban board. This is a good thing and a natural result of a lean process (i.e. “smaller batch size”)

The key takeaway: greater agility doesn’t come from dogmatic adherence to a framework or rote execution of ceremonies. By gleaning the principles and? leveraging an understanding of the underlying theory that make Lean and Agile work, project managers can reap the benefits in other contexts.