Recently, we had the fortunate opportunity to talk to our second Playbook customer about the successful completion of their large and complex project. In this particular implementation, the company achieved 60% reduction in cycle time as well as a 50% reduction in cost.
Besides the obvious wins, three additional items made this result interesting:
- First, it wasn’t an R&D project–it was an enterprise IT project;
- Second, the scope was at least twice as big as the previous one; and
- Third, we achieved this result before Playbook software was developed.
In other words, we implemented the Playbook method using spreadsheets, sticky notes (lots of them!), Sharpies, large foam boards, copy machines and web cams!
What we discovered was the methods work for any project with a lot of complexity and uncertainty, and not just R&D for manufacturing.
Here’s the story behind that effort and some of the project highlights…
I met Patrick Shannon at the 2009 PTC/USER World Event where I was giving a presentation titled “Lean NPD & PLM: A Perfect Marriage, or a Perfect Storm?”
At the time, Patrick Shannon was the CIO at a large aerospace and defense company and was about to launch a project to upgrade their PLM system. A few years prior, they had completed a similar project and weren’t happy with how long it had taken. The new project was twice the scope–twice as much data, twice as many users, and twice as much functionality. As such, Patrick knew there was a good chance the new project would take twice as long, and that was not acceptable.
Since I was talking about Lean Project Management and PLM in the same presentation, Patrick contacted us to ask if the Playbook method would work on an Enterprise IT System upgrade.
After a bit of Q&A, we saw no reason why not, so we accepted the challenge.
Understanding the Current State
Back then we always started an engagement with a diagnostic phase. This phase involved creating a Current Reality Tree (CRT) and a Value Steam Map (VSM).
The CRT is a very robust version of a root cause assessment. The very popular “Five Whys” will get you to a root cause, but in complex environments it’s very likely there are multiple root causes. So you have to find all of them and the CRT has the effect of asking “Five Why Else’s.” In other words, rather than digging straight down, it also looks laterally for issues. The CRT is then used to identify all of the necessary solutions and connect them to the issues they will resolve.
We followed the CRT exercise with a Value Stream Mapping session to highlight the overall process, the wait times, repeat loops, etc. This work is beneficial to establishing a high-level project plan.
And both methods are great for generating buy-in to the subsequent solution. Patrick still had notes (and a great memory!) of the engagement and reminded us that we completed the diagnosis and initial methods training within four days.
Playbook Lean Agile Method
Other important foundational pieces that we put in place were:
- Project Economic Modeling
- Project Risk Management Process
- Decentralized Planning
- Manual Visual Project Boards
- Daily Standup meetings
- Rolling Wave Planning
These are all key parts of the Playbook Method.
Fixing the Airplane While Flying
This entire process was completed over a six-week period, which may sound long, but all of the coaching work was done on the actual project so there was very little downtime during the training. And most of the resources were assigned to other projects and were only available part-time, so we were literally fixing the airplane while it was flying.
As I mentioned, the results were unprecedented. Even though the scope of this project was at least double (data, users, functionality, etc.), we finished it in 60% less time—literally 12 months faster than the previous smaller project. And because of the unexpectedly short duration, the company saved over $400K on their project budget.
Results like this don’t go unnoticed and their team won their company’s Silver Level Chairman’s Award.
From Patrick’s perspective, “The Playbook method is a game changer. Even though it was built specifically for product development, the methods are so practical and robust that they work in any type of complex project. In fact, Playbook becomes increasingly valuable as projects become larger, more complex, with more people—especially remote resources—and longer schedules.”
Project Management Issues are Consistent Across Complex IT and Complex R&D Projects
To demonstrate why this worked so well even though this was an enterprise PLM system upgrade and not an R&D project, these were some of the root causes we discovered. Notice how much they sound like the same issues faced by hardware product development teams...
- Planning is not thorough
- Cross-functional communication is lacking
- Resources have other commitments
- Schedule isn’t visible
- Schedule is out of date
- Priorities are not clear
As you can see, Playbook is both a methodology and a visual management tool that supports a fit-for-purpose approach to product development, but it also works for any project that has a lot of complexity and uncertainty.
If you would like to find out if these methods will work on your non-R&D project, feel free to schedule a free 30-Minute strategy session with me, David Paulson, President, Playbook.