Monday, April 7, 2008

Traditional Project Roles

I have often thought that there is a glut of staff crowding a project. This idea was recently brought to the forefront of my mind when I looked at the costs associated with a project. Now I had worked on this project at its inception, and with one other developer, the two of us had written all the requirements, produced a software architecture document, written tests and developed much of the software.

The project was dogged with issues, I moved into a different role on another project, the other developer moved on to a new company and other developers came and went, all over the period of about a year. Additionally, we were dependent on a number of third party vendors, all of which had legal agreements and other time consuming hurdles which had to be overcome before we could proceed - the project largely dealt with the integration of external systems. Together with a couple of QA staff, the project proceeded at a slow, steady pace until it finally went into production a few months ago.

It was around this time that I happened to stumble on the financial figures for the project, which I don't normally bore myself with, but someone had been talking costs on this and I couldn't figure why it would ever be an issue. Turned out that around 30 people had booked a considerable amount of time to the project, thus causing a high and somewhat disturbing bottom line report.

Even with full possession of the facts, I could not avoid jumping to the conclusion that is was a costly project, providing poor value for money to the client. But it did not seem like it at the time. I looked more closely at the staff on the report.

There were a number of BA staff, QA, PM's, process analysts, numerous managers from different departments, and a host of other people, some of which I had never heard of. With the sole exception of several QA staff, I couldn't remember one of these people actually having made a contribution to the project. Granted, the Project Manager had a 30 minute 'is it done yet?' meeting once a week.

What would have been the outcome of the project if just the two developers and one or two QA staff had been the only ones working it? I suspect exactly the same, only the company would have save itself hundreds of thousands - another small project.

Why is it that we are convinced that we need people with these different titles on a project? Perhaps it makes organizations feel comfortable that we follow some age old process ideas that dictate we must get smart people who can tell the working class 'coder' what to do - because everyone knows they can't do it on their own. I think this is related to same disease we have built in to our social fabric in the western world - command and control, tell the 'workers' what to do. This attitude seems to still be prevalent 100 years after Frederick Taylor's scientific management was first put together. The sad irony here is that most good developers I know, could actually do a better job of each of the other roles than those whose role was actually their full time job. Developers have to step up to the mark however and play the various roles - oftentimes, I see developers who don't want to get engaged with the client and understand that we are actually 'building a cathedral' and not 'cutting stone'.

Why is it that being a developer on a project always seems to take second place to all other roles? What is the most important thing a project produces
a) Documents
b) Diagrams
c) Timescales
d) Cost projections
e) Working software

For those who need it spelt out, working software is the ONLY thing that matters. Now I am not advocating that we do none of the other things, merely that given limited resources available to us, we choose our priorities carefully.

1 comment:

Paul said...

Hi Andrew,

It is sad that in 2008 that this point still needs to be made. But as you can see from my current discussion on my blog it still does.

I like the succinct way you put it. Even so I fear that the message is still unlikely to get though. Why? Well there are too many vested interest that like things the way they are.

Like I say, it is a war. Many have given up on the fight from within traditional organisations and have decided to go it themselves and startup new organisations.

Paul Graham as a number of interesting essays where he advocates just this. The freedom to do the right thing! For me this is the next step.