Knowing When to Pause the Project

Knowing When to Pause the Project

Written by : Brad Egeland

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. I realize that. 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. That happened to me on a project that was handed to me by sales and clearly when I sat down with my business analyst and the customer during functional design the customer was lost and my business analyst was actually in tears between sessions because we were getting nowhere. I had no other choice but to stop the project, get the customer up to speed with some free – yes, free – training before we could move forward with productive requirements documentation. From that point on, relationships improved and the project improved. We lost two weeks – actually pushed the project end date out two weeks – but it was worth it. It all ended happy and successfully.


Communication is becoming an issue.

For me as project leader, communication – excellent, efficient and productive (accurate, understandable and everything else thrown in) communication - is Job One. I feel that 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. On a personal note, my 10 yr old son was diagnosed with cancer – Leukemia to be exact – in March of this year. We are learning all types of things like good and bad hemoglobin and platelet count levels, what IGG means, what's a good ANC level and why and lots of new names for medications. Every day, every week is a new challenge, but communication is critical and understanding and the asking of questions is important because doctors know so much and don't want to assume we are all ignorant, even if you are uncertain and it's the 3rd time he's explained something to you. So you ask questions because being on the same page is very important – so when you have to make the midnight call to him because you're son's nose is spontaneously bleeding you know that is one of the things on the list to call about – and by the way it results in an immediate trip to the emergency room in case you're wondering. 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 we need to know when we 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.