Software Project Management

[This was written in April... and I was cleaning house on my computer, so...]

Over the years I've put together some rough guidelines on software projects and how to manage them. (I've managed two teams so far). This evolving list is something that I've come up with. It repeats what you'll read in most good management process books. But if you've not read them before, you might see something new.

Rule 1: Motivate Your Team

Make sure members of your team are motivated correctly. Each person's motivation is different - and may not coincide with yours at all.

Rule 2: Plan Your Project

Plan your project out accordingly. Use timelines and estimates. Use tools to produce planning documents (such as Project). If you don't have it written down, you're wandering around in the dark with a blindfold on.

Rule 3: Project Planning Isn't Finished Until You Ship

Repeat rules 1 and 2 until done. Timelines are never complete; they change as you go on. Teams never stop needing motivation - different people need different things. Both of these processes are iterative.

Rule 4: Let People Work When They're Most Effective

(a corrolary of rule 1)

It doesn't matter when your team do their work as long as they make it to meetings. You're paying people to work. If they are achieving their goals, they're doing the right thing. Insisting on people turning up at 9am every day and leaving at 5pm is a poor subsitute for actual performance reviews, understanding the work being done, and proper project maangement. For a start, you still have no idea what they're doing if they arrive at 9am. They could be sitting on their asses all day and twiddling their thumbs, perhaps watching the latest plays on ESPN or reading The Economist and The Beano. Maybe they track their stock portfolio all day long, or buy and sell things on Ebay. Maybe they don't.

A properly motivated employee, however, might show up at 11pm and leave at 7pm... and then work on the problem at home. They will work weekends, work evenings, and will pull your ass out of the fire again and again because they enjoy the challenge. Writing software - for really good software engineers - is a creative process. It's like writing music, or crafting a novel, or painting a picture. When the inspiration hits, a really good software engineer will be twenty - or many more - times more productive than a competent one. The rest of the time they're the same as a competent engineer.

If a software engineer feels that they're getting nothing done - and are highly unlikely to get anything worthwhile done - let them go home. Get them out of the office. Don't make them feel guilty about it - just get them out of there. If they're a professional, they will take the time, get their mojo back up, and then spend their official "free" time working on the problem. Making someone sit in a chair for hours at a time just because those are your working hours is useless and pointless. You're wasting their time, your time, and just causing resentment. Brains do not function at full pelt 24/7, and software engineering is very demanding on brain power.

Show me one physicist who works 8 hours a day on writing equations and papers using nothing more than the sweat and blood coming out of his pores as he thinks onto the page. They don't - they spend their time tinkering in a lab, playing around with physical bits and pieces, and otherwise toying with what they're doing. This is worlds different than what a software engineer does, which could most easily be described as doing a really difficult crossword or rubik's cube for 8 hours a day, nonstop. (Or longer, if you consider that most software guys just can't turn their brains off - they think about their programming problems nearly constantly).

Rule 5: List your tasks in priority order

Task lists and prioritization are good for your project, and good for the individual team members. If you don't have them, not only can you not track how and where you're going, but you're doomed to failure every single time. At the very least, you'll burn out your employees very quickly - because every time you throw them through a mad random crunch, you make them so much more weary.

Rule 6: Reward Crunches with Time Out

No matter whether your project is having random, planned, or unexpected crunches, or even if the workload is just too high, make sure that you give your employees some downtime at the end of the milestone. If you don't, you risk burn-out. If you burn-out your employees, you may need to get more employees - because they will walk out on you. This is costly - it costs you time, money and team morale. Especially if one employee leaving triggers an avalanche because the project is mismanaged and is being run close to burn out.

Rule 7: Never schedule more than 4 hours of real work per day

People have meetings, lunches, and life. And frankly, you're lucky if you get 1 hour a day of real work out of anyone at less than executive level - there's just not enough reason for those people to put any more effort into it than that, after all, executives own considerable chunks of the company - regular employees tend to not own squat. But if you schedule for 4 hours of work a day, it all smooths out nicely, everything happens on time, and you maintain a nice high energy atmosphere where things get done right.

Rule 8: Don't Randomly Screw With the Schedule

If you interrupt your engineers, it can take as much (if not longer) as half an hour to get back into the zone needed to thread back together the spatial relationships between everything they're working on into one piece. Every interruption - every other random task - has a similar effect. (This is why Microsoft gives software engineers offices).

Similarly with the schedule - if you throw random tasks, software is VERY difficult to steer. It takes time - sometimes weeks - to adjust to the random changes. In some cases, you have to throw out whole swathes of code just to compensate for the fact that priorities have changed and everything needs to be done yesterday.

If you must make changes, get buyin from people, and at the very least find out what the risks are with the changes you're planning. Better informed = better decisions.

Rule 9: Be Observant

Not all employees toot their own horns. The loudest employees might not be the ones doing all the real work. The quieter ones might be doing several things - it's only when you talk to them or watch them in action that you actually see everything they're doing.

(Corollary: watch out for other employees who try to steal credit from these people).

That's all for now. More later if I remember more to put up :)

About the author

Simon Cooke is an occasional video game developer, ex-freelance journalist, screenwriter, film-maker, musician, and software engineer in Seattle, WA.

The views posted on this blog are his and his alone, and have no relation to anything he's working on, his employer, or anything else and are not an official statement of any kind by them (and barely even one by him most of the time).

facebook comments