The Template Collective Blog

Project management templates… and more

Monthly Archives: December 2015

Project Time

Five Options for Project Start Dates

One of the characteristics of a project is that it is a temporary endeavor. In other words there is a start and end-date. This seems simple enough until you start to try to define exactly what these dates mean. Is it after the Project Charter is signed? Is it when the schedule is finalized?

There are no universally recommended definition for either date. It depends on each organization and whether there are any implications for choosing one alternative over another. Here are some of the options for identifying the project start-date.

  • The need/idea is generated. The definition you choose can depend on what the implication is. You may choose this definition of project start date if your company is trying to focus on the time it takes between when an idea is generated until the idea is fulfilled. Your company may be concerned that it takes too long to commercialize good ideas. If your company wants to minimize this total time span between idea and fulfillment, you might go with an early project start-date definition like this.
  • A budget is approved. In this definition, an idea has been generated and the idea has made it far enough that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year business planning process. The actual work may not start until the following year. Therefore, this definition may also start the clock too early for many organizations.
  • A project manager is assigned. This one is more common. The assumption here is that the project manager is the first resource assigned to a project. When the project manager is assigned, the project initiation and planning begins. This is the definition for project start-date in the TenStep Project Management Process.
  • The Project Charter is approved by the sponsor. In some organizations the project officially starts when the sponsor approves the Project Charter. Some companies require an approved Project Charter and schedule before the project team can be allocated.
  • The project kickoff meeting is held. Using this definition, the planning work is considered to be “pre-project”. The projects starts with a formal kickoff meeting with the major stakeholders and the project team. The kickoff meeting is the time to tell everyone that the project is ready to begin.

In some respects the exact definition of the project start is not as important as whether the definition is applied consistently. For example, if you wanted to compare the time it takes for two projects to complete, it is important that both projects use the same definition for start and end date.

Risk Management

Seven Components to a Risk Management Plan

The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually describe the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes:

  • Roles and responsibilities. This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a specialist. Third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the sponsoring project team.
  • Budgeting. Discuss your budget for risk management for the project. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
  • Timing. Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. Results should be developed early enough to affect decisions.
  • Scoring and interpretation. You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
  • Thresholds. The threshold level is how you determine which risks are important enough to act upon.  The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks.
  • Communication. Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status.
  • Tracking and Auditing. Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.

Other sections can be added to the Risk Management Plan as needed.