Month: September 2014

The Project Schedule Part 1: Overview

Professor of Project Management Project Planning ,

Planning

Now that you have a Project Charter, a Project Management Plan and a Project Plan, you can construct a detailed schedule. As mentioned in an earlier post, many refer to the Project Schedule as “The Project Plan”. Since the schedule does not detail how tasks are going to be accomplished it is not a plan. That is why we have a separate document for the Project Plan.

In the upcoming posts I will present the following topics related to constructing a Project Schedule:

  • Part 2: Schedule Tools
  • Part 3: Work Breakdown Structure
  • Part 4: Resource Assignments and Estimates
  • Part 5: Dependencies
  • Part 6: The Critical Path
  • Part 7: Schedule Adjustments (Crashing and Fast-Tracking)
Advertisement

The Project Plan Part 9: The In-Project Support Plan

Professor of Project Management Project Planning ,

Planning

The In-project Support Plan is needed if all or part of the solution is to be supported by a vendor or 3rd party. It addresses support needed during the project which includes the post-implementation stabilization period.

Here is a list of some things to consider (this is not necessarily the complete list of considerations; your project may have more):

  • Scope – describe the conditions in which this support is triggered.
  • Contact information – phone #’s, email, website, customer access id
  • Service Level Agreements (listed in order of severity, commits to how fast you can expect a response to a reported issue)
  • Problem and Status Reporting – what tools will be used, roles, responsibilities
  • Escalation Procedure if issues are not addressed in a timely or effective manner
  • Change Requests – for changes that are not bugs, define the request procedure & labor rate

This topic concludes the series on “The Project Plan”. In the next series of blog posts, I will address development of the Project Schedule.

The Project Plan Part 8: The Post-Live Support Plan

Professor of Project Management Project Planning ,

Planning

The Support Plan describes how the solution will be supported once operational. This includes a description of the support personnel and their roles as well as the processes to resolve problems arising within the solution boundaries.

Implementing a Support Plan is an important piece of Project close-out. The operational Stakeholders must be self-sufficient once the solution is live and no longer dependent on the Project Manager. Lack of a Support Plan is the primary cause of Project Managers being attached to projects for a long period of time after go-live.

Here is a list of some things to consider when building your Support Plan (this is not necessarily the complete list of considerations; your project may have more):

  • Support Resources, Roles, Responsibilities
  • Support model – define who will function as level 1, 2 & 3 support, how they will be contacted, and their staffing needs
  • Service Level Agreements (e.g. system availability, up-time, response time, etc)
  • Help Desk support
  • Vendor Support (support that will be purchased from the vendor) including naming the Stakeholders that will be the vendor support point of contact
  • Specialists (describe circumstances in which in-depth knowledge of the solution requires engaging specialists)
  • Product Updates – Who is responsible? Software vendors typically release updates multiple times a year. How often do we plan to apply them? Who will monitor changes in platform support?

The Project Plan Part 7: The Deployment Plan

Professor of Project Management Project Planning ,

Planning

The Deployment Plan describes the factors necessary for a smooth deployment and transition to ongoing operations. It encompasses the processes of preparing, installing, training, stabilizing, and transferring the solution to operations. For some projects, deployment can be very complex. For these types of projects it pays to start deployment planning as early as possible to manage the risk of delays due to deployment difficulties.

Here is a list of some things to consider for your deployment plan (this is not necessarily the complete list of considerations; your project may have more):

  • Scope
    • Stakeholders (those affected by the solution)
    • New and changed Business Processes
    • Licensing considerations
    • Approx. # components per platform
  • Deployment strategy & schedule (e.g. phased, site-by-site, push vs. pull, dept. by dept, etc)
  • Organizational Change Management
  • Implications of new and old system and processes in production at the same time
  • Deployment Resources
  • Help Desk Preparation
  • Desktops/Servers Affected
  • End User Training (High level business process and detail usage)
  • Installation Process
  • Installation Validation
  • Support during Stabilization
  • Hand-off to Support and Operations
  • Activation of Monitoring (for computer systems and business processes)