Case Studies | By Brad Egeland | Read time minutes
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).
Summary
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.