Project Restart Guide: 7 Areas to Document When Putting a Project on Hold

November 6, 2018

Project Restart Guide icon

Here’s the scenario: You have an important software implementation project that you’ve been leading and making good progress on. You are almost complete with the requirements definition phase when a data issue brings progress to a halt.  Because resolution will not occur for several months, the project Steering Committee asks to put the project on hold, allowing the team to work on other projects in the interim. After all, the team is experienced and knowledgeable – their reputation keeps them in high demand.

In 1965 Psychologist Bruce Tuckman defined the path to high-performance that most teams follow: “forming, storming, norming and performing”.

  • Forming – Learning about each other.
  • Storming – Challenging each other.
  • Norming – Working with each other.
  • Performing – Working as one.

Your team has worked on the project together and matured to where their journey has them at the “Performing” level.  When this project restarts, you want the team to pick back where they left off, not revert back to forming. As the project manager, you assess the potential risks of an extended project hold. Some of the risks include:

  • Loss of key team members – this requires replacing resources (team members) which may require lead time to obtain and require “Onboarding” and time to come up to speed.
  • Loss of project memory – the loss of “head” knowledge within the team about the inner workings of the project, including technical and process understanding.  Another loss of project memory comes in the form of a loss of an understanding of the history about key decisions.
  • Loss of project relationships – the network of connections within the team, as well as between the team and key external organizations and people. If there is significant turnover in the makeup of the team, the team may experience initial inefficiencies as they gel again into a mature team.

Now you consider actions that can be taken now to mitigate those risks. One of the best courses of action you, as the project manager, can take at this point is to put together a Project Restart Guide to ensure you’re well-prepared to successfully relaunch the project when the time comes.

There are seven key areas you should document in your Project Restart Guide.

1. Reasons for Project Hold

Fully document and list out in detail all the reasons for the project hold.  This includes dates, who made/communicated the information, and any context provided around why the decision was made. Capturing this information when it is first communicated is key, as it decreases the chances that information could be forgotten or misremembered. Why should you do this? So that you can accurately answer specific questions about why the project was suspended without needing to rely on recollections.

2. Contacts for Project Restart

Identify who is the single contact for project status during the hold and for initiating a restart of the project.  If the project involves multiple vendors, also list the key contacts for a project restart at each of the organizations. Why is this important? This formally establishes a network of knowledgeable leaders who can come together to restart the project at the right time.

3. Teams

List all of the existing team members at the time the project was placed on hold.  That includes:

  • Your Core team (Project Managers, Functional Leads)
  • The Extended team (IT, Marketing, HR, Finance)
  • The Business Unit key contacts that were involved
  • All other Stakeholders

When you do this, it is helpful to include full contact information and identify project role / expertise. If the project involves multiple vendors, also list the key people your team has been dealing with on the other side.  It is the people that make a project successful, and it can make a world of difference when you have the right people from vendor organizations working with your team.

Tip!  If a resource at a vendor does a good job, tell that person and tell their manager. In addition to giving them well-deserved recognition, you are more likely to work with that person again, and there is nothing wrong in asking for someone specific to be a part of your project team. If it is at all feasible given their workload, it’s highly likely their manager will accommodate.

4.  Adding New Team Members

If one or more of your original team members can no longer participate in your project, you’ll need to onboard new team members. Onboarding a new team member to the team is a critical process.  If this is done well, the team will reform and more efficiently achieve “Performing” status.

To help with this process, you can create a list of onboarding tasks that the new team member must do.  Include information on:

  • Access to project shared document repository sites and a list of documents to be reviewed
  • Access to training courses and a list of lessons to be completed
  • Access to systems required for project participation
  • Mentors / Job Shadowing
  • Lifelines – who to reach out to for help

5. Workflows / Next Steps to Restart

Define the main workflows within the project – such as Benefits, Time Entry, Payroll, Learning.  Don’t forget change management – it is also a workflow and will need to be restarted, too.

For each workflow, identify, in detail, the following:

  • Overview – high level description of status at time of hold and what must be done to restart.
  • Project Documents – where are the most current documents maintained for the workflow – Workbooks, Project Plan, Requirements, Signoffs. Provide URLs for these documents and specifically list key documents by name.
  • Open Issues – list out all open issues and action items. If you’ve documented those items somewhere else and don’t want to duplicate efforts, you can just reference where they can be found, such as in a Workbook.
  • Action Items to Restart – including steps. For example:
    • Changes that are updated in the workbook will be analyzed when team returns from the freeze
    • Review open issues log and risk register
    • New Team Members Onboarded
    • Schedule meetings – Kickoff and ongoing
    • Schedule and complete UAT and DILO (Day In the Life Of) Testing

Tip!  Prior to the project going on hold, it is very important that the team update all existing documents to the most current state.  Have the team also provide a list of pending decisions or actions that are not otherwise captured in the project documents. Most projects will have dynamic email exchanges/phone calls occurring that are not documented and would be lost unless that team member returns and can locate the email history. This is a really helpful step in preserving project knowledge.

6. Scope/Budget

Make sure to identify the location of most current statement/scope of work (SOW), document current budget status, and identify any change orders that will need to be assessed/established upon project restart.

7. Lessons Learned

If there are any lessons you’ve learned from the efforts on the project thus far, now is a good time to document those.  Consider the areas of Project Planning/Project Management, Training, Testing, Integrations, and Collaboration when you’re working on this.

In summary,  a good record of the project at the time the project was put on hold will serve you extremely well when it comes time to restart the project. Documenting key information in the areas of reasons for the project hold, contacts for the project restart, teams, adding new team members, workflows/next steps to restart, scope/budget, and lessons learned will leave you with a thorough Project Restart Guide.

HRchitect has worked with many different sized clients, industries, and systems, which gives us an expansive knowledge of best practices in managing projects that go on hold for a variety of reasons, and later start back. If you are ready to start an HCM implementation project, or restart a stalled project, talk to HRchitect to ensure that your organization gets the most from your system and that your investment continues working best for your organization.

Warren Phillips 

About Warren Phillips

Warren Phillips is a Senior Consultant and Project Manager at HRchitect. With over 30 years of experience in the training industry, Warren has led the implementation of training initiatives and Talent Management Systems for a wide range of commercial and government projects. He is also an expert in the technical side of training as well as an experienced training developer with a solid understanding of adult learning theories, instructional systems design, and user interface design for instructor led, self-paced and blended learning solutions.