How to estimate project time and resources
How to estimate project time and resources
When a Project Manager is presented with a project and asked “Can you do this?”, “How long it will take?”, “How much resources will you require?” his immediate answers can only include that to question one, going like: “I think so”. To answer the other two questions, he will need time.
Now, to calculate the time and resources needed to complete a project, we need a detailed plan involving all the tasks, estimates, required budget, team members, taking into account their skills, expertise and so on. To simplify this formula, we can combine most of the criteria and get this:
- Number of tasks needed to complete
- The duration of those tasks
- The number of team members working on those tasks
What’s good about this formula from a project manager’s perspective is that all the three questions can be effectively answered, if the exact number of tasks is known. In other words, if you’re experienced and know your team well, you can pretty easily tell how much time each task will take to complete and how many team members you need to work on those.
This is where Top-Down and Bottom-Up approaches step in. While the calculations can be made using either of the two, there are a number of differences between them and each should be used in a corresponding scenario for maximum effect.
For those who don’t know:
“Top-Down approach focuses on the main project deliverable and breaks it down into smaller chunks of work needed to be done, until, finally, all the to-do tasks are clear.” – This is usually performed by the PM and the details of the small tasks get cleaned up by the team.
“The Bottom-Up approach focuses on the team members resolving all the phases and tasks of the project to form the end deliverable” – This is performed by the whole team right off the bat (under the supervision of the PM) and all the small details are taken care off from the start.
The Top-Down approach works well if the project is clearly defined, has a clear end goal and there are previous examples of such projects that a PM can use a guideline. All this information allows a PM to quickly define the major tasks and break those down into smaller chunks of daily tasks.
This approach is suited for cases when you don’t have a lot of time to answer the ultimate question “how long will it take?”, and at the same time, have a lot of data to work with.
Though the Top-Down approach can be useful in terms of quick (and pretty realistic) time and budget estimations, there will most certainly be problems that will come up somewhere in the process of doing all the tasks. The thing is that it’s impossible for a PM to singlehandedly think about all the details, since obviously, no PM is equally strong in all aspects of a given project.
Here is an example:
Suppose you have a project to upgrade your product’s hardware and software layers. Since this kind of stuff has been done in the past, you know you’ll need:
- A bunch of new servers
- Create the updated operating system
- Install the new system on those servers
- Install the latest product version
Since you know all the major components, it will be quite easy to break those down into smaller, day-to-day tasks and assign those to team members. What you might not know though, is that the new operating system doesn’t work with your product because of API integration problems, or library issues, or it might mess up user information security and what not.
These problems will most probably be discovered in the process by team members and, depending on their size, mess up both your time and cost calculations. In the end, you will have to take more time to complete the project than you previously estimated, and more resources as well.
One could argue that it’s not the PM’s fault and this is a pretty common thing in the project management world, but hey, I doubt anybody’s going to listen.
“You said August 2016. It’s already September and the project is not even close to done yet.” – This is what you will get most of the time.
Unlike the Top-Down approach, Bottom-Up will involve the whole team in the process of defining the tasks needed to complete a project, allowing to consider all the details that a PM might not know about, and come up with a much more specific figure.
Using the example above, the whole team would brainstorm about it, and the guys responsible for quality assurance and security would probably think about the potential issues (or at least make a task to test), thus helping their PM out and making sure there will be no unexpected stuff coming up out of nowhere.
On the downside, this approach will require significantly more time to answer the ultimate question “how long will it take?” and, since all the team members are actively involved in the brainstorming process, it offers less control over the project.
This approach should be used when you are on no tight deadlines (or at least have enough time to carefully plan and analyze everything), and will also help encourage teamwork within the organization by allowing much more freedom to team members. It’s also a good approach if you, as the PM, don’t have any past, similar projects to use as a guide and are completely new to the sphere.
Once you have the number of tasks, depending on the method you chose to go with, you can now decide how much time, resources and budget they will require to be completed.
Again, with Top-Down, you will be able to get the answers quickly, but there will be some inevitable estimation errors, since the details of the tasks are yet to be figured out. With Bottom-Up, you will be able to come up with a most accurate answer, but require significantly more time to do so.
Choosing the right approach
Of course, stakeholders, PMs and investors all want to have accurate cost and time figures, but the level of accuracy must be balanced with the other needs of the organization. Prioritizing your priorities will come in handy here as well. If time is of the essence, Top-Down might be the best way to approach a project, while when precise figures are more important, Bottom-Up could be the way to go.
Since we live in a real world (sadly), I am pretty positive that, most of the time, neither of the above mentioned work on their own, so using a mix of both methods might be a good solution. For example, you could break down the project into a few phases and implement Top-Down for the phases you know everything about, and ask your team to brainstorm on the ones you feel uncomfortable with.
Plus, this way, maintaining project control will be a lot easier than if you simply throw everything into your team’s hands. Don’t get me wrong: I’m sure all of them will try their hardest to come up with the best solution, but when too many people are working on the same task without any control, things are bound to go out of hand sooner or later.
What are your thoughts on those two approaches to project management? Tell us about your experience and how you handle different projects, we are dying to know!