Basics of project estimations and scheduling

The way I was taught software estimations was that you do the following in sequence:

  1. Figure out all the work items/deliverables that your project is expected to generate (artifacts, manuals, final working code etc)
  2. Figure out the estimates for building each of those work-items
  3. Figure out the sequence/network for all the deliverables i.e which work-items have dependencies on others, which need to be built first, which need resources that are time-sensitive etc
  4. Lay out all the activities required to build each work-item.
  5. Lay out all the activities that need to happen to link the work-items together
  6. Lay out all the activities in a sequence including dependencies, resource-sensitivities etc
  7. Figure out the critical path for the project
  8. Write down each assumption you made in steps 1-7 above
  9. Get your team together in a room (if your team is more than 50, this may not work. Invite instead the team-leads)
  10. Walk the team through each of the work-items and activities.
  11. Ensure that each work-item has an owner — even if that owner happens to be you
  12. Delegate as much as possible — the PM on small projects is more of a “doer” role. On large projects, a PM is more of a “leader” role and in medium projects, the PM can be all sorts of combinations of the two. You decide
  13. Make sure you get your team to agree to the schedule and ownership. There will always be disagreement, but the team needs to have a plan to work around those disagreements before you leave the room — for very large projects, this could take more than one meeting…and that is OK
  14. Update the list of assumptions you made in step 8. Start identifying risks.
  15. Set the thing in motion
  16. Monitor, ask questions, collect data, report status, revise estimates, schedule, assumptions, risks

This is the gist of the planning part…this is more or less what the PMBOK will tell you. Yes, this is not an exhaustive list and yes, every project needs a slightly different approach. But you cannot be too far off this list on any project.

Congratulations, you are a PM !