Sunday, 15 May 2016

A Doomed Project

I had been working as a senior consultant at my then employers for around eighteen months when Ronald (all names have been changed), my boss, called me in to his office.
“You know Paul has resigned.”
“Yes, I did know that.”
“I’d like you to take over Project X, Rick and Jason will stay on it but I need you to manage it.”
“OK, what sort of state is it in?”
“Well, the customer isn’t very happy at the moment, they don’t think that they have had the results that then need. We are ten months in and the project is due in another two”
“Hmm…, OK, I’ll talk to the guys and find out what’s going on.”
Well, that’s a bit worrying, seemed like I had been handed a poisoned chalice. Still, better get some facts before I jump to conclusions.
Rick and Jason were in the shared office, so it didn’t take long to find out the state of the project. It was a mess.
A bit of background. The project was for a government defence agency and involved prototyping user interfaces for weapons targeting on a land vehicle (tank, in everyday terms). In order to do this, it had to display a viewport containing landscape features with targets and other objects overlaid. This was some time ago, so the whole thing was running on a Symbolics Lisp workstation (if anybody remembers those) as PCs were nowhere near capable of handling the demands. It was also written in an artificial intelligence environment. So, nothing ordinary about it.
Paul was a bit of a prima donna, very bright and interesting to talk to, but with very little regard for other people’s abilities, which he took delight in belittling. In line with this personality trait, he had kept all the work he deemed interesting to himself, and had not documented any of it.
So, what did we have? Jason had created a database of targets and other objects with symbols that could be placed on the landscape, so that was good. Rick had made a pretty good start at landscape painting (mind you, this was black line drawing), including obscuring objects that would be hidden, so that was also good.
Paul had kept for himself the user interface prototyping, and, from what I could tell, none of that worked or was even written in a way that any of the rest of us could understand. This was, of course, the part that the customer really wanted, the database and drawing were almost eye candy so far as they were concerned.
It was pretty clear that there was no way we could deliver what the customer wanted within two months. Given that all three of us were able to concentrate on replacing Paul’s work, we reckoned we could deliver something useful in three.
I went back to Ronald.
“We’re going to need more time, if we try to do this in two months we run the risk of the customer refusing to pay.”
“How long?”
“We think a one month extension will do it, but I have an idea of how we can make that more acceptable.”
“Go on.”
I had read Tom Gilb’s Principles of Software Engineering Management and its description of evolutionary development, which was revolutionary and predated agile by around two decades.
“Well, you know Paul had been meeting with the customer once a month and telling them whatever nonsense it was?”
“That’s about the size of it.”
“Well, I want to be upfront about the issues, and propose weekly meetings. At each meeting, we will decide what is the most important thing we could be working on and for which we could show them results at the next weekly meeting. I think they will go for the weekly meetings because they really need to see progress, and they will like the engagement we bring by laying out what we could do and asking for their input.”
“But it will seem like we are abdicating responsibility.”
“Not if we explain that the whole goal is to get to something useful to them as quickly as possible.”
“OK, I’ll talk to them about extending the delivery date.”
“Great, but please make it clear that they will get something delivered each week that they can review and provide feedback on. They won’t have to wait until the end of the project before they get something.”
So that’s what we did. The first meeting with the customer was a bit touch and go, but we were able to show them some of the work Rick and Jason had done (Paul had kept it from them, probably to claim it all as his own), and agreed on something we would deliver for the next meeting. And so it went on.
Did they get everything they originally wanted? Pretty much. Were they happy with the result? Yes. Did we get paid? Yes. Did we work with them on other projects? Yes.
Is there a moral to this story? Well a few, I guess:
  • Don’t give the project management job to an overbearing egotist who tries to take all credit and deflect all blame
  • Work with the customer closely
  • Deliver something of value as soon as possible
  • Deliver something of value at every meeting.
  • Review everyone’s work and ensure it has enough documentation that someone else can take it over.

Sounds pretty much like agile development, even though, as I said, the term hadn’t even been invented at the time. Nothing new under the sun.
Post a Comment