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

Revealed: The golden rules of managing software projects

Buff up your halos

By Jon Collins

Posted in Workshop, 15th October 2008 12:44 GMT

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.

We'd love to hear your views in our short poll on the next page.

Reader poll

Q1. What is the main kind of project you are working on now?

a. New application developments
b. Significant updates to existing applications
c. Maintenance and minor updates to existing applications
d. Integration across multiple applications
e. Development of Web front-ends onto new or existing software

Q2. What is your role on the project?

a. Project or programme manager
b. Enterprise or technical architect/designer
c. Tester or integration role
d. Quality or configuration management
e. Other project role (please state)

Q3. What kind of development structure are you working within?

a. Formalised, using structured methodologies
b. Formalised, working with Agile methodologies
c. A combination of the above
d. No particularly formalised structure
e. Other (please state)

Q4. What kind of management approach/relationship is prevalent?

a. There is an excellent collaboration between managers and developers, on a peer to peer basis
b. Management is centralised but there is a good relationship between managers and developers
c. Management is very much command and control, developers are told what to do
d. Developers tend to manage their own activities with management playing an overseeing role
e. There is very little management visibility, developers are responsible for planning and delivery
f. Other (please state)

Q5. Which of the following measures do you use as your primary development metrics?

a. Lines of code produced
b. Effort necessary/used (person days)
c. Tests completed
d. Quantity of code tested (code coverage)
e. Requirements implemented
f. Bugs to be dealt with/fixed
g. Functional units delivered
h. Other (please state)

Q6. How much would you agree with the following statements?

5
Agree Strongly
4
3
2
1
Disagree Strongly
We deliver software on time and to budget
All software is at a high level of quality prior to delivery
There is a high level of communication within the project team
All developers and staff are fully aware of project timescales
There is a great level of motivation within the team
The metrics and measures we use are appropriate and useful

Q7. Do you have any comments or anecdotes you'd like to share?