Rescuing a complex project part 1: Baseline

Full disclosure – I am not going to name my client here, or indeed the company that did the original work. This would be unfair of me, I believe that everybody entered into what they tried to do in good faith. I don’t want to be seen to be second guessing who said what when to whom.

A friend of mine contacted me through FaceBook and asked if I knew Ruby on Rails. This was an odd request, but I said I did. I’ve been using Rails since it was practically new and know it very well. It’s where I do my bread and butter work when I’m not working on Lean Teams.

I contacted the client and discovered that they were very unhappy with their current provider and wanted me to do a review. Several things, e.g. making the site multi lingual, had been promised. It now seemed that despite the contractual obligation it wasn’t going to happen.

There was also a clash of cultures. My client had written a contract that was results based, the agency they engaged with had a culture of charging for their time. They kept getting invoices for hours that listed things on the list, but what they wanted wasn’t there. So lots of rework and estimates going wrong.

First I had to baseline what was needed after meeting and establishing a rapport with the client, who were under a lot of pressure to deliver something within a few months and were not getting what they needed quickly enough. It became apparent to me that my observation that every problem is a fundamentally communication problem was correct.

The client had also bought the powerpoint. I’ve seen this a lot. On paper the provider could do the job easily. Every step of a standard due diligence procedure had been followed and it hadn’t worked. The problem is, if you identify problems like this there’s nothing you can do anyway. Fortunately they talked to me early enough to get it resolved.

Baseline questions

  • What are they missing that they need?
  • What do they value that they haven’t got?
  • What is frustrating them about what’s happening now?
  • What are the symptoms of the problem?

After my initial meeting we agreed that I would review the code they had and evaluate it against what they needed. It became apparent that the client had lost all faith in the initial provider’s ability to finish the project.

The problem the client had was the agency were very unresponsive and had started to seriously slip in what they were delivering. Every thing that they thought had been agreed turned into a change request. This was part of the clash of cultures – time versus results. In the end the relationship was unsustainable.

In part 2 I will cover how you rebase what’s possible and narrow down what can be done with the resources available.

Posted in Agile practice, Project rescue, Value