Project management is the discipline of carefully projecting or planning, organizing, motivating and controlling resources to achieve specific goals and meet specific success criteria. A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverable’s) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent, or semi-permanent functional activities to produce products or services. In practice, the management of these two systems is often quite different, and as such requires the development of distinct technical skills and management strategies.
The primary challenge of project management is to achieve all of the project goals[5] and objectives while honoring the preconceived constraints. The primary constraints are scope, time, quality and budget. The secondary — and more ambitious — challenge is to optimize the allocation of necessary inputs and integrate them to meet pre-defined objectives.
The Project Management Process recommends three main deliverable’s be created before the actual work on the project begins. These are the Project Definition, project workplan, and the Project Management Procedures. The Project Management Procedures describe how the project will be managed, and are an effective way to communicate the processes to the project team, customers, and stakeholders.
Although they may seem time consuming to develop, in most cases these procedures only need to be created once. When you have a set of procedures that allow you to be successful, you can reuse them on subsequent projects. In fact, these procedures can be written at the company or organization level, and then used as the starting point for all projects in the company.
These project management procedures come from the process for large projects. They should be customized as appropriate for your project, your team, and your organization. In most cases, the processes should be simplified for smaller projects. Although this template is called Project Management Procedures, this document really describes processes. Processes are at a higher level than procedures. You can turn them into procedures by specifying the particular roles, people, and dates that make sense. For instance, take the step “The project manager will review the Scope Change Log on a weekly basis.” This can be made more specific by stating “The project manager, Sam Jones, will review the Scope Change Log by Tuesday noon of each week.”
Major Project Management Procedures
A-Workplan Review and Update Procedure
- Review the workplan on a regular basis. For a medium project, this is probably still a weekly process. For larger projects, the frequency might be every two weeks. Do not go any less frequently than every two weeks.
- Capture and update actual hours. If the project is capturing actual effort hours and costs, update the workplan with this information. Identify activities that have been completed during the previous time period and update the workplan to show they are finished.
- Review your schedule situation. Determine whether there are any other activities that should be completed, but are not. This information can be gathered by running the appropriate report from the project management tool. If there are activities that are late, work with the individual(s) who are assigned to see what is going on.
- Reschedule the project. After the workplan has been updated to show the current reality, let the tool reschedule the work to see if the project will be completed within the original effort, cost, and duration.
- Run additional workplan management reports. Run additional reports from the project management tool to help determine how the project is progressing. For instance, look at resource allocation.
- Review your budget situation. Review how your project is performing against your budget. Because of how financial reporting is done, you may need to manage the budget on a monthly basis, even if you update the workplan on a weekly or biweekly basis
- Look for other signs that the project may be in trouble. These could include:
- Activities start to trend over budget or behind schedule early on in the project. There is a tendency to think you can make it up, but usually these are a warning that you will get further and further into trouble.
- A small variance starts to get bigger, especially early in the project.
- You discover that activities you think have already been completed are still being worked on.
- You need to rely on unscheduled overtime to hit the deadlines, especially early in the project.
- Team morale starts to decline.
- Deliverable quality or service quality starts to deteriorate.
- Quality control steps, testing activities, and project management time starts to be cut back from the original schedule.
- Evaluate the critical path of the project.
- Adjust the workplan. Update the workplan so that it reflects how the remaining work will be completed.
- Communicate any schedule and budget risk. As soon as you feel at risk of missing your budget or deadline, you should communicate this to the sponsor and stakeholders.
- Add more details to future work. On a monthly basis, adjust future work to reflect any additional information you know now. For instance, when the workplan was created, many of the activities further into the future may have been vague and placed in the workplan at a high level. On a monthly basis, this work needs to be defined in greater detail.
B – Issues Management Procedure
- Solicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issue Submission Form.
- Enter the issue into the Issues Log.
- Assign the issue to a project team member for investigation. (The project manager could assign it to themselves.) The team member will investigate options that are available to resolve the issue. For each option, they should also estimate the impact to the project in terms of budget, schedule, and scope.
- The various alternatives and impact on schedule and budget are documented on the Issue Submission Form. Take the issue, alternatives, and project impact on the Issue Submission Form to the Project Sponsor and other appropriate stakeholders for a resolution.
- If resolving the issue will involve changing the scope of the project, close the issue now and use the project scope change management procedures instead to manage the resolution.
- Document the resolution or course of action on the Issue Submission Form.
- Document the issue resolution briefly on the Issues Log.
- Make the appropriate adjustments to the work plan and project budget, if necessary.
- If the resolution of an issue causes the budget, effort, or duration of the project to change, the current Project Definition should be updated.
- Communicate issue status and resolutions to project team members and other appropriate stakeholders through the 6. Manage Communication step, including the Project Status Report.
C – Project Scope Management Procedure
- Solicit potential scope change requests from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it will be formally documented using a Scope Change Request Form.
- Enter the request into the Scope Change Log.
- Assign the scope change to a project team member for investigation. The team member will investigate the impact on budget and schedule for various viable options. The team member will first determine how much time it will take to investigate the scope change request. If the time required to perform the analysis will cause deliverable dates to slip, the request must be taken to the Project Sponsor to determine whether the request should be investigated or not. If the sponsor gives the initial approval to proceed, the workplan and budget may need to be updated to reflect this new work. The options are documented on the Scope Change Request Form. If the Sponsor does not agree to investigate the change request, then the request should be placed closed as “not approved” on the Scope Change Log.
- (Optional). If the impact on project cost, effort, and duration falls below a threshold (say less than 20 hours) and the project will still be completed within the agreed upon cost, effort, and duration, the project manager and client manager may approve the scope change request. This threshold needs to be identified and approved in advance. The purpose is to keep from surfacing many small changes to the sponsor for approval.
- Take the scope change request, alternatives, and project impact on the Scope Change Request Form to the project sponsor for a resolution.
- Document the resolution or course of action on the Scope Change Request Form.
- Document the resolution briefly on the Scope Change Log. If the sponsor does not agree to the change request, then the request should be closed as “not approved” on the Scope Change Log.
- If the resolution is agreed upon, the appropriate activities are added to the workplan to ensure the change is implemented. The project budget should also be updated, if necessary. If the resolution is not approved, note it as closed on the Scope Change Log.
- If an approved scope change results in a substantial change to the project, the original Project Definition should be updated.
- Communicate scope change status and resolution to project team members and other appropriate stakeholders through the 6. Manage Communication step, including the Project Status Report.
D – Risk Management Procedures
- When you are defining the project, perform a complete assessment of project risk. The project manager can take an initial draft based on what they know and circulate it for additions/changes/comments. Another technique is to gather all the key stakeholders and discuss potential risks during a facilitated meeting. Also see the Risk Assessment Checklist template.
- Assign a risk level to each risk identified. The risk level should be high, medium, or low, depending on the severity of impact and the probability of the event occurring. Use the following table as a starting point. For instance, a highly likely/high impact event is obviously a high risk. However, each event must also be evaluated individually. If you have an event that is not likely to occur, but the impact, if it occurred, would be devastating (e.g., someone could get killed), you would still want to consider it a high risk and put together a risk plan accordingly.
| Severity of Risk Impact/Probability of Risk Occurring | Overall Risk Level |
| High negative impact to project/Highly likely to occur | High |
| High negative impact to project/Medium likely to occur | High |
| High negative impact to project/Not likely to occur | Medium/Low |
| Medium negative impact to project/Highly likely to occur | Medium |
| Medium negative impact to project/Medium likely to occur | Medium/Low |
| Medium negative impact to project/Not likely to occur | Low |
| Low negative impact to project/Highly likely to occur | Low |
| Low negative impact to project/Medium likely to occur | Low |
| Low negative impact to project/Not likely to occur | Low |
- Create a response plan for each high-level risk that you identified to ensure the risk is managed successfully. This plan should include steps to manage the risk, people assigned, completion dates, and periodic dates to monitor progress. There are five major responses to a risk—leave it, monitor it, avoid it, move it to a third party, or mitigate it.
- Evaluate the medium-level risks to determine if the impact is severe enough that they should have a risk response plan created for them as well.
- Look at any low-risk items and see whether they should be listed as assumptions. In this way, you recognize that there is a potential for problems, but because the risk is low, you are “assuming” that the condition will not occur.
- (Large projects) For every high and medium risk where the project manager is creating a risk mitigation plan, you should also create a contingency plan to document the consequences to the project if the risk plan fails and the risk actually occurs.
- Move the activities associated with the risk plans to the project workplan. Moving the activities to the workplan should help ensure that the work is actually completed and keeps the workplan the primary focus of all work planning and monitoring.
- The project manager needs to monitor the risk plans to ensure they are being executed successfully. New risk plan activities should be added if it looks like the risk is not being managed successfully.
- The project manager also needs to periodically evaluate risks throughout the project based on current circumstances. New risks may arise as the project is unfolding and some risks that were not identified during the 1. Define the Work step may become visible at a later date. This ongoing risk evaluation should be performed on a regular basis, say monthly, or at the completion of major milestones.
E – Communication Management
Larger projects should have a Communication Plan that guides the overall communication process. The Communication Plan can be included here as part of the Project Management Procedures.
F – Document MANAGEMENT
Large projects should have project document management procedures that describe how documents are created, stored, and shared. This is a part of the knowledge management process. So much of document management is dependent on site-specific tools and the particular project environment that a general set of guidelines is not possible. However, refer to the Manage Documents step for an understanding of what should be taken into account for the smooth handling of documents on a project.
G – Quality Management
Larger projects should have a Quality Plan that guides the overall quality management process. The Quality Plan can be included here as part of the Project Management Procedures document, or it can be created as a separate document.