Or we could call it ‘Project Speed’ if you are a big fan of movies where objects that move too slow are reprimanded with high explosives. Either way, we are talking about a project management metric that is very helpful in identifying problems and adjusting milestones.
What you will need:
o A Project
o A team or yourself
o A task list
o Estimated hours
o A record keeping system (such as excel or crayons and paper)
What you will be doing to monitor a project’s or individual’s velocity is assigning an estimated task time to all the new tasks that may show up on your project. So first make sure that you have a list of all your known tasks and that you and/or your team has given a best estimate for time to complete them. Once this is done, go ahead and add up the total estimated hours and set that aside. For now, lets say that you came up with 100 hours of tasks.
Go ahead and work on the project for the day. Either at the end of the day or before working the next day, get the sum of project hours remaining and record that again. Lets say that the first five days yielded 104, 115, 103, 93, and 80 with two people working on the project.
In the perfect world you would assume that two people working a project would net you 16 task hours completed a day. As we all know, this will not happen or we would all be spending additional hours at work for meetings, side tasks, waiting for feedback, dealing with IT issues, delegating work, etcetera just to get the 8 hours of task work completed (wait a minute…) So, now that we have the remaining estimated work for the week, we can figure out the velocity daily or the average. Starting with the daily, the team seemed to have the following results; -4, -11, 12, 10, 13. Taking the average of those hours will give you 2 hours/day as your current 5 day velocity.
What does it mean though? This is where you will have to take a closer look at the data or have a meeting with the team. In this particular case, we gained hours on the project time during the first two days. After that we seemed to get what could be considered normal results. Possible causes of the velocity could be from any of the following: incorrectly estimated task hours, discovery of new tasks during project ramp up, poorly performing team, obstacles are preventing task work from being completed, failure to properly update tasks with remaining hours, or shared resources being used on the project. Some of those same reasons could also be the cause of a faster than expected project velocity. Alternatively, unique causes of a faster velocity could include the rapid closing of tasks toward the end of a project when estimations are not as conservative, resources performing above expectations or putting in additional time, or removal of tasks from scope.
Once you understand why your Project Velocity is what it is, you can now reforecast when your project milestones will occur based on the current performance. It will also help you identify if any of the issues mentioned in the prior paragraph are occurring so that you can fix them or congratulate the team for the good work. Keep in mind that you should see slower rates at the start of a project, where new tasks are being discovered and people are being conservative about how much time is required to complete tasks. Faster rates should occur towards the end of the project where tasks are being knocked out of scope or finished with better efficiency.
Try using this data for a project dashboard that shows current data, historical trends, and project goals! Bonus points if you work in a speeding bus!
