Month: June 2020

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 and where tasks are going to be accomplished, it is not “the plan” but is a component of the complete 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? How will it be tested? What is the roll-back plan? Who will monitor changes in platform support?
  • Include both one-time and ongoing costs for the items listed above

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)

The Project Plan Part 6 – The Pilot Plan

Professor of Project Management Project Planning ,

Planning

Some organizations define a solution “pilot” as a “limited deployment” for the purpose of managing risk. That can be covered in a Risk Management Plan in lieu of a Pilot Plan. The definition we will use in this post is to use a Pilot to gather information about the solution that can only be discovered by “going live”. The intent of the Pilot is to obtain the information and then pull the solution out of the live environment for additional work.

The Pilot Plan describes what aspect of the solution will be delivered as a pilot and provides the details necessary to conduct the pilot successfully. This includes details on how to evaluate the pilot, the results of which will facilitate a decision whether or not to move the solution to production. Projects often create one or more “pilot” solutions for the purpose of proving the feasibility of solution approaches, experimenting with different solutions, and obtaining user feedback and acceptance on proposed solutions. Pilot solutions usually implement only those subsets or segments of requirements or functional specifications necessary to validate a solution.

The Pilot Plan provides the means to validate business requirements and technical specifications prior to deploying the solution into production. Planning the details of the pilot ensures that the participating project teams identify their roles and responsibilities and resource requirements specific to pilot development, testing, and deployment activities.

A pilot can provide key information on development processes, end-user validation, and production environment usage. It also provides feedback to stakeholders regarding the success of the solution once it is formally released.

Note that Pilot Plans are not just for IT projects. For example, fast food chains will often test new menu items for a limited time in a small number of locations to gauge consumer interest and test the store’s ability to deliver the product successfully.

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

  • Overview – Scope (what part of the solution will be demonstrated as part of the pilot, and the target user profile used to select which users will participate)
  • Success Criteria and Metrics – The success criteria may fall into the following categories:
    • System performance
    • Operations cost
    • Stability –down time
    • User performance
    • User satisfaction
    • Business goals
  • User Preparation and training
  • Marketing Plan – how users will become aware of the pilot and the value to them
  • Conditions for adding additional users
  • Rollback – conditions for rolling back the pilot to pre-deployment state
  • Pilot Evaluation – describes how the pilot results will be evaluated