I actually enjoy putting timescales together for a project. It’s the first time you put your head down and shape nebulous requirements into some tangible product. It’s when you pull a project from the ether into reality?at least on paper. It’s the first time you start thinking about how an application will work, what the user experience will be like, and how the infrastructure help or hinder you.
You sit down and put together some reasonable timescales for how long the work will take you. Someone new to the industry (or a veteran slow-learner) will give incredibly ambitious timescales and allow for no contingency (hint: nothing ever gets done in 20 minutes). Experienced developers allow for a reasonable amount of ‘shit happens’.
- 3 Days to design workflows.
- 2 Days to design the database.
- 4 days on middle tier.
- 4 days on client.
- 5 days testing
- 2 days deployment
Drafting timescales is a lot of fun. Handing them over to a project manager sucks.
A project manager sees these timescales as the ‘sticker price’ of the project. No one actually pays the sticker price. Regardless of how ambitious your timescales are, a project manager sees this as his opportunity to use some ‘negotiating skills’ and haggle. They try to turn us into construction workers or car salesmen. They love this. Project managers get together and boast about how they talked down developers?”He was asking for 20 days, but I talked him down to 15 and he threw in a free air freshener.”
I’ve never had a project manager say “Looks good. Get started.” I’ve also never heard “Do you need anything from me?”
Just to add a caveat, I’m not talking about project managers who can code (or build, or whatever other industry you might be in). I’m referring to the fresh out of Prince2 course, a-project-is-a-project , I-manage-resources, project manager. I’ve worked for project managers who could code and find them to be very reasonable. They lend experience where needed. If anything, they’ll ask if you gave enough consideration to problems that might arise. I have no problem with them. Although I have worked with ex-developers who’ve been out of the game for more than a decade and they’re just as bad as having never developed?”I used to develop in VB2, so I understand the kind of problems you might have.” I’m referring to the ordained project managers who pop by your desk every five minutes to ask “How are things going?” and then glaze over as you tell them about the issues your having.
With these project managers, I cease to be a person with an opinion and become a ‘resource’. They even refer to me as a resource to my face. I actually had a manager say, “You can’t help him, you’re my resource!” I don’t think it even crossed his mind that I may have been offended by it. I’m sure he used the term affectionately.
I believe project managers suffer from relevance deficiency needs. They live in constant fear that someone will pull back the curtain and say, “Hey. Hang on a second . . . I drew up the plans. I understand the technology. The users call me when they have any questions. What do you actually do here? Are you relevant? ”
It can happen any day at any time and it scares the hell out of them. They try to keep us from approaching the relevancy topic by producing large amounts of documentation that no one will ever read and calling a couple of meetings a day. “Let’s have a daily catch-up at 4 o’clock. I’ll bring copies of the project plan. I sent you the minutes from the last meeting. Have you had a chance to look over them?” By asking this, we go into some latent grade school guilt about homework we had to do but didn’t, “I’ve, um, been very busy this morning.” “Well, have a look at it before this afternoon’s meeting.” It’s like when a teacher would announce “Pop quiz!” and send us into a panic. Never do we get a chance to bring up their relevance. What we should say is “I’m sorry I didn’t read the forty-page document, I was busy BUILDING THE APPLICATION!”
But this insecurity is gone when we send them a spreadsheet full of timescales. Without any technical competency (glancing at a ‘For Dummies’ book is beneath them), they can look over a plan and, clutching their heart as if going into a stroke, say “20 days? Surely you can do it in 15!”
Imagine if your doctor (aka, the guys with the medical skills) had to produce a project plan for a project manager. “You say the surgery will take four hours? Surely a procedure like this should only take two.”
The one item on the timescales that ruffles feathers more than any other is . . . take a look at the list above and see if you can guess. That’s right?testing. If there is a bit of fat in these timescales, surely it’s in the testing. Testing is always the first to go. If anything goes wrong after deployment, it’s cheaper to just look at you with pursed lips and say “Really. I would have expected a higher standard of software from you.”
I once produced timescales for a manager (the ceo of a small company, actually, but he saw himself as a pm too) and had him say, “Let’s get rid of the testing and security and then we should be able to do it.” I looked at him stunned. He was apparently under the impression that I had handed him a menu. I should bow and say, “Excellent choice, sir. Our middle-tiers are excellent this season.”
In the offshoring world (yes, it always comes back to that!), I hope that we start seeing the end of skill-less project managers. In an ideal society, the veteran developers will lead the offshore developers. When a client asks about a feature to their application, they will be asking a developer who knows what technology can accomplish and roughly how long it will take to do. Ideally, local coders will continue to code and spend more and more time reviewing code. However, the cynic in me sees this as not being the case. When developers are looked on, and referred to, as ‘resources’, they become easily replaceable. “Hey! I just got an idea. You know those resources on the second floor? They got resources in India and China too.” It’s a wonder so many offshoring projects fail.