10 tips for making a rock-solid project plan

Posted on

Is it possible to make a rock-solid project plan? All projects have risks. What you can do as a project manager is managing risks in the best possible way. If you do that you can make a robust project plan.

In this article I will share my best tips for making a robust project plan, using both agile and more classical project management techniques.

In other words, I will give my best shot at answering the question:

How do you make a robust hybrid project management plan?

The tips below could be used if you need to deliver a customized web portal or a smartphone app. But I am positive they can also be used in other scenarios.

Precondition for using the tips

You need to do some preparation before you can use the tips below: 

  • Execute the project initiation stage, where you capture the requirements for the project and get a clear definition of why you execute the project.
  • As a minimum you must have a backlog of requirements or user stories
  • Some of the tips assume you use Scrum and execute your project in short 1-4 week sprints. 

The article “Hybrid project management – manage by stages and sprints” outlines how to execute the initiation stage.

Tip #1 Include lessons learned

Make a list of the lessons learned you want to incorporate in your project. Use your network to collect lessons learned from similar projects. Consider what “lessons learned” you can include from your own previous project. 

If you decide to make an “incorporated lessons learned” list, you will ensure you consciously reflect on how you can harvest the experience you have access to.   

It is not only your list, maybe your team, the project board or even the customer can have valuable input for the lessons learned list. 

Tip #2 Tailor to fit the project environment

It will take weeks before you are done planning if you implement all the great ways of planning you can find in the project management literature. Hence, it is essential you tailor your planning and delivery approach to suit your project environment.  

If you deliver to an internal customer, you might not need to setup a rigid process for change management. On the other hand, if you have an external customer with a tight budget, you need to document changes and focus on prioritization.  

Tip #3 Three-point estimation

Estimate your project using three-point estimation. If you read the theory about this estimation technique you might think it is very complex. But in fact, it is simple to use. Just follow these steps: 

  1. Find a good excel template for doing three-point estimation or make your own.
  2. List all the user stories or the requirements that you need to deliver.
  3. Add other work to the list. E.g., fix bugs found under user acceptance test, prepare go live, hyper-care, time for Scrum rituals, automated test, documentation, Scrum master time, project manager time.
  4. For each item on the list estimate hours for best-case-, most likely- and worst-case estimate.
  5. Decide if you want to use the estimate with 50%, 68%, 90% or 99,7% confidence.

If you select 50%, you have a 50% chance of not delivering on time. If you select the 99,7% I think you will have a hard time getting your budget approved. Hence, you must select something in between 50% and 99,7%.

Tip #4 Use two estimation techniques

It is very hard to predict the future. You will most likely not have foreseen everything in your three-point estimate. Therefore, I will recommend you use two estimation techniques.

A good candidate for the second estimation technique is “Comparative estimation”. This technique is quick to use.

You compare your project to a similar project that has already been completed. Estimate how many times bigger or smaller your project is compared to the old project.

If your project implements 10 new user stories, and the old project implements 20 user stories you could argue that your estimate should be 50% of the actual cost of the old project.

If the outputs from the two techniques are similar you don’t need to do anything. If the second estimate is higher than your first estimate, you might need to go back and find out what you missed in your three-point estimate.

Tip #5 Prioritize the backlog

The simplest way of mitigating risk is to prioritize the backlog. To do this you ask the customer what the most important requirements are, and then you develop them first.

You can also use the MoSCoW method, where you ask the customer to prioritize the backlog with one of the following priorities:

  • Must have
  • Should have
  • Could have
  • Won’t have (this time)

If you experience that the customer wants to set all requirements to “Must have”, it indicates that there is no flexibility on scope. In this case you should be very cautious on what agile techniques you deploy.

Bonus tip: If your project contains technology that is new to your team, you could consider starting the project with a proof-of-concept sprint. If you don’t manage to prove the new concept you can stop the project with a limited loss. 

Tip #6 Plan sprint where you do nothing

Plan that every sixth sprint is not used on developing new features. When you reach the “no-planned-development” sprint there are two possible scenarios:

  1. There are no major issues, hence you can use the sprint for education and documentation.
  2. You have issues and have not completed as many uses stories as planned. In this case you should use the sprint for catching up to the original plan.

Tip #7 Contingency budget

You must include a budget for contingencies. If you have the privilege of having a stable experienced team that work in a known domain, and you use known technology, the contingency budget could be as low as 10%. But you will most likely have to pick a higher number, because there are known unknowns and unknown unknowns.

Three-point estimation can give you good input for how big your contingency budget should be.

Tip #8 Budget for minor changes

During the project, your customer will always get new ideas, when they see what you have built.

If your scope is defined with full user story descriptions with acceptance criteria, I will recommend you add 10-20% to the project budget for minor changes/improvements.

This budget can be managed by the customer or the product owner.

The budget can also be used when it is unclear if a detailed requirement is part of the original scope.

If you decide to add a budget for minor changes you will reduce the number of small scope issues you need to escalate to the project board.

Tip #9 Risk analysis

Every project is unique, and it has its own risks and opportunities. If you follow some of the tips above, there are still risks that might occur. Therefore, I will highly recommend you involve some of your key stakeholders in a risk analysis. After the risk analysis you need to update your plan with the actions you have agreed to reduce-, avoid-, or share risk.

Tip #10 Build a dream team

The products your project deliver is delivered by the project team(s). Hence, making sure the project has a high-performing stable team is one of the keys to delivering a successful project. 

See yourself as a sports coach that need to establish and build the best possible team. When you have the team in place focus on getting the best out of your team’s potential.

Full-time allocation of the core project team will give you the highest chance of fast and efficient development. 

If your team is new to the domain or technology, consider bringing in an expert that can be part of the team in a period.

Not only the delivery team is needed. You need to make sure the product owner or business subject matter experts are allocated to the project. You need them for refining the requirements, testing the deliveries, and maybe also for training the uses.  

Trying to execute a project, without the needed skilled resources, is like trying to win a formula 1 race with limited or bad quality fuel.  

Final note

I hope you find some of the tips useful. What are your favorite tips when you plan a project?

References / further reading