Project Schedule Slipping? 2 Creative Recovery Methods Inspired by Lean Six Sigma

Your project’s traffic signal status has just changed to RED — Congratulations!

The fact that you have recognized, admitted, and declared that your project is behind schedule puts you in the top 5-10% of Project Managers! Because you have an innate bias to action, you have already called the first special session with your team to get back on track.

     Here are two non-traditional ways for Project Managers to adapt to the unexpected situations encountered during project execution, to plan and achieve project schedule recovery. Both come from the field of Lean Six Sigma (LSS), a broadly accepted industry practice dedicated to delivering value to the customer, used widely in manufacturing but applicable in many other ventures. These LSS tools can help you create and execute your Action Plan to GREEN.

Method 1: Use Daily Stand-up with PDSA, to coordinate all remaining tasks

Method 1: Use Daily Stand-up with PDSA, to coordinate all remaining tasks

When a complex project such as product development is nearing completion, many activities involving different skills, resources, and outside suppliers or contractors have to be tightly coordinated. Hardware/software integration, performance testing, design verification, electromagnetic compatibility and electromagnetic interference (EMC and EMI) testing, packaging and shipping tests, manufacturing release, process validation, and scale-up activities are tightly coupled, sometimes in ways that may not be obvious from the Gantt chart developed many months prior.

     Any delay in starting one task, or failure in one test suite, can cascade through all the subsequent activity.

Many qualification tests have durations that cannot be reduced; they may have a specified number of days or product performance cycles that are mandated by an agency or industry standard. Specialized tests such as EMC and EMI testing are nearly always conducted by outside specialists who book their lab equipment and technician time weeks in advance, with little or no slack time; it is absolutely imperative that the systems to be tested are completed and delivered to the test lab on time, or rescheduling the test will irrevocably delay project completion. 

     If you maintain a weekly meeting cadence throughout your project, in the final 10-12 weeks you may find yourself risking a schedule slip that cannot be recovered. From my experience involving new product development and new manufacturing line installation projects, I have come to rely on the Daily Stand-up with PDSA method to eliminate this end-of-project ‘death spiral.’

Team uses daily stand-up to ensure project schedule recovery.

Briefly, PDSA (Plan, Do, Study, Adjust) is a LSS practice that can be applied to operations, engineering, and other technically complex projects. The practice emphasizes performing quick trials or experiments that can provide actionable data for the project team to improve their confidence that a future task can be successfully completed.

First off, prevention is easier than correction. Don’t wait until one or more scheduled tasks are already late to initiate Daily Stand-up with PDSA. Proactively start the work to stay on track; it is far easier to take action before the final push begins rather than attempting a belated project schedule recovery.

     The Stand-ups must include the people accountable for every major task underway and planned, so that everyone knows what the others are doing. No Surprises! This method only works in teams which have built a high level of personal accountability and trust in one another, through having accomplished all of the previous tasks and milestones.

     Daily Stand-ups are intentionally kept short. Daily Stand-up is for succinctly stating progress and achievements for the prior day, new problems to be assigned out for PDSA solution in the next day or two, and making sure requirements for upcoming critical tasks stay on track. They are not for long debate about product attributes, process flow, supplier evaluation, or in-depth problem solving. Take those offline with subsets of the project team and subject matter experts, and summarize the outcomes in the daily meeting.

     In a recent project, my team used Daily Stand-up with PDSA to devise and perform some experimental pre-testing of new features ahead of system integration using a functional mock-up of the final product. The mock-up and review took us 4 days (the Plan, Do, and Study), and gave us data pointing to a design change to improve manufacturability of one mechanical assembly (the Adjust). Implementing that change effectively prevented a system integration test failure that would have been a show-stopper for us.

Method 2: Use Agile Kaizen, focusing on close-in tasks

Method 2: Use Agile Kaizen, focusing on close-in tasks

This method is most useful when your schedule has gone Red early in the project. Agile Kaizen focuses on shortening the duration of the current and next few close-in tasks, by one day or perhaps a few days each, while leaving later tasks unaffected.

     Agile is a project management technique, often though not exclusively used for software and IT development projects. Agile emphasizes rapidly producing something functional as a useful iteration toward the ultimate end product. Kaizen is a continuous improvement method applied to a manufacturing operation: (1) to break the operation into incremental elements, then (2) to restructure the operation for simplicity, mistake-proofing, and speed.

     Agile Kaizen project recovery combines these two techniques to tackle the current and near-future project schedule. Consider the following example from a recent project.

• Project essence: Product enhancement; electronic, mechanical, software; design and integration; verification and validation; production pilot; 35 weeks planned duration

• Project essence: Product enhancement; electronic, mechanical, software; design and integration; verification and validation; production pilot; 35 weeks planned duration

During week 14, we had planned to have (ref. blue solid lines):
σ  Tasks 5.1, 5.2, and 5.3 completed
σ  Task 6.1 half-completed
σ  Tasks 7.1 and 7.2 started

However, the actual week 14 status was:
σ  Task 5.1 not completed
σ  Task 5.2 just started
σ  Tasks 5.3 through 7.2 not yet started
σ  Business-as-usual estimates for start and completion shown by dark red dotted lines.
σ  Tasks 7.3 and beyond were in jeopardy because of the noted delays.

     During the Week 14 meeting we recognized we were about 2 weeks behind, and made the decision to recover that delay by applying the Agile Kaizen technique to the schedule. After some thoughtful debate about what’s possible, we set our goal to bring the project back to GREEN at the time of Milestone 3, in the middle of Week 22.

     Thus, our Agile Kaizen work focused on Tasks 5.1 through 8.1, to reduce the total duration of those 9 tasks.

The Agile project framework  emphasizes daily scrum and short sprints to complete tasks. Each of our scrum meetings lasted about 20 minutes, and all team members left each scrum with their day’s self-assigned deliverable for the sprint.

     In the first scrum, the project team zeroed in on Tasks 5.1 and 5.2 to understand the work content in detail, and ensure there was no wasted effort, then focused on completing those tasks quickly. By doing so, we were able to reduce the expected duration of 5.1 by 1 day and 5.2 by 2 days.

     Then, since Tasks 7.1 and 7.2 both had finish-start dependency on 5.2, we were able to start those tasks 2 days earlier because of the Agile Kaizen.

     We had 8 more schedule days to make up in the next 7 weeks, one daily scrum at a time.

     The same detailed breakdown of the work with daily completions of interim functionality (sprints) were applied to all subsequent tasks.

     Tasks 5.3 and 7.3 were not on the critical path, but since they still consume resources we dissected those tasks as well, to be sure they did not become critical.

     We continued the daily scrum through Week 21, by which time we had recovered the original schedule.

     Milestone 3 actually occurred one day earlier than originally planned – bagels and schmear for everyone in the building on Friday!

     Then from Week 22 on, we reverted back to our weekly project team meeting cadence, monitoring all tasks closely, and remaining ready to act quickly if any upcoming task was in jeopardy.

Project schedule recovery using agile kaizen early in the project.

Project Schedule Recovery Summary – from RED back to GREEN

Project Schedule Recovery Summary – from RED back to GREEN

Getting back to GREEN when your project is slipping requires a brutally honest assessment of the problems and risks that have caused the schedule delay, and a focused effort by the project team to make the needed course corrections.

     Sometimes the traditional methods – “crashing the project” and “fast-tracking the project” – can work. However, crashing requires that you have a reserve of people with specific skills, plus probably adding beaucoup hours of overtime – including the associated stress – to an already stressed-out workforce. Fast-tracking assumes that tasks planned sequentially can be performed in parallel with little or no added risk.

     My experience is these methods look good on paper, but are only partially effective in practice. Fast-moving tech companies don’t have reserves of idle talent waiting to jump on projects in trouble. Bringing additional short-term contractors up to speed does not happen in an instant. And when you have scheduled certain tasks sequentially, it is usually because each successive task depends on output from the previous ones.

     However, by contrast, Agile Kaizen and Daily Standup with PDSA, applied thoughtfully, are effective because they compel the dedicated project team to conduct a rapid in-depth analysis to understand the immediate and near-future tasks, their associated risks, opportunities, and dependencies, and to do so armed with all of the business context and the knowledge acquired about the project since planning and kickoff.

     It’s tough to beat ‘learning by doing.’ Why not try one of these methods soon in a low-risk situation, and use the experience to build your team’s capability for the next time you need to devise an Action Plan to GREEN?

Dann Gustavson, PMP®, Lean Six-Sigma Black Belt, helps Program Managers and their teams achieve superior results through high-impact program execution. Prepare, structure, and run successful programs in product engineering, manufacturing operations (including outsourcing), and cross-functional change initiatives.

Contact Dann@Lean6SigmaPM.com.