The golden rules of managing software projects

Reader Poll We asked what looks to have been a pretty contentious question – what’s the role of managers in software development? - and we got some pretty contentious answers, which are well worth a look in their entirety. The conclusion: a lot of managers are crap. But – and it’s a big but – they don’t have to be, if they get certain basics in place.
Here are your very own top five golden rules, compiled from your comments, which managers can employ to build trust and get the best out of developers. These rules may seem like common sense, but we know from the feedback that they are as frequent as a night bus. “Most can't [manage] and if you find one that can, you are blessed,” said one of our respondents. “If you find one, pay him or her whatever it takes, because they are rare creatures,” said another.

We’ve used the comments directly as they speak for themselves. If you want to help us bottom out how management can make a real difference to software projects, click here to answer a few very simple questions in our minipoll.

1. Protect the team from unnecessary distractions

A manager's job is to help the developers to work as productively as possible towards logical and achievable project goals by protecting the team. He must also earn the team's respect by fighting heroically for them against the boneheaded stupidity to be found in swampy stagnant meeting rooms across Britain.
The only 'big' company I've ever worked for that managed developers well was managed by an ex-coder with a 'personality' who could fight his own corner in the boardroom and kept the sales/marketing types well away from the developers, apart from the monthly 'meet the developers down the pub' meeting. That's programmers’ nirvana!
A good manager keeps the devs shielded from crazy nonsensical requests and other managers that don't understand the importance and priority of the items being made.

2. Provide structure where necessary

Some people/teams are able to produce the goods without management - others require various levels of management to keep them on track. A good manager will already understand this and treat people accordingly.
"Structured" is the key word. Go read "Dreaming in Code" - the more "awesome" the developers, and the more free rein you give them, the more out of control they'll be.

3. Plan proactively and collaboratively

Finally to all those - too few - managers who do a good job, keep at it, Carpe diem, or even better Carpe cerevisi!
The problem is not with managers per se but with managers who use schedules to beat up developers. Management is fairly straightforward if you are a manager and not a dictator. Real managers know that trust from your staff is earned, not given.

4. Know how to manage

Logistics, politics, budgets, etc are necessary but boring - so, let's leave that to managers as long as they get us what we need and stay out of the ‘how’.
In established professions like engineering and accounting, to manage the project you have to be a member of the profession. One of the problems facing IT is that our projects are run by professional salespeople, professional lawyers, and professional accountants. These people know a piece of the puzzle, but they should be resources that an IT professional manager consults, not quarterbacking projects.

5. Balance requirements with reality

A manager’s job is to balance between what is best for the company, for the devs and for the users. You can't just pick one. All that will do is run the company into the ground in time.
If the QA is getting buggy software then the manager should be able to see this. When there is a problem with something that they are managing, they first they must do is look at themselves.
The best developers always have a very clear understanding of where the money for their salaries comes from (customers), and the best managers should be helping the developers to produce the goods that those customers want.

http://www.theregister.co.uk/2008/10/15/project_management_rules/