Creating a Project Schedule

Posted by Gabrielle Guerrera on Thu, Jul 22, 2010

creating a project scheduleOne of the must-have skills for a project manager is the ability to oversee technical projects for which you have little or no specialized technical knowledge. For experienced and new managers alike, difficulties arise when creating a project schedule and you have limited knowledge of the inner workings of a new software package, how to go about developing a selected application, or the time it may take to successfully address all of your client’s support needs. Even in these circumstances, is it possible for you to successfully create a well-defined schedule that gives management and sponsors an accurate picture of when their deliverables can be expected? To that question I give a resounding “Yes!”, and here’s why:

 

1) The role of project manager comes with its very own support team. 

There are a few major inputs to project scheduling that your skilled support team should help you to develop to ensure that you aren’t flying blind through the project life cycle. Here are a few examples:

  • The Activity List – Your technical team can help you to break out each business requirement into related system requirements and lower-level tasks for completion.
  • Activity-Scope Relationship – You and your business analyst (may be one and the same on some engagements) can tie each activity on your list back to original business and scope requirements to make sure there are no gaps in your delivery.
  • Activity Duration and Sequence – Again, your technical team will assist in estimating how long each activity will take to complete, whether that task is design, development, or testing.
  • Resources Required and Availability – Functional managers in a matrixed organization will work with you to determine which developers, architects, testers, etc. will be available to you and when so that you can sort out your project’s plan accordingly.

 

2) Project planning is an ongoing, iterative process. 

The project schedule is not a fixed, immutable document. It will often change slightly here and there to accommodate the following:

  • New task duration estimates
  • Issues encountered during design, development, or testing
  • Scope changes initiated by the customer
  • A more thorough risk analysis

Because of this nature of the schedule, there are no expectations of absolute perfection. With the help of technical experts and other support team members, you can use the inputs above – resource availability schedules, the generated list of activities, along with their durations and sequence – to develop a baseline. This baseline indicates planned start and end dates for project milestones and is used to track your team’s progress towards project completion.

As project manager, it’s your job to see the entire field of play, leaving the bulk of the technical details to subject matter experts, so that you can maintain focus on the big picture and make schedule tweaks where necessary to accommodate variables. Simply make sure to manage stakeholder expectations by maintaining a consistent plan of communication so that everyone understands the impacts that slight schedule changes can have on other dependent plans.


If you love food as much as I do, you can liken this support/lead relationship to the support a head chef gets from his kitchen staff: sous-chef, saucier, grill chef, pantry chef, pastry chef… and on, and on. While the head chef is the one in charge, he couldn’t produce as fine a result without his assistants, experts in their own right in their respective fields. Too, what chef doesn’t oversee each station and make changes to his dishes along the way? The same will be true of you as you keep an eye on overall delivery of your project and make room for changes as you go.


Since project estimating can be done in several different ways, what specific advice is there for you as you estimate tasks along with your technical team? The IT Project Blog will publish its next article on three different methods of project estimating: high-level feasibility analysis, top-down estimating, and bottom-up estimating.

Topics: Project Planning