Is trying to manage your ever-changing project plan keeping you awake at night?
Does defining your requirements feel like trying to wrestle an angry octopus into a string bag?
Do you feel torn between allowing your customers and team to be agile while simultaneously creating defendable schedules, estimates, and scope definitions for your sponsors?
Fear not. While the struggle is real, so are the solutions. Teams have been grappling with project requirements in flux, high rates of change, and demands for detailed plans for years. We can steal their best strategies and avoid common mistakes. Let’s explore 9 planning tips for taming wild projects without stifling agile teams or mumbling when asked about the project management plan.
1. Take a Customer-Centric Approach
Relentlessly focusing on customer needs and wants is the way to win them over. Showing genuine care for their desires builds understanding about the true project requirements.
Sponsors listen to customers more than project managers about progress. With the customer on your side, changes to the plans are supported when they improve the solution.
Do this by collocating with the customer whenever possible. Live their world and share their frustrations to understand their needs for the system.
2. Think MVP not Kitchen Sink
MVP stands for Minimum Viable Product. Ask what is the smallest thing we can build first that demonstrates our solution would be valuable?
Work with your customers to identify their highest-value items in the product. Often the highest priority items are surprising, so ask not presume.
Create a prioritized backlog of features and a visual roadmap of what can be developed when based on team estimates. Build this functionality first to demonstrate value.
3. Prototype Concepts Cheaply
Developing software is an expensive way of verifying we understand our customer needs. So use paper prototypes to mock-up screens and websites first.
Rapid prototyping with hand-drawn paper designs is a collaborative process that customers can engage in too. This inclusion builds ownership and support.
Get your teams to verify understandings with quick prototypes before coding. Changes are quicker, cheaper, and the process of engaging the customer increases buy-in.
4. Engage the Team in Solutioning
Teams do not want to be handed task lists. Teams want to solve problems, delight customers, and deliver value.
Humans are hard-wired to get a buzz from problem-solving. This is why people do crosswords and sudoku puzzles in their spare time. We get an endorphin buzz to further our learning and evolution.
Present work as problems to be solved rather than task lists. Teams will enjoy their work more and be more productive.
5. Exercise All the Architecture
Issues can spring up in any new hardware or software component. Until we have proved things work, they contain risks of failure.
If we will need it at some point, then let’s try it out as part of the project execution to make sure there are no unforeseen problems lurking in there.
Deliberately test each component of a solution as soon as possible. Prove the connections work or surprises are found while we still have time to address them.
6. Prove it or Pivot
Not all ideas or products are a success. Collaborating with customers during development should let us know early on if we have a winner or a dud.
Sometimes the best outcome is a fast failure while we can divert remaining time and funds towards other initiatives.
Create review points to evaluate progress and benefits. Facilitate a frank conversation between sponsors and customers. Did we prove the product viable, or is it time to pivot towards something else?
7. Go with the Flow
Projects need initial estimates for approval, but these are inaccurate since they are based on information from when we knew the least about the project – at the start.
As the project progresses, it is important to transition from these initial estimates and plans to new ones based on actual rates of progress.
Use the number of features delivered and actual spend rates to produce new completion projections. Using the actual data flowing from the team builds the most accurate plans.
8. Courageous Transparency
Share information, good and bad, with stakeholders throughout the project execution. The one thing people like less than bad news is late bad news.
Sharing information throughout the project demonstrates the desired behavior. Teams that see project managers sharing their mistakes and questions are more likely to do the same.
Many project failures can be traced to communication failures. When we fail to communicate we set the scene for cascades of problems. So be transparent and share information.
9. Review and Adapt What Matters
No plan survives contact with reality. Once we get into our project, we will learn new information about the project and our team dynamics.
We need to review the evolving solution and how the team is working together. Is the product working as expected? Are we working together as best we can?
Every couple of weeks ask the team: what should we do more of? What should we do less of? Experiment with team suggestions. Keep what works, learn from failures.
Here’s to change…
Project plans and estimates might change, but by being transparent and using the team’s actual production rates to create new plans, they will be defendable and realistic. Often the business customers become the project manager’s most reliable allies, answering many of the questions about completion dates and quality.
Customers are the most potent salespeople. They have fewer ulterior motives and the most credible stories. Work with them earnestly, and even the most dynamic projects can become rewarding partnerships.
- Today’s Project Manager: 9 Tips For Effective Project Managementin 2020 - April 28, 2020
- PMI-ACP® Credential – What you Need to Know for Certification - July 5, 2018
- How to Study for Your PMI-ACP® Exam - April 2, 2018