Project Smart ~ Exploring trends and developments in project management today

Calendar icon
Adobe PDF icon

Knowing When to Say 'Enough'

~ By Brad Egeland

Hand pushing an enough button

Ever had one of those situations where you try and try and try and you seem to be making no progress at all…or you actually find yourself going backwards. Believe me, I live in Las Vegas so I know gamblers are in this kind of a rut everyday (thankfully I do not gamble).

The same thing can happen on the projects we manage. I took over a project with a seemingly never-ending string of software bugs. Every time my team fixed one and turned it over to the customer team for testing they would identify two new ones. It was a nightmare of a project. We never reached the point of final customer sign off, falling agonisingly close but not quite getting there. Needless to say it was a PM low point for me…softened only by the fact that it was not my project to begin with. Still, a failure is a failure.

So why am I sharing this? I think revealing those less than proud moments to other PMs is just as helpful as discussing success stories. Project failure is a way of life - most studies show that it happens more than 50% of the time…depending on how you or your customer or your organisation defines failure/success. The key is to learn something from it. What did I learn? Several things.

Discuss the Reality of the Situation With the Customer Earlier Next Time

Being fairly new to the organisation I wasn’t in the mode of making huge decisions on the fly yet…I had only been with the company a couple of months at this point. What I didn’t know at this point was if this was a common struggle or if it was just an issue with this particular implementation (turns out it was a little of both). But the hard reality of the likely end result was becoming painfully obvious to me and I firmly believe that the best move would have been to set aside the blind optimism we were showing and work toward negotiating and end to the process we were going through or worked out a very large discount to turn the less-than-bug-free solution over for the customer rollout on their own.

Discuss the Reality of the Situation With Your Senior Management Earlier Next Time

I actually did this…I wasn’t going to hang out to dry alone on this one and also because I was fairly new to the organisation so I was making fewer 'independent' key decisions at this point. But I should have pressed harder for what we all knew was reality - the project wasn’t going to succeed and we would have saved dignity, money, and probably some respect of the customer if we had gone to them earlier and tried to negotiate some end to the chaos. I could see it but my management refused to see it and in hindsight I wish I had pressed harder.

Avoid Throwing Too Many Bodies at the Problem

I was a very experienced PM at the time, but as I said I was still very new to this particular organisation. The senior management kept giving me more warm technical bodies to throw at the problem…analysing, fixing issues, performing testing, and handing issues over to the customer only to have their team come back with two new ones nearly every time we said we had one resolved. It killed the project budget by adding so many high priced technical resources to the project in a fairly short time frame and there was no way to recover. I remember our delusional PMO director going onsite to try to negotiate a big payment and more funding from the customer, but they sent him on his way fairly quickly and moved on to another vendor to perform the final fixes and deployment. In the end, therefore, we were spending OUR money by continuing, not the customer’s money. Bad move.

Negotiate a Rollout With Bugs

Finally, what we should have done was to negotiate a discount with the customer to have them take the developed solution - where it stood at that moment - and allowed them to implement it on their own however they saw fit. We would have avoided spending the $10s of thousands of dollars more that we ended up spending on it only to have the customer refuse to pay that final bill and fund the project any further (when they sent our PMO director home following his failed negotiation attempt).


What turned out to be a failed implementation that was eventually turned over by the customer to another vendor to finalise and deploy, really couldn’t have gone any other way. The organisation I was working for at the time had a reputation for not having the right technical personnel available to get the tough jobs done every time and it was so painfully obvious on this particular project of mine. We should have pulled the plug earlier, saved the customer some money, saved our organisation a lot of money, and moved on. In the end, the customer likely would have respected the organisation more for it. It’s ok to fail from time to time. We need to be able to weigh the costs and risks of moving ahead with more attempts to 'fix' the situation and just calling it quits and saving some costs and frustrations on both sides.

Comments (1)

Topic: Knowing When to Say 'Enough'
4/5 (2)
Full StarFull StarFull StarEmpty StarEmpty Star
31st October 2014 10:34am
Mahesh (Bangalore) says...
I have been in this situation where the project team was cornered with lack of time since the original estimates provided were much lower than practically possible (maybe the idea was to get the project), but ended with the exact situation mentioned above. Here is how I pulled the project back on track. What I did was:
  1. Identified the poor / unstable parts of the application and made the changes required with careful thought processes.
  2. Did not not moved / or added resources until we got the bug list to zero.
  3. Made the development team demo the proposed changes / fixes to the client to make sure that the impacts were understood before the implementation.
  4. Clearly set the expectation for the client on what is not feasible and won't be available.
  5. Filled the gap between the developers and the client to avoid confusion.
  6. Set a hard rule of "NO ASSUMPTIONS" to have better understanding.
  7. Made the development and testing team attend UAT to know the level of detail the client is expecting in the meeting.
  8. Would only take up the changes / fixes if the logic had been documented and signed by customer.
These are some of the points that I made and followed strictly and achieved a project that was declared almost scrap by the whole organization. BTW this was my first project as PM.

Bottom line was; I kept cool and kept going to achieve this without panicking.

Best Regards,

Add a comment

(never displayed)

Enter the second letter of the word horse.
Notify me of new comments via email.
Remember my form inputs on this computer.

Is Your Project Proposal READY?

Businessman saying: Are you ready in retro style pop art

The mnemonic READY is useful when creating a project proposal. It will help you produce a project proposal that's difficult to ignore.

Taming MS Project

Gantt chart and plan

Microsoft Project can become a huge overhead, even for seasoned project managers. This article contains some tips and tricks that will help you tame the tool.

Helping Project Teams Succeed

Business team brainstorming using coloured labels on a table in an office

Project teams will be successful when the right environmental conditions exist; sadly this is not always the case.

Estimating Project Costs

Money and a calculator

Tips and advice for estimating project costs, including three point estimating and Monte Carlo Simulation in MS Excel.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.

Latest Comments

Allana commented on…
12 Tips for Being a Good Manager
- Tue 5 January 8:30pm

George Bockius commented on…
Better Coaching Using the GROW Model
- Thu 24 December 3:55pm

Al commented on…
Better Coaching Using the GROW Model
- Tue 22 December 10:07pm

Latest tweets

General Project Management • Query on PMP Numericals about 5 days ago

General Project Management • Problems With Project Planning about 5 days ago

General Project Management • IT project management phrases - 10 terms you need to know about 12 days ago