In an age when project failure rates sadly top 50%, having the chance to actually restart a project that has been stalled, canceled or put on hold for whatever reason, can be a very positive thing. But it is definitely not with out great challenges. Often, the project manager asked to restart the engagement is not the same one that ended its previous iteration. It is worth noting here before we go any further that restarts - like 2nd marriages - are just as likely, if not more likely, to fail than the original engagement.
Considering project failures or work stoppages, they usually happen for one (or more) of three key reasons. These are:
Personnel issues
On a halted project that does get the chance to restart at some future point, usually 70-80% of the original personnel has changed since the last work stoppage, if not an entire personnel overhaul. Finding internal information on where the project stood may take some searching and definitely some due diligence on the part of the project manager and project team. At the very least, the project manager and key project team members are looking at a period of interviewing internal personnel prior to ever re-engaging the customer for discussion and project re-start activities.
Funding issues
Another key reason projects come to a screeching halt is often because funding has run dry. I personally led a project for a very well known government institution that had stopped one year previous. I then took over as the project manager with an entirely new team and even a new customer sponsor. With restart came new requirements and the data integration needs had changed, but the funding available had not. It wasn’t long before funding became and issue – and like my statement above about restarts often ending in failure – the project not surprisingly came to another point of work stoppage. Project budgets need extreme oversight and cannot be taken too lightly. Never assume that the customer has more money to spend or will come up with it just because they’ve already spent ‘x’ amount of money on the engagement. They may pull the plug due to funding issues at any time during the project.
Requirements issues
The third main reason why projects often get put on hold is due to changes or disagreements in requirements. It may be that the delivery team and the customer are unable to agree on and finalize requirements. It may be an issue solely within the customer organization – meaning changes at the customer’s site or with their end user needs may be turning requirements into a moving target. That type of situation obviously makes it impossible to move forward on the project without expecting to deliver a useless end solution. That scenario is something that neither side wants to see happen – thus making a work stoppage a much more viable solution at the present.
Steps to restart
It’s no small undertaking to restart one of these stalled projects. The project manager may tend to think that he and his team have nothing to lose since they can’t do any worse than the first team. Actually, nothing could be farther from the truth. This isn’t a scenario where you’re coming in as the Superman project manager trying to rescue a project that is in progress but is currently failing. I’ve been there – usually experiencing success and recognition, but not always.
No, taking over a stalled project that has been on the shelf for weeks, months, or more than a year is different. You often lack the type of up-to-date information that you would have if you were taking over a failing, but in-progress, project. You sometimes have very limited access to the previous project personnel. And your customer personnel may even be very different. However, they are still skeptical, all eyes are still on you and your team, the target is still on the project manager’s head, and expectations from senior management are high because they’ve likely gone through significant work to convince the customer to put the time, money, and effort into restarting the previously failed engagement. It’s one shot and you have to make it work. No pressure…right!
The restart process is basically a five-step process of trying to get your team, your information, and your customer in perfect alignment to resume work at a productive and efficient level. Let’s examine these five steps in detail….
Step 1 – Get knowledge transfer from the account manager
The first step to a successful project restart must start where the project likely originated – with the account manager or sales person that closed the deal with the customer. At this point, the project manager and team need to treat it almost like a new project and get the sales to delivery knowledge transfer and customer information that would likely happen with a new engagement. Learn the customer quirks, assumptions, preferences, and concerns from the person who met with them when everything was fresh, new and the project outlook was bright. Get the original sales materials, the draft project schedule, the original resource plan, key assumptions, report mockups, etc. – anything and everything that was mapped out as part of the sales process with this client.
Step 2 – Connect with the previous project team
Once you’ve managed to get all attainable information from the original sales person or team, it’s time to meet with whoever remains from the original project team. In this step, you’re looking for more of the same information as Step 1, but with the twist on what happened during the engagement to get the project to the point of work stoppage. Be careful, because there will likely be some damaged egos and frustrated project personnel who are wondering why they aren’t getting a second shot at this project (assuming they are still employed by the delivery organization).
In this step, it’s critical that your team acquire the historical documentation for the project. You’re looking for weekly status reports, any deliverables that were presented to the customer, notes from project status meetings, budget iterations, and as many iterations of the detailed project schedule as you can acquire as you try to piece together what activities were going on and how things were changing on the project.
Step 3 – Look at the failure points
Using information from the account manager and the original project team, piece the details together and examine what seem to be the project failure points. If it was a requirements disconnect, look at the status reports, iterations of the project schedule, and notes from the planning sessions to try to determine where things went wrong. If it was funding, look at the many iterations of the resource planning and budget status reports – assuming they are available (and they should be as part of the database of project status reports if you’re involved with a functional and organized PMO). If it was a personnel failure in your own delivery organization, you may not get the objective information you want from the first project team. That may have to come from the PMO director or – more likely – from the customer who you’ll talk to in the next step.
Step 4 – Engage the client
It may seem like placing the first actual discussion with the client in Step 4 is rather late in the process, but while there’s much fact finding involved in Steps 1 through 3, they really shouldn’t take that long. You’ll want to be working fast to get back on track with the customer because they have likely been built up with lots of hopes and dreams from your own senior management regarding the upcoming project restart. They are ready, willing and excited about talking to your new team – though it is likely that they are also carrying a decent amount of skepticism with them heading into this second iteration of the project. They’re going to be holding you to high standards and will be quick to pull the plug again if things are not going well in the early stages of the project restart. We’re assuming here that the problem was not likely internal with the customer – because if it were we would probably not be at a point of restarting the project.
Conduct a formal discussion with the client. But the first thing on the agenda must be a thorough listening session. You and your team have just spent the first three steps fact finding on your own. You must be careful not to go into this Step 4 telling the customer how it is. After listening to the client and understanding their perception of how the project was proceeding and why the work stoppage happened, then – and only then – do you begin to discuss what you’ve learned and the ideas you have about what went wrong and how to avoid those issues this time around.
Step 5 – Rework and rollout the project schedule and budget
As a progression of Step 4, we transition into Step 5 and actually work hand-in-hand with the customer to rework the project schedule for all remaining work, plan out the resources needed, and discuss the remaining project budget in detail. Of course, you and your project team have already done this internally and come into this customer discussion with the draft work already done and a starting point (or shall I say, re-starting point) for all three of these items. Look at this as a re-kickoff meeting of sorts where expectations are re-set, assumptions are once again documented, agreements are made with regards to deliverables, milestone dates, and project task responsibilities.
Summary
A carefully planned project restart – that begins by following these five steps – can be a successful undertaking. Nevertheless, it’s very important that you take nothing for granted. No matter how friendly the renewed relationship with the customer is, it has been strained in the past so leave nothing to chance. It’s important at the actual project work restart point following the kickoff (or re-kickoff) that you obtain a formal customer signoff on the many discussions and agreements you made during the project kickoff session. Don’t make one move toward actually restarting work on the project until the customer acknowledges in some written form that they are in agreement with your new project team on the project direction, schedule, statement of remaining work, and the planned outcome.
Considering project failures or work stoppages, they usually happen for one (or more) of three key reasons. These are:
Personnel issues
On a halted project that does get the chance to restart at some future point, usually 70-80% of the original personnel has changed since the last work stoppage, if not an entire personnel overhaul. Finding internal information on where the project stood may take some searching and definitely some due diligence on the part of the project manager and project team. At the very least, the project manager and key project team members are looking at a period of interviewing internal personnel prior to ever re-engaging the customer for discussion and project re-start activities.
Funding issues
Another key reason projects come to a screeching halt is often because funding has run dry. I personally led a project for a very well known government institution that had stopped one year previous. I then took over as the project manager with an entirely new team and even a new customer sponsor. With restart came new requirements and the data integration needs had changed, but the funding available had not. It wasn’t long before funding became and issue – and like my statement above about restarts often ending in failure – the project not surprisingly came to another point of work stoppage. Project budgets need extreme oversight and cannot be taken too lightly. Never assume that the customer has more money to spend or will come up with it just because they’ve already spent ‘x’ amount of money on the engagement. They may pull the plug due to funding issues at any time during the project.
Requirements issues
The third main reason why projects often get put on hold is due to changes or disagreements in requirements. It may be that the delivery team and the customer are unable to agree on and finalize requirements. It may be an issue solely within the customer organization – meaning changes at the customer’s site or with their end user needs may be turning requirements into a moving target. That type of situation obviously makes it impossible to move forward on the project without expecting to deliver a useless end solution. That scenario is something that neither side wants to see happen – thus making a work stoppage a much more viable solution at the present.
Steps to restart
It’s no small undertaking to restart one of these stalled projects. The project manager may tend to think that he and his team have nothing to lose since they can’t do any worse than the first team. Actually, nothing could be farther from the truth. This isn’t a scenario where you’re coming in as the Superman project manager trying to rescue a project that is in progress but is currently failing. I’ve been there – usually experiencing success and recognition, but not always.
No, taking over a stalled project that has been on the shelf for weeks, months, or more than a year is different. You often lack the type of up-to-date information that you would have if you were taking over a failing, but in-progress, project. You sometimes have very limited access to the previous project personnel. And your customer personnel may even be very different. However, they are still skeptical, all eyes are still on you and your team, the target is still on the project manager’s head, and expectations from senior management are high because they’ve likely gone through significant work to convince the customer to put the time, money, and effort into restarting the previously failed engagement. It’s one shot and you have to make it work. No pressure…right!
The restart process is basically a five-step process of trying to get your team, your information, and your customer in perfect alignment to resume work at a productive and efficient level. Let’s examine these five steps in detail….
Step 1 – Get knowledge transfer from the account manager
The first step to a successful project restart must start where the project likely originated – with the account manager or sales person that closed the deal with the customer. At this point, the project manager and team need to treat it almost like a new project and get the sales to delivery knowledge transfer and customer information that would likely happen with a new engagement. Learn the customer quirks, assumptions, preferences, and concerns from the person who met with them when everything was fresh, new and the project outlook was bright. Get the original sales materials, the draft project schedule, the original resource plan, key assumptions, report mockups, etc. – anything and everything that was mapped out as part of the sales process with this client.
Step 2 – Connect with the previous project team
Once you’ve managed to get all attainable information from the original sales person or team, it’s time to meet with whoever remains from the original project team. In this step, you’re looking for more of the same information as Step 1, but with the twist on what happened during the engagement to get the project to the point of work stoppage. Be careful, because there will likely be some damaged egos and frustrated project personnel who are wondering why they aren’t getting a second shot at this project (assuming they are still employed by the delivery organization).
In this step, it’s critical that your team acquire the historical documentation for the project. You’re looking for weekly status reports, any deliverables that were presented to the customer, notes from project status meetings, budget iterations, and as many iterations of the detailed project schedule as you can acquire as you try to piece together what activities were going on and how things were changing on the project.
Step 3 – Look at the failure points
Using information from the account manager and the original project team, piece the details together and examine what seem to be the project failure points. If it was a requirements disconnect, look at the status reports, iterations of the project schedule, and notes from the planning sessions to try to determine where things went wrong. If it was funding, look at the many iterations of the resource planning and budget status reports – assuming they are available (and they should be as part of the database of project status reports if you’re involved with a functional and organized PMO). If it was a personnel failure in your own delivery organization, you may not get the objective information you want from the first project team. That may have to come from the PMO director or – more likely – from the customer who you’ll talk to in the next step.
Step 4 – Engage the client
It may seem like placing the first actual discussion with the client in Step 4 is rather late in the process, but while there’s much fact finding involved in Steps 1 through 3, they really shouldn’t take that long. You’ll want to be working fast to get back on track with the customer because they have likely been built up with lots of hopes and dreams from your own senior management regarding the upcoming project restart. They are ready, willing and excited about talking to your new team – though it is likely that they are also carrying a decent amount of skepticism with them heading into this second iteration of the project. They’re going to be holding you to high standards and will be quick to pull the plug again if things are not going well in the early stages of the project restart. We’re assuming here that the problem was not likely internal with the customer – because if it were we would probably not be at a point of restarting the project.
Conduct a formal discussion with the client. But the first thing on the agenda must be a thorough listening session. You and your team have just spent the first three steps fact finding on your own. You must be careful not to go into this Step 4 telling the customer how it is. After listening to the client and understanding their perception of how the project was proceeding and why the work stoppage happened, then – and only then – do you begin to discuss what you’ve learned and the ideas you have about what went wrong and how to avoid those issues this time around.
Step 5 – Rework and rollout the project schedule and budget
As a progression of Step 4, we transition into Step 5 and actually work hand-in-hand with the customer to rework the project schedule for all remaining work, plan out the resources needed, and discuss the remaining project budget in detail. Of course, you and your project team have already done this internally and come into this customer discussion with the draft work already done and a starting point (or shall I say, re-starting point) for all three of these items. Look at this as a re-kickoff meeting of sorts where expectations are re-set, assumptions are once again documented, agreements are made with regards to deliverables, milestone dates, and project task responsibilities.
Summary
A carefully planned project restart – that begins by following these five steps – can be a successful undertaking. Nevertheless, it’s very important that you take nothing for granted. No matter how friendly the renewed relationship with the customer is, it has been strained in the past so leave nothing to chance. It’s important at the actual project work restart point following the kickoff (or re-kickoff) that you obtain a formal customer signoff on the many discussions and agreements you made during the project kickoff session. Don’t make one move toward actually restarting work on the project until the customer acknowledges in some written form that they are in agreement with your new project team on the project direction, schedule, statement of remaining work, and the planned outcome.
RSS Feed
