This Is How To Develop An Effective Project Plan — Part 2

A series about project planning essentials: breaking down a project into smaller tasks, identifying team roles, understanding development effort and estimations.

Personally, early in my career as a Product Manager I found it difficult to determine an accurate timeframe for completing a project, yet it was not my first time struggling with this.

When I was a web developer, I also found it very hard to determine the precise time it would take to finish a project. Some project managers I encountered would add extra time to my estimations by guessing, without having a level of certainty.

This sort of planning baffled me, because when road blocks started to arise, the developer was the one to blame. When I became a Product Manager, I hoped to avoid these situations and try to understand estimations from developers to come up with a good plan.

What you’ll find in this guide:

• Breaking the project into smaller tasks 📋

• Identifying team roles and responsibilities 👥

• Estimating development effort 🏃

  • Simple and easy estimation techniques

If you missed the part 1 of these series just read it here 👇👇👇

Breaking the project into smaller tasks

To break the project in smaller tasks it’s important to identify what kind of project it is and the different phases involved. This will help to decide what would be the best strategy to follow, if Product Breakdown Structure (PBS) or Work Breakdown Structure (WBS).

Product Breakdown Structure (PBS):

A PBS is a tool for analyzing, documenting and communicating the outcomes of a project, and forms part of the product based planning technique. It represents the product or the final outcome of a project and its components. It breaks down the project deliverable into smaller components, depicting them in hierarchical structure. PBS focuses on what needs to be delivered.

For example, let's consider creating a website. In PBS, we consider the structure of the website, like Homepage, About us Page, Contact us Page, and so on.

Work Breakdown Structure (WBS):

On the other hand, WBS focuses not only on the final output but also the tasks and efforts needed to deliver that output. It represents tasks and activities involved in a project. It helps in defining the total scope of the project, breaking it into manageable tasks, developing cost and time estimates for each task, and setting responsibilities for each task.

Continuing the example of implementing the website. In WBS, we consider the tasks involved, like designing Home page, coding Home page, testing Home page, same for About us Page, Contact us Page, etc.

Helpful Tips:

• Keep the WBS deliverable-oriented, instead of activity-based or department-centric, to focus on the project's final outcome.

• Use visual aids like flowcharts, mind maps, or software tools to create and present the WBS effectively.

• Update the WBS as needed throughout the project lifecycle to accommodate changes or newly discovered tasks.

Identifying team roles and responsibilities

Identifying team roles and responsibilities is crucial for effective project planning. Each of your team members should have a clear understanding of their role and responsibilities to ensure smooth collaboration and accountability.

To identify team roles, start by listing all the tasks and activities that need to be completed for the project. Then, assign each task to a specific team member based on their skills, expertise, and availability. Consider their strengths and weaknesses to make sure the right person is assigned to the right task.

A great tool for this is the RACI matrix. This matrix is a helpful for defining team roles and responsibilities. RACI stands for Responsible, Accountable, Consulted, and Informed.

• The Responsible role refers to the person or team who is responsible for completing the task. They are the ones who will be doing the actual work.

• The Accountable role is the person who is ultimately accountable for the success of the task or project. They have the authority to make decisions and ensure that the task is completed successfully.

• The Consulted role includes individuals or teams who may need to be consulted or provide input during the task. They may have valuable expertise or knowledge that can contribute to the success of the task.

• The Informed role refers to individuals or teams who need to be informed about the progress and outcome of the task. They may not be directly involved in the completion of the task, but they need to be kept in the loop to ensure effective communication and alignment.

RACI Matrix Tool for Team Roles and Responsibilities.

Remember, it's important to communicate the roles and responsibilities clearly to each team member. This can be done through meetings, emails, or project management software. Make sure everyone understands their role and what is expected of them.

Estimating development effort

Have you been the authoritarian product owner who gets mad at engineering for delivering late constantly? And just to discover estimations were right from the beginning but somehow you still missed the target.

Estimating development effort is a critical step in project planning. When you start learning about planning, it’s easy to fall in the trap of calculating the total amount of hours of availability for each developer. Let’s you have 3 developers working 8 hours from Monday to Friday, then that is:

8 hrs * 5 week days * 4 weeks a month * 3 developers = 480 working hours for the project

This is a great recipe for disaster! Setting up a deadline that engineers will hardly meet.

Product Managers at the intersection of balancing engineering efforts with what stakeholders want.

A software engineer is not going to dedicate 100% of his time to develop a product feature.

Take into consideration engineers have other activities:

• Part of their time goes attending meetings and ceremonies.

• They may be working in solving bugs or technical debt.

• They may need time to learn how to resolve what you need.

• There’s also Holidays and their vacations.

• They need time to document and monitor systems.

• They also spend time managing their tasks and writing technical specs in your project management tool.

• They need to refactor and test their own code.

• Also, is their time split into multiple projects?

Remember, team capacity is dynamic; team members may join or leave, get sick, take a holiday, etc. So it's vital to update your plan regularly and be transparent.

Question for you: How do you estimate developers work?

Here are some tips for estimating development effort:

• Use historical data and past experiences to gain insights into the effort required for similar tasks

• Involve the team in the estimation process to ensure a collective understanding of project requirements

• Consider external factors that may impact the timeline and effort required

• Regularly review and update estimates as the project progresses to ensure accuracy and keep the project on track

Simple and easy estimation techniques

Use any of this estimation techniques on your favor to help your engineering team determine an accurate estimation. There are various estimation techniques that can be beneficial, such as:

• Planning Poker: An agile estimating technique based on consensus. Team members make estimates by playing numbered cards, with the goal of convergence of opinion.

• T-Shirt Sizes: A simple and effective technique where tasks are categorized as XS, S, M, L, XL.

• The Bucket System: A much quicker Agile estimation technique with larger groups.

And there’s more estimation techniques like Three-point, Bottom-up and Parametric. It all depends on what it’s more convenient to the project and the team you have. Personally, I like Planning poker because it’s easy and the team have fun with it. If you want to give it a try here is a free tool: https://planningpokeronline.com/

Are you liking this series so far? I’ll be delighted to read your experiences into project planning and how you estimate engineers effort. We can always learn from each other! Happy planning 🚀