Saturday, January 08, 2005

Day estimates and the length of strings...

If one more person comes to me and asks for an estimate on how long it will take to do some work, without being able to tel me anything about the work or allowing me to specify it in any way, then I might just have to kill them.

I wasn't going to post about this, but one of the people involved in this persuaded me that I should and the more I think about this, the more I feel the need to talk about it (or basically to vent).

This has been building for some time, more and more over the last few years I have been asked to provide day estimates for unspecified work. In a lot of cases this is somewhat understandable given the type of work that we do. We are often responding to open tenders for public organisations and therefore they expect a fixed price contract, with that price fixed well before any specification work has begun. But recently several people have started asking me for estimates on work that could be specified, if only the project/client was managed better. These are estimates for clients we have a very good relationship with, people with whom, I am almost certain, we could take the time to explain the benefits of proper specification.

I should give you some examples of just how bad things have gotten. A project I recently worked on was delayed, on the client's request, becauee they were having meetings and agreeing things with their clients and partners. We were working on a time and materials contract, which was still to be signed, therefore I wasn't allowed to do any work. I had placed a period of specification work, into the project plan, that had to happen before any practical development take place. As it was the client who was delaying things people at our end were not that concerned, but I was. We knew that our client had immovable delivery dates with their clients, which meant that in reality the length of the project was being squeezed from the front end.

I finally managed to persuade the project manager that, as we were 99% certain to have to do this work, and by the original deadline, that we should begin the specification work. We ended up with less than half the time for this work, which meant I had to deliver very generic wireframes of the GUI. I explained to the client that this was all I had time to do, yet they still requested that I redo them with some real data in them, which pushed us further back.

The lack of proper specification time has added about 20% to the project, the delivery date for our end of which we have had to put back once already. The client has asked for an extension project, and wanted a day estimate based on a few lines of description. The project manager asked me for this and I spent about half an hour explaining to him why there was no way I could give him anything close to accurate figures, and that if he wanted them then I would have to build in such a margin of error that we probably wouldn't get the work. After all of this, after he agreed to go back to the client and explain the situation he said the following;

Project Manager: "So how long would it take to train people to use this?"

...then you could see the bulb over his head lighting up...

Project Manager: "That's a stupid question isn't it, how long will it take to train people on an application for which we have no specification and not a clue what it will look like. I can't ask that can I?"

Me: "No..."

If you think that's bad...

Oh it gets worse, yesterday was the proverbial straw. One of our analysts came to me for a day estimate, with absolutly no warning, no meetings, no meetings booked, nothing. This is how the conversation went;

Analyst: "How long would it take to translate some data?"

Me: "What data?"

Analyst: "An Excel spreadsheet."

Me: "What kind of spreadsheet? What format? Plain sheets or Workbooks?"

Analyst: "I don't know."

Me: "Well how much data?"

Analyst: "I don't know."

Me: "So what format has this got be be translated into?"

Analyst: "XML."

Me: "What specific format? Standards based or do we need to make up a grammer for it?"

Analyst: "Needs to be compatible with [some CMS thing]."

Me: "What does such a format look like?"

Analyst: "I don't know."

Me: "Can you find out?"

Analyst: "Not in time, I need the estimate now."

Me: "Well I just cannot tell you, there is no way that I can estimate that."

Analyst: "I fully understand..." brief pause "...so 10 days then."

I swear I almost ripped his throat out. This isn't a blind tender we are responding to, this company, while technically a client, is actually a strategic partner who we have been working with on this project for months. How on earth can we be in this situation.

The worst part is that these clients are shooting themselves in the foot, and so are we. The lack of specification raises the risk on projects massively, but this is not something that others recognise. There are a lot of people at work who would never ask this, who do understand the risks, but this small pocket of people that consistently ask for these things are driving me up the wall.

I had to write this, to vent my frustrations, but I am wandering if this is a more common problem in the induistry as a whole. Why is it that people will not listen to us developers, we have been doing this stuff for a long time. There is a lot of collective memory and knowledge about how to run these projects, and yet people still refuse to listen.

Let me know what you think, comments and e-mails always welcome.

2 comments:

Matt Large said...

I completely agree with what a project manager can be, and I've known many of these. In my post I admitted that it was somewhat of a vent, in which case it was bound to be completely bias, but then I am. I am a developer and will always pull in the direction of more specification and project managers should always pull in the other direction, because in many real ways they are the client's representative inside the company.

The reason for my venting is that it is occuring more and more where I am not even given the opportunity to pull in the direction of more specification, or in the worst cases ANY specification. There are many reasons for this, and not all of them should be placed at the feet of project managers, however it is nice if they realise that this is a problem. WHen a project manager listens to me saying that I cannot give an estimate and then procedes to put one down anyway I am bound to get frustrated.

A lot of my frustration is with the clients, and not just because they expect the moon on a stick and in double speed, but the fact that they are hurting their own projects. However I am a mere developer and I don't get to see that much of the other side of the fence, no where near as much as the project managers and therefore I should reserve much of my jusgement and defer to them. Because as much as I rant and rave sometimes I realise that I am lucky to work with some people, especially some of the project managers at my company. I'd have ended up in the loony bin long before now if it weren't for them.

But thanks for the reminder.....I am an idiot.

Anonymous said...

A PM is there to provide leadership and yes part of that is to translate the needs and desires of a client into reality.

Unfortunately while it's OK for wetware be vague and non specific computers are crap at such things... quite simply if a client or PM can't explain to a developer what is wanted then the developer can't explain it to the computer and then the chances are he builds the 'wrong thing'... and if that happens then you get unhappy clients, developers and bosses...

This isn't about wanting the moon on a stick rather it's about communication and being clear about what is wanted. If the client can't explain what is needed because they don't know (in sufficient detail) then it's the PM's job to help the client... help them structure their thoughts, lead them through the process, demonstrate and prototype aspects of the project if need be... don't simply act as a conduit and pass crap through to your developer and expect them to deal with it - that's abdicating your responsibility.