Handling the impossible project

By Digbyswift at June 24, 2010 05:56

I’m currently finishing the first phase of a project that has caused a few sleepless nights. The causes I can comfortably lay at the door of my boss:

  • He agreed a fixed fee up front with the client without any analysis of requirements;
  • He agreed a go-live date up front, again without analysis of requirements.

You might say that this is actually not an issue. This happens all the time, right? How many projects have you worked on when you’ve actually known the budget? Or when the specification for the project has been written after the horse has bolted?

Sure, this probably isn’t an issue if the project is relatively small and one that you can boilerplate from another project. However, in this case, the client wanted us to build an e-commerce/auction application, that once spec’d out required approximately 1050 man hours – that’s around 30 weeks, one developer working flat-out. This also making the assumption that I had captured all the tasks – which inevitably I hadn’t.

My boss promised up front that the client could have it in 12 weeks.

Every developer knows that given any week of development, he will not get 100% development time one one project. Maybe, 75-80%? The rest will be meetings, helping colleagues etc. So, to me, the task was ludicrous. Even with two developers working flat out, the timings still did not add up.

I’ve done my math and the fixed fee agreed with the client, before any specification was written, requirements analysed etc. was a hefty 5-figure value short of just the development cost. Add to this the cost of design, planning, project management costs and then contingency, and you can see that this is simply ludicrous.

This is what we did

So in a nutshell, this is what we did:

  • Myself and another developer worked flat out for the 12 weeks;
  • We hired a contractor to do a independent chunk of the project;
  • We drafted in a third colleague at times to pick up certain tasks;

The 4 weeks testing originally scoped, became 1 week and then the site went live.

The result

It was not my intention to go live after such a short testing period. In fact, no internal was done at all and barely one week of client testing. But the client wanted it live and we weren’t in a place to argue. The result was that a sub-standard site was released to the public:

  • There was missing functionality;
  • There was buggy functionality;
  • There was functionality that just didn’t work;
  • The work the contractor had done was untested and error strewn;
  • The client required changes that were difficult to incorporate due to the buggy nature of the site;
  • The client required changes that they hadn’t realised they wanted till they saw a complete, functioning version of the site.

In addition to this, because the testing phase was cut short and, as it turns out, the client didn’t sign off the specification, the issue-fixing stage will be ongoing for quite some time.

Lessons learnt?

Its easy to say, but don’t let your boss promise anything to the client until a project brief has passed your or the lead developer’s eyes.

How can a project be costed if there is no analysis of what the project will actually entail?

You may upset your boss by insisting on being involved as it will be seen that you are overcomplicating a process that he/she needs control over. But the benefits out-weigh the additional time spent, even if this is 30 minutes doing a high-level analysis of your bosses interpretation vs. the clients brief.

I’m actually very happy how the project has turned out. I’m less happy about the stress that it has caused. But it has up-skilled members of the team, given colleagues the encouragement that larger projects, when handled in a certain way needn’t be difficult and shown core weaknesses in the company’s project delivery process that we can improve upon for next time.

Comments are closed