Knowing When to Pause the Project

Knowing When to Pause the Project

Written by : CPS Network


You always hope everything goes smoothly on your project and ends in utter success. But we all know from most studies and surveys that as many as nearly 60% of all projects end in failure to some degree. Maybe it's going over time frame, or going over budget, or just having an unsatisfied project customer. But if things seem to be going south and corrective action needs to be taken now... not later... you may have no other choice than to put the project on pause and investigate the root cause or have that discussion with the client as to what is going wrong. The earlier you find out, the less damage will be caused and the faster you can move forward to success.

Let's consider 5 scenarios where it may be very wise to pause the project and investigate and take corrective action before matters get worse...



Over budget


If the project budget is starting to go overboard it may be best to push the pause button. If you can figure out the bleed quickly and stop it or slow it enough then great. Fix it and move on. But often it is going to require investigation. Is your team charging $$ to the right project when they are working on three projects at one time?

We've all been there when it comes time to fill out the weekly time sheet and you know you worked 55 hours that week but you're not certain exactly where you spent all that time. Don't let your project be the project that the tech lead or anyone on the team charges all their “grey” hours to.

Any 10% overrun on budget can probably be fixed or is somewhat acceptable, but a 50% overrun is probably one you won't recover from. If numbers and dollars start to get out of whack, halt the project and figure out why. You won't be sorry you did and you may save the budge and the project.


More info needed for major decision


If something comes up that could cause catastrophic damage to the project then the experienced project manager is going to need to know when to make the tough decisions on the spot and possibly with less input than he would feel comfortable with and when to say “stop” and wait for the needed information or a gathering of the right people and stakeholders to help make that best and essential decisions.

Some decisions must be “now!” No matter what. But there are those times when you either have the option to pause the project or you have no other option than to pause the project. It’s almost always going to be better to add 2 weeks to the timeframe for the project than to let the project move forward with a potentially poor decision based on unreliable or unavailable information.


Requirements clarification


There are times on a project when you get everything just right. And there are times when it feels like maybe expectations have been incorrectly set. You feel that way... it may be obvious, or it may be something your getting through discussions with the client that just aren't matching up. Whatever the cause or feeling, transparency is the key to success here. Stop! Immediately.

Going down uneasy road without making absolutely sure you are on the right path is the worst move and can lead to expensive and time consuming rework. And depending on where the problem started or how the customer responds to the issue and assigns blame, it could be free rework without paid change orders. So if there seems to be a scope issue or a key requirement needs to be re-examined and clarified, do it immediately. Nothing good happens from procrastinating a discussion like this.


Additional training is necessary


This is a tough one, but especially if you're implementing a tech solution, there may be some training that the client needs in order to really successfully help you – as the delivery organization – understand the “as is” business processes and processing environment and the needed “to be” business processes and processing environment once the solution is rolled out to the end users.

If there is a disconnect on the customer's part on what the technology is and can do for them, there may need to be additional training for them that has to happen in order to properly capture requirements and / or write a detailed scope document.

In doing so, you may find that your business relationship has improved. On the other hand, you may also have "lost" time but it's usually worth it. At the end of a project, what matters is that the outcome serves its original purpose. If it does, then you've done your job, even if it took two extra weeks to achieve your objectives.


Communication is becoming an issue


As project leader, communication – excellent, efficient and productive (accurate, understandable and everything else thrown in) communication - is Job One. It is the case for all project leadership and really even team members as well. We need to know that everyone is on the same page every day, following every meeting, following every status discussion and every milestone and every deliverable.

Ask questions, communicate well and often and follow up to ensure common understanding on both sides.


Summary / call for input


It takes a wise - and bold - project manager to throw up their hands and say "stop!" forward progress. But it may be necessary and as project leaders you need to know when you need to step in and take that action to help save our floundering project. Project progress is everything, but knowing how and when and why to pause the project can mean the difference between failure and success.

Readers – what's your take? Have you had to halt a project and investigate and issue and take corrective action before resuming? Was it successful? Please consider and share your thoughts and experiences.