8 Bad Habits – Creating and Maintaining Your Project Schedule

I have always believed that you can learn as much or more from challenges and problems on projects as you do from successes. It is amazing how much you as a project manager contribute to the project’s challenges (in a bad way). The project schedule is a good example of where a project manager can have the best intentions in the world, and yet they create a schedule that is difficult to understand and nearly impossible to maintain. The bad thing about a poorly constructed project schedule is that it is something you have to live with the entire project life cycle. I have been on more than one project where we decided it was best to have a “do over” on the schedule than continue to struggle along with the one we were using.

There are a handful of traps that project managers fall into when creating a project schedule, either because at the time it seems like their approach is a “shortcut”, or they don’t understand the scheduling tool well enough to know any better. These bad habits make the schedule difficult keep up to date to reflect progress on the project, as well as changes in the work to be performed. In addition, these bad habits make the schedule difficult to understand by key stakeholders (sponsors and team members), which usually results in the need to create additional tools and reports to communicate work assignments and provide project status updates. Below are the 8 bad habits that I most frequently encounter.

The 8 Bad Habits

1. Failure to Use MS Project – This first habit seems obvious, but it is amazing how many project managers use tools other than MS Project to create and maintain their project schedule. Many project managers create visuals of the project timeline using tools like PowerPoint or Visio for stakeholder presentations and believe this same visual can be used effectively to manage progress/work on the project. In addition, some project managers feel that MS Project represents “overkill” for their project, so they use tools like Excel or SharePoint Task Lists to maintain project tasks and work assignments. These tools are fine until you need to understand things like task dependencies, resource utilization, or overall progress (% complete).

2. Poorly Structured WBS – Many project managers start entering tasks into the project schedule without taking time to think about how the tasks should be organized in the context of a Work Breakdown Structure (WBS). The Work Breakdown Structure is what provides you with the ability to roll-up activities and track/report effort and progress by major project components. It is a good practice to ensure that the WBS is organized based upon the way work is planned to be completed throughout the project life cycle. A strong WBS allows you to closeout large segments of the schedule as your move through the project life cycle.

3. Unnecessary Constraints – Inexperienced MS Project users will often insert unnecessary constraint dates into the project schedule. Their logic is that they should just enter the date the task will start or finish. The problem with this logic is that when dependent tasks change, the task with the constraint will not move as well. There are times when a constraint is appropriate (e.g., external dependencies), however overuse of arbitrary constraints results in a lot of manual intervention when maintaining the schedule (or worse – incorrect reporting of task start/end dates).

 


 

4. Dependencies Tied to Summary Tasks – One of the “shortcuts” that project managers will use is tying a dependency to a summary task. This approach eliminates the need to maintain dependencies for each of the individual tasks in the group of tasks. The problem with this “shortcut” is as soon as one of the tasks in the group has a different dependency, the dates for the individual task will be incorrect because the summary task dependency takes precedence over the individual task dependency. In addition, it is difficult to understand where the actual dependency exists when there are dependencies tied to summary tasks.

5. Lack of Clearly Defined Milestones – Milestones represent events or points in time that are critical to the success of the project. A milestone is established in the project schedule automatically by creating a task in the schedule with “0 days” duration. It is a good practice to focus on milestone status in executive sponsor project reviews. It is difficult to understand significant planned project accomplishments without clearly defined project milestones in the project schedule.

 


 

6. Incorrect Resource Loading – Many project managers load resources into the project schedule to assign resources to tasks, with no attention paid to the work effort established for the task. Loading resources at 100% utilization for the planned duration for each task results in significantly overstating the overall work effort for the project. The work effort can be adjusted by entering the estimated work hours for the task or the allocation % for the resource.

7. Improper Set-up of Schedule Options – The Options maintained in the project schedule establish the default behaviors of the project schedule. Many project managers do not understand why certain information does or does not change when other fields are updated in the schedule. In most cases, the update behaviors are tied back to the default Options that have been established for the project schedule.

 


 

8. Poorly Organized Views – MS Project provides the ability to define views that are used to track different information maintained in the project schedule. In addition, these views can be defined in MS project templates to ensure that projects are reported in a consistent manner across the project office. Unfortunately this is functionality that most project managers do not use very effectively. Project managers attempt to overcome poorly constructed views by creating visuals of the timeline and resource utilization in tools such as PowerPoint.

Benefits of Good Practices

Applying good practices to create and maintain your project schedule will save you time and ensure that you are presenting the right information in an accurate manner to your stakeholders. The following are the specific benefits associated with good schedule management practices.

  • On-Going Schedule Maintenance – You will spend less time updating a project schedule that has been well constructed.
  • Presentations to Stakeholders – You will have the ability to present information to stakeholders as a byproduct of maintaining the project schedule (without using separate visuals of the schedule in other tools).
  • Understanding & Communicating Resource Requirements – Resource utilization information is available to understand and manage over or under allocation of critical project resources.
  • Enterprise Enablement – Use of good schedule management practices is a prerequisite of successful implementation of enterprise project management tools (e.g., Project Server).

Note from the Author:

First of all, I apologize to my readers for not posting new content on my blog for a little over a year. I don’t really have an excuse, other than you tend to go through “seasons” where you are more passionate and motivated to write about the things you see and do as a project manager. Writing a blog is like cutting your grass or cleaning your house. If you keep up with it on a regular basis the work is not too difficult, but as soon as you let it slip a bit it becomes much harder to get motivated to take on the bigger task at hand. I have recently been exposed to some new project management approaches and tools, so I am hopeful to keep up the momentum and post more regularly.

Secondly, my good friend, Tom Hoffmann, and I frequently joke about his less conventional approach to project management. In fact he takes great pride in frequently practicing bad habit #1. It is with a smile on my face that I dedicate this post to Tom’s Worst Practices (TWP).

Using MS Project to Manage Dependencies

The strength and integrity of your project schedule is built based upon the definition of deliverables and activities, the estimation of durations and effort, as well as the organization and sequencing of the work efforts. All three elements are important, but the one that I think project managers’ struggle with the most is organizing the deliverables and activities in a manner that reflects the way in which the work will actually be performed / completed. Organizing the work involves developing a work breakdown structure (WBS) that is arranged and decomposed in a structured manner, and sequencing the deliverables and activities based upon logical relationships (dependencies) between the deliverables and activities. This blog focuses on establishing and managing dependencies that are understandable and create a reasonable workflow. This discussion includes using project management tools like MS Project to efficiently define and managing dependencies within your project schedule.

Type of Dependencies

Understanding the types of dependencies inherent in the work that needs to be completed is one of the most important elements of creating a strong project schedule. There are 3 primary types of dependencies:

  • Mandatory Dependencies – These are dependencies that create firm relationships between two activities. Examples of this logic include:

    These two activities must be performed at the same time (starting and/or finishing at the same time).

    This activity cannot start until another activity finishes.

  • Discretionary Dependencies – These are “soft” dependencies that reflect how the team anticipates the work will be completed, or how the team “would like” the work to be completed. These types of dependencies enable the team to optimize the flow of work throughout the project life cycle. Most importantly, “soft” dependencies represent the tool that the project manager utilizes to create “float” in the schedule. This is a much more effective manner to drive the timeline than “hard coding” dates (artificial constraints) into the schedule. Examples of this logic includes:

    This activity will happen at the same time as another group of activities.

    This activity will start up a couple weeks after another activity is completed.

  • External Dependencies – These are dependencies that are outside the control of the project team, but nonetheless must be reflected in the project schedule. Examples of external dependencies include:

    Approval from an external organization must be received prior to starting an activity.

    Completion of a project milestone is linked to the completion of a milestone within another project.

Creating external dependencies within your project schedule can be accomplished in a couple different ways:

Insert a milestone that reflects the completion of the external dependency.

Insert a planning component (placeholder type task) that reflects the timing of the external dependency.

Link specific activities to activities in other project schedules (requires utilization of enterprise scheduling tools).

Dependency Relationships

Dependency relationships are utilized to link two tasks in the most logical manner possible. As in the case of dependency types, this relationship may represent a “hard” relationship (must happen in a certain manner) –or- a “soft” relationship (a relationship set up by the PM to establish a logical flow of the project activities). The valid relationships in MS Project are:

  • Finish-to-Start (FS) – This represents the default relationship in MS Project. If you do not specify the relationship, FS is assumed. This relationship is utilized to establish a sequential flow of work – this activity can start when the previous activity is completed.


  • Start-to-Start (SS) – This relationship is utilized when two activities will be launched at the same time. They may end at different times (depending on the duration of each activity), but they can start at the same time.


  • Finish-to-Finish (FF) – This relationship is utilized when the completion of two activities should be linked together. The two activities may start at different times (again, depending on the duration of each activity), but the completion of the two activities is coordinated.
  • Start-to-Finish (SF) – This relationship is seldom utilized (in 20+ years of using MS Project, I have never used a SF relationship).

In addition to establishing the relationship, predecessors and successors can be utilized to create leads (acceleration or overlap) and lags (delays or gaps) between schedule activities. Here are a couple examples of the appropriate use of lags and leads in the project schedule:

  • Lead: The technical design can be started after 75% of the requirements definition effort is completed. If the requirements represents a dedicated effort that will be completed over a 20 day period. The predecessor in MS Project for the start of the technical design would be reflected as: (n)FS-5D (where (n) represents the task number associated with the requirements definition effort).
  • Lag: The UAT test plans will be completed a week after the completion of the system test plans. The predecessor in MS Project for the UAT test plan would be reflected as: (n)FF+5D (where (n) represents the task number of the completion of the requirements effort).

Using MS Project to Establish Predecessors and Successors

Dependencies are created in MS Project using the Predecessor and Successor fields. The Predecessor is the task completed “prior to” the current task, and the Successor is the task completed “after” the current task. The dependency is entered with the ID of the Predecessor or Successor task, the Type of Dependency Relationship (FS, SS, FF, SF), and the Lag(+)/Lead(-) between the two tasks.

Below is an example of creating Predecessors and Successors within the MS project schedule.

Using the Predecessors & Successors Split view provides a good picture of the dependencies established for each task.

 

4 Tips for Effective Use of MS Project to Manage Dependencies

  1. Using Date Constraints – The most important take-away from this discussion is that establishing dependencies is the key to creating a logical flow (organization) of work within the project schedule. A “worst” practice is to hard wire dates (e.g., must start on, or must finish on date constraints) within the project schedule. As things change (and they inevitably will change) with regards to how the work is actually completed, these arbitrary date constraints quickly become inaccurate and difficult to maintain. They will impact not only the accuracy of the specific schedule activity, but also the accuracy of any subsequent dependent schedule activities.
  2. Using Summary Tasks for Dependencies – Another thing to avoid is linking dependencies to the summary tasks. During the first cut of creating the schedule, it may seem like a good shortcut if multiple activities are tied to the same set of activities, but ultimately this practice results in a schedule that is difficult to understand and maintain. All activities should be linked to specific activities, and not to summary tasks.
  3. Look for Activities without Predecessors or Successors – Activities should have both a predecessor and a successor, unless they truly represent the beginning or end of a project (or string of standalone activities within the project).
  4. Fully Leverage Dependency Relationship Capabilities – Dependency relationships (and leads/lags) are an aspect of creating a project schedule that should be well understood by the PM, and fully utilized. A project schedule that contains all FS relationships, and no leads/lags, is generally an indication that not a lot of effort has been put into understanding the activity dependencies, or the flow of the project work.

Using MS Project to Improve Project Performance

People often ask me what I find to be the most useful tool to perform my job as a project manager. I pause when responding to this question, because I prepare my share of presentations in MS PowerPoint, create many project deliverables in MS Word, manage my budget using Excel, and I have expressed in many blogs how to improve your project environment using SharePoint. However, because I view the project schedule to be at the core of good project management (my bias as a Time Management instructor shines through), I generally respond that MS Project is the tool that I rely on the most to do my job as a project manager.

In the enterprise project management space, MS Project Server has a lot of competition, but in the project management tool space it is my opinion that MS Project is by far best in terms of features, flexibility, and ease of use. The focus of this blog is how project management tools, specifically MS Project, can be used to improve your ability to manage project performance, from the perspective of becoming both more efficient and effective as a project manager.

Common Myths about using MS Project and Other Project Management Tools

  • I am too busy managing the project to deal with maintaining a project schedule – My response to this myth is that you are too busy managing a project to NOT create and maintain a project schedule. I have seen plenty of situations where the team has invested time and effort in a very extensive project schedule, and then they do nothing with it once they start progressing through project execution. This generally happens because the project manager does not know how to use MS Project to effectively progress and update the project schedule. The time required to create and maintain the project schedule pays for itself over and over throughout the project life cycle with the information required to understand and communicate what needs to be done when, and by whom.
  • It is just as effective and much easier to use Excel to manage the project schedule – I will admit that if you are creating a list of activities/tasks and assignments, Excel does the trick just fine. However, once you need to sequence that tasks, estimate durations and work, and load resource requirements, you quickly get beyond the capabilities of Excel. The time to required to set-up these capabilities in Excel would be much better invested in leveraging the robust out-of-the-box scheduling features of MS Project.
  • Non-project managers cannot understand MS Project – I agree that most non-project managers have a hard time relating to the details maintained within MS Project. Predecessors, durations, WBS are foreign terms to most non-project managers. However, MS Project provides the ability to tailor views of the schedule in ways that non-project management stakeholders find easy to understand and use. From my perspective, it is much more productive to create useful views in MS Project (one time), than spend the time to reenter schedule information into other tools for presentation purposes.
  • Does not work with iterative delivery approaches, only waterfall – Having been the project manager on plenty of Agile projects, I understand that there are additional tools utilized heavily to manage scope and measure progress (the product backlog and burn down charts). However, as a project manager you still need a project schedule to establish and manage overall timing related expectations. The schedule will not contain the details of the sprint, but it is utilized to put the sprints in the context of the other project related activities (e.g., product releases, training, and knowledge transfer).
  • MS Project has a mind of its own – I was mentoring a project manager one time who told me, “his tool had been compromised”. Admittedly, a certain level of complexity is a by-product of the features and flexibility of MS Project. Therefore if you are not familiar with how to create a schedule that can be easily progressed and updated throughout project execution, the project schedule becomes an enigma rather than an enabler. If you are not well versed in MS Project and/or the construct of your project schedule, the impact of updates to the schedule become difficult to understand and communicate. The simple answer to this myth is to get the training and mentoring required to be proficient using MS Project.

6 Ways MS Project Helps Manage Project Performance

1. Breaking down the work: MS Project provides the ability to easily capture and organize the WBS (Work Breakdown Structure). The use of indentation makes it easy to decompose the work from the highest level (project phases) to the lowest levels (tasks) of the project. In addition, the ability to collapse specific sections of the schedule allows you to focus on specific areas of the work breakdown. Some project teams prefer a graphical representation of the work breakdown. The tasks can be easily be imported/exported from MS Project to tools like Visio to support the desire to review a graphical depiction of the WBS.

2. Sequencing Activities: Dependency relationships are utilized to link two tasks in the most logical manner possible. The default in MS Project is Finish-to-Start (FS), but this may not be the relationship that most accurately defines the linkage between two tasks. This relationship may represent a “hard” dependency (this must happen in a certain manner), or a “soft” dependency (a relationship set up to establish a logical flow of the project activities). In addition to establishing the relationship, predecessors and successors can be utilized to create leads (acceleration or overlap) and lags (delays or gaps) between schedule activities. MS Project provides a lot of flexibility to ensure the Project Manager has the ability to sequence the work in a manner that reflects the way the work will be executed.

3. Creating the timeline: After the project activities, durations and dependencies are loaded, the schedule is starting to take on some shape and form. The Gantt view is one of the most effective tools for communicating the timeline associated with key summary tasks and milestones. Use the MS project filters to limit the tasks to those that convey the appropriate message.

4. Managing resource loading / utilization: The mechanics of loading resources into the project schedule is very straightforward. MS Project provides the ability to either load effort based upon estimated hours to complete or percent the resource is allocated to the tasks. In addition, the resource utilization view displays the effort planned for each team member and the ability to make the appropriate adjustments to “level” the resource utilization.

5. Progressing the project: Maintaining the project schedule throughout project execution is referred to in project manager speak as “progressing the schedule”. In MS Project the project manager has the ability to update the % complete, estimated to complete, and the actual effort worked. In addition, the project manager will make updates to duration & work estimates, dependencies, and tasks to ensure the schedule continues to reflect the way planned work will be completed.

6. Understanding project impacts: Upon completion of the planning process, a baseline “snapshot” of the project schedule is saved in MS Project. This baseline provides the ability to measure current schedule performance against the original plan to understand and communicate actual and planned impacts to the project schedule. These impacts are reflected in the schedule as variances that are captured for the start and finish dates of individual activities, summary tasks (i.e., project phases), and project milestones.

PM Foundations – Updating Schedule Progress

It always amazes me that after project managers put so much time and effort into creating a baseline project schedule, they do not always put the same level of energy and discipline into maintaining it during the execution phase of the project. It is extremely important during this phase of the project that the schedule reflects where you are at currently, as well as how the remaining work is planned to be completed.

During the transition from planning to execution the project manager establishes the progress update processes. These processes are both formal (e.g., submitting updates through a tool) and informal (e.g., soliciting input in one-on-one meetings). A productive project manager will ensure that these update processes are linked to other project related activities, such as time reporting, team meetings, and status reporting.

Progress Update Processes

The progress update processes and tools should fit into the way the team works. Try to avoid implementing processes that are disruptive or redundant. You do not want these processes to end up getting in the way of actual work being completed. In addition, these processes should be timely and consistent. The updates should be completed the same time/date during the reporting period (day/week). Team members should KNOW when information is due and when the schedule updates have been completed.

Based upon the organization and work environment, the project manager either establishes formal or informal processes and tools to collect progress updates. These processes and tools can range from weekly conversations with team members, to utilization of a tool for each team member to submit updates.

The key to this process is that it is linked to other project update activities (timeliness of information is dependent update establishing efficient processes):

  • Time reporting – Usually time reporting is at a higher level than required to update schedule activities, but at a minimum this process can be leveraged to trigger schedule update discussions.
  • Team meetings – Information shared at team meetings should be direct inputs for schedule updates (particularly on smaller projects).
  • Status reporting – It is up to the project manager to ensure that the status report is completed after schedule updates have been completed.

Performing Schedule Analysis

After completing progress updates to the schedule, it is a best practice to review the schedule data in a manner that proactively identifies potential issues. This review is utilized to identify areas where additional information and/or adjustments are required.

I will generally utilize the MS Project feature AUTO-FILTER feature to highlight potential project related issues. The approach helps focus in on specific problem areas:

  • Tasks that are NOT completed
  • Tasks that should have been started or finished already (past due), OR tasks that are scheduled to start or finish in the upcoming 1-2 weeks
  • Task assignments for specific resources (identification of resources that may be over or under allocated in the current time period

As the project manager you should be asking yourself the following questions when reviewing schedule related information:

Why are tasks past due? Most likely you will have run across the answer to this question when gathering progress updates from team members. If not, this is a good opportunity to follow-up with team members on the status of specific tasks. The answer generally falls into one of the following categories:

  • The task is taking longer than expected
  • Other tasks took higher priority
  • I could not start the task because I need another task to be completed first

Are actions required? Based upon review of past due tasks, as well as other tasks scheduled for the upcoming 1-2 weeks, you may identify problem areas that require immediate action. This is particularly true if delays (or anticipated delays) in the tasks will impact an upcoming milestone (or the project end date). Based upon discussions with the team, you may decide that one of the following actions must be taken:

  • Change resource assignments
  • Add a risk and initiate mitigation action planning
  • Change task dependencies to reflect new task sequencing
  • Add a task to reflect new work

Are schedule adjustments required? Some follow-up actions drive additional updates to the schedule. The bottom-line is that if the schedule no longer reflects how work will be performed, you should likely make additional updates to the schedule.

Making the Right Adjustments

Based upon completion of on-going schedule analysis, including follow-up research and discussion with team members, you will often identify adjustments that need to be made to one of the planning artifacts (schedule, issue / risk log, project management plan). The following represent considerations when making common adjustments to the schedule:

Resource assignments: Resource assignments may be proactive resource changes to avoid future problems, or reactive changes to respond to slippage in the project schedule. If material in nature, the resource changes should be made in the schedule. After the changes are completed, the project manager should review the resource usage to ensure that the changes solved the resource utilization issues as anticipated.

Duration / work estimates: When material differences in work effort or duration are identified (plan vs. actual progress), you should consider reflecting the difference in the schedule (particularly when there is significant work or time remaining to complete the task).

Tasks & dependencies: As work gets underway, additional tasks or task dependencies are identified that are required to complete the deliverable. These generally represent clarification of the work to be performed (vs. change in the deliverable to be completed). Again, if these changes are material in nature, and have not already been completed, you should consider reflecting these changes in the schedule.

Risks & issues: Review of the schedule based upon completing progress updates will often result in identification of additional risks or issues. This is the appropriate time to capture these risks/issues, and plan the appropriate actions to close or mitigate the risk/issue.

Project impacts: There is often a question around initiating project impacts based upon schedule changes identified. This topic is discussed further in my blog post on Managing Change, but the following represent the guidelines as to whether or not a project impact should be initiated:

  • Does this change have a material impact on the scope, schedule (end date), or cost of the project?
  • Is this a permanent change (or just a timing issue that will be resolved at some future point in the project)?

Updating Schedule Progress Best Practices

In summary, the following represent the primary best practices relating to updating schedule progress:

  • Establish a timely process (and supporting tools) to update schedule progress. The team should be well aware of how and when schedule updates will be captured, and when the schedule updates will be accurately reflected in the project schedule (to ensure team members are looking at the most current information).
  • Ensure that the processes for updating schedule progress are efficient for the project manager, as well as the rest of the team. Where appropriate, leverage existing communication vehicles or tools to capture this information (e.g., team meetings, timesheets, and personal status reports).
  • The process of updating schedule progress should regularly trigger the project manager to review the schedule to identify current or potential problems, and initiate the appropriate corrective actions.

Top 6 Project Management Best Practices

What about Project Management Best Practices

I do a lot of blogging about project management best practices. I firmly believe that it is the effective implementation and consistent application of PM best practices that differentiates successful projects from challenged projects. Best practices represent the practical application of the concepts, processes, and tools defined in the PMBOK® and other sources of knowledge. Project management is a very mature competency, and there is no shortage of resources to understand and define best practices, but the key lies in identifying the “critical few” that are key to project delivery success in your project environment. Below is the graphic that depicts the “critical few” included in Cardinal’s PM Foundations program.

Practical application of these best practices drives a consistent project management approach, and tangible business results:

  • Quicker ramp-up of project managers
  • Easier integration of projects in a multi-project environment
  • More productive project managers (not inventing processes and tools on the fly)
  • Equips project managers with tools to “fill the gaps” in the client environment
  • Better overall team performance – delivering on customer expectations (including measurement of performance)

These are the tangible business results that separate good project managers apart from “the pack”.

My Top 6 Best Practices

If I could only have 6 best practices to put in my toolkit as I ventured into a new project assignment (or mentor a new project manager), these are the ones I would select.

1. Project Organization: Forming the project team sounds pretty basic, but it is amazing how many project teams launch the project without performing stakeholder analysis, and defining the project organization. Important elements of the project organization include project sponsors, the core team, and understanding other key stakeholders. The use of a RACI is a flexible and effective tool within this best practice area.

2. WBS: The WBS defines the scope of the project and breaks the work down into components that can be schedule and estimated, and easily monitored and controlled. Simply put, a WBS is a deliverable oriented hierarchy that defines the work of the project, and only the work of the project. The use of facilitated WBS sessions represents a key technique within this best practice area.

3. Resource Loaded Project Schedule: The project schedule utilizes the WBS to define the activities, sequence, durations, and resources required to complete the project work. What does a good project schedule look like? Here are a few questions to help test your schedule:

  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?

4. Managing Project Change: Change is an inevitable element of managing a project – nothing works out exactly as planned. The project manager effectively manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. Nobody wants to be “that” project manager that leads a project that delivers on-time and under budget, but still has an unhappy customer. The following are the key aspects of this best practice area:

  • Definition of a change in the context of your project
  • Understanding the sources and early warning signs of change
  • Establishing a process to manage change
  • Measuring the cumulative impact of change

5. Measuring Performance: This best practice area involves keeping your eye on the appropriate project performance measures to proactively identify potential problems, and engage the team to identify and implement corrective actions. Measuring project performance includes schedule, budget, and supplier performance. Use of earned value to measure schedule and budget performance represents a tool within this best practice area.

6. Closing the Project: A best practice area that is often minimized or entirely over looked is project closure. At the end of a project, many project managers are busy preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project performance report (also referred to as the post-project assessment. Creating the project performance report includes gathering input from key stakeholders, and identifying improvement actions to be implemented for future projects.

PM Foundations – Creating a Strong Project Schedule

While teaching Time Management at the PMP Certification Class for the past two years, I often receive feedback about my passion on the topic of Time Management. This passion stems from my belief that without a good schedule that directly supports the project objectives (scope, time, and cost), the project manager will struggle to effectively deliver on customer expectations.

What does a good project schedule look like? Below are a few questions that help you test your schedule.

  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?

Although these steps are not completed in an entirely sequential manner, I do believe that a project schedule is created most effectively and efficiently based upon a very specific approach and sequence of processes:

1. Activity Definition – Starting with the Work Breakdown Structure (WBS) that defines and organizes the project deliverables into a logic manner, activity definition adds the detail work to be performed to create the deliverables. This process adds 1-3 levels of detail to the WBS, and provides the basis for estimating, identifying resource requirements, and tracking progress.

2.  Activity Sequencing – Activity sequencing establishes the relationship between deliverables and activities. This process defines both “hard” and “soft” logic in the schedule, that establishes the flow of the work to be completed throughout the project life cycle.

3.  Duration Estimating – Duration Estimating establishes the number of work periods required to complete schedule activities (reflected in work days). This process is utilized to create the first cut of the project timeline. At this point in the process the project manager is assessing the schedule for reasonableness, not perfection.

4. Resource Loading & Leveling – Resource requirements for specific activities are loaded based upon a percent allocation for resources, or “bottoms-up” estimates of work effort. Resource leveling is utilized to resolve resource usage conflicts and over allocation of specific resources.

5. Schedule Analysis – Schedule analysis is utilized to finalize the project schedule and create the baseline project schedule. The goal of this process is to ensure that the team can deliver on customer expectations with the schedule that has been created, and that the project schedule is fully documented and well understood by key stakeholders.

Leveraging best practices, the project manager ensures that a project schedule is efficiently created and is proactively utilized to successfully deliver on the project objectives:

  • Ensure that the appropriate schedule related defaults have been set-up within the scheduling tool. These defaults define work hours, holidays, and other key behaviors within the scheduling tool. A good example of set-up data that drives behaviors in the project schedule is the task type field (I recommend using fixed duration as the default task type)..

image 

  • Schedule related risks should be appropriately mitigated within the project schedule in the form of schedule reserves or contingencies. I find it most effective to explicitly document the schedule reserves in the project schedule.

image

  • Leverage dependencies in the project schedule to create a logical “flow” of the project deliverables and activities. Conversely, avoid arbitrary constraints (e.g., “must start on” or “must finish no earlier than”). As things change (and they inevitably will change) with regards to how the work is actually completed, these arbitrary date constraints quickly become inaccurate.

image

  • Before the first cut of the timeline is complete, milestones should be inserted into the appropriate points in the schedule. How do the milestones in the timeline compare to target dates that were established up-front (potentially committed dates from the project sponsors)? Are there actions that can be taken to close gaps between milestones and target dates?
  • There are several techniques that represent best practices during the final schedule review. Each of these techniques will help uncover opportunities to improve the schedule or reduce the risk, but can drive undesirable results if used improperly (see the chart below).

image