What’s Your Minimum Viable Project Plan?
Recently, all of us at LiquidPlanner have been bitten by the Lean Startup bug. We’ve been reading and studying Eric Ries’ methods for building better products faster, with less waste. You’ll likely be hearing more about how our own team is changing based on what we’ve learned, both on this blog and in our product. Stay tuned for that.
I won’t attempt to summarize the book’s ideas (plenty of others have done that), but much of his advice centers around the concept of the “Minimum Viable Product” (see Eric’s presentation below for more). He shares how startups have found success by building feature-light, stripped-down products, with the primary goal of getting them in front of customers, testing them, and finding out if they’re on the right track as quickly as possible. Once you’ve learned from the tests, you repeat the process.
For those of us who have spent years building very polished features, this is a radical idea. It would be easy to look at this shift as scary, and even potentially embarrassing. It makes total sense – you have to embrace uncertainty, speed, and even failure to get the benefit of frequent learning and optimization.
It strikes me that there are strong parallels between building products and building project plans. How many project managers spend hours, days, or even weeks building the perfect project plans – complete with resource balancing, dependencies, and detailed task breakdowns –only to have them discarded, delayed, or overhauled due to changing business circumstances? It’s no wonder teams so often resort to Excel or email to manage their work.
On one hand, you need detailed and accurate project plans and on the other hand, you need an easy and manageable system. How can we meet both needs? For starters, you can build a Minimum Viable Project Plan. By that I mean a plan that’s less baked than your “ideal,” but that can be made quickly, modified quickly, and shared with the team quickly.
Here are my top five components for a Minimum Viable Project Plan (or MVPP). These are made under the assumption that you’re actually working on more than one project at a time (because these days, who’s not?).
- Put your projects and tasks into priority order (or as close as you can get).
- List out the big chunks of work in each project and assign them to the right people. Don’t bother creating hundreds of small tasks. Just use the notes section of each “chunk” (the same way you would an email!) to list out the details.
- Give each project a deadline date. Don’t bother estimating for now.
- In addition to your list of prioritized projects, create an “ASAP” package that has each person’s top five to-do’s in it (from across all their projects).
- Maintain the project plan. Mark stuff done, keep the projects in priority order (and add new ones as they come up), and ALWAYS make sure each team member knows their “Top 5” to-do’s across all projects.
How long should you keep up this most minimal of project plans? For as long as it takes to prove to yourselves that you’re free of Excel and have a sustainable way to keep projects and priorities straight. Then, and only then, should you even think about breaking work down into more detailed tasks, adding estimates, resource leveling, and all the fancy stuff. And when you do add those things, add them one at a time. I bet that’s what Eric Reis would do.
What do you think is the Minimum Viable Project Plan for your project management team? What do you consider more valuable – a high-level of detail or a “real-time” plan? In our experience, it takes considerable discipline and focus to have both. Our hat goes off to you if you do!