The integration of the responsiveness of Agile with the governance of Stage-Gate just makes sense and it's a natural way of working. Even in our daily lives.
My wife and I recently completed finishing our basement. By “completed”, I mean we passed final QA testing (city building inspector) and are now adding the final UX details on the project (furniture, drapes, pictures).
It was a six-month project, and my wife is blessed by the fact that her hubby has done project management, Agile and Stage-Gate consulting for a long time. I think she really appreciated my input on “doing projects the right way” throughout the six months :D
Now that's it over, it's interesting to think back on the project and how we approached it. The project started with a needs assessment (my wife's dream basement) and rough estimate of time and costs. Based on this information, we developed a technical assessment (what exactly was realistic – no, Versailles wasn't quite an option) and business case (a floor plan and a rough idea of what it would cost). We went to our first gate meeting (a much anticipated building permit hearing) and received a GO decision when the city gave us a building permit.
From there, we purchased all of the supplies, followed the plans exactly, and completed on-time and on-budget…
… NOT EVEN CLOSE!
The problem was that there were a LOT of unknowns. We had done large DIY projects before, but nothing to this extent. We had some experience in framing, drywall, plumbing and the other necessary skills, but we had never had to tie it all together in a project of this scope.
Without planning it, we evolved into using what looks like an Agile Stage-Gate hybrid approach. We had real gates with technical progress reviews (inspections) and business-oriented go-no go decisions (aka late talks around the kitchen table) where we adjusted and re-approved the scope, budget and timeline. But in between those gates, everything we did was iterative.
We would run up to the store and purchase just enough materials to get us through the next few days (our next sprint). In some cases, we'd build a section and decide to tear it down and do it a better way (which is okay, because I believe in responding to change over following a plan). Over time, we completed each part of the project and moved on using the same iterative approach until we had a living space we were happy with.
So what does any of this have to do with PPM?
It's obvious, at least to me, that new product development cannot be completed within a strict step-by-step process. For years now, we've been talking about Agile, flexible Stage-Gate, and more recently hybrid Stage-Gate. The integration of the responsiveness of Agile with the governance of Stage-Gate just makes sense and it's a natural way of working.
But all too often, the processes and tools I see people use ignore this reality. What we need is the recognition that structure and flexibility are not in opposition and that they aren't delegated to different teams; they are needed throughout our project teams and require proper support, balance and coordination.
On the process front, we get caught in traps like thinking that creating products is something that can be managed and measured like an assembly line, or that scope change is a bad thing, or that changing the design means we wasted time. That's fine if we only want to do the same thing we've always done in the same way we've always done it, but where's the innovation when we do that? In the same way my wife and I were more concerned with having a basement we liked than worrying about the original plan, organizations should be tracking progress towards the desired outcome than tracking how closely their teams are following their plan.
To be fair to the process owners, these issues are often caused by our PPM tools. Our work is both enabled and limited by the tools we use. In the same way that I couldn't have done miter joints on my baseboards without the proper saw, we can't have flexible or Agile Stage-Gate processes without the proper tool. It shouldn't be a collection of tools; proper PPM governance still requires “one source of truth” that can support multiple ways of working. It's not workflow, it's not Kanban, it's not gate meetings, it's not collaboration, it's not document management, it's not resource or financial management – it's a flexible combination of all of these that allows us to work in the most natural and efficient manner. Planisware is very proud of the fact that project teams can use our products to work in whatever way they chose to in order to meet their project needs.
I'm heading off to PDMA's Annual Conference next week to hear a little more about the current state of the new product development practice and how innovative companies are using hybrid project methodologies to get better products to market quicker. I'll let you know what I learn.
