Revealed: The golden rules of managing software projects

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 …

[Reg Varney]

If only everyone was such a paragon...

re: "The best developers always have a very clear understanding of where the money for their salaries comes from (customers), "

That's great - if you have the best developers. And I'm sure everyone who posted on the original thread about this was a paragon of virtue and a supreme master of their trade. But in the real world, where a lot of developers are just average, or not interested in keeping their skills up to date, or want everything handed to them on a plate without them having to think - maybe not so clear cut.

[Anonymous Coward]

Project Management #1

So number one Golden Rule. Get some good developers. As a suggestion a good developer is worth 10 times more to you than a poor one, and 3 times more than an average one.

A poor and average developer will need so much of what they have broken fixed that they generally have a negative impact on your project resourcing anyway.

What ever you choose to do with the sh**e that you have recruited don't be tempted to make them managers to get them out of the way.

[Jodo Kast]

Unfortunately...

bad developers are paid the same as good developers. Which is nothing.

Example: Any other IP development scenario, if you are creating something, you get royalties.

With software development, 9 times out of 10, you get paid hourly.

There is absolutely no incentive to provide anything above 'average' for this type of remuneration.

It's not going to get better until developers are better respected. Comment #1 shows that management probably doesn't understand why the programmer is 'bad'. They have no incentive. They want job security, and if that means buggy, sloppy code, who cares?

The customer is getting what they want. Sure there are bugs here and there, but those can be fixed.

[Aristotles slow and dimwitted horse]

Surely number 1 should be...

Always appoint or recruit a professional and experienced project manager rather than techies that have only just been on Prince 2 foundation courses, so they can tick the boxes in their "career development" plans for their line managers.

In my experience, the range of business, technical and interpersonal skills that a project manager has to juggle day to day in corporates is sometimes lost on a lot of people who seem to think that simply having a practitioner certificate is all it takes. This is a mistake I have seen made time and time again in my 15 years as a freelance PM and whilst I'm happy to try to educate, long may it continue as it will most likely keep me employed successfully for the next 15.

[Anonymous Coward]

@Surely......

In my experience as a developer the number of project managers I have met with any of business, interpersonal, or technical skills is very low. More so if they either have or are claiming Prince Qualifications, this seems to be the equivalent qualification to any of the MS Certified technical qualifications.

If you really want the project to work what you probably need is the classic Alpha team to start a good Project Manager with chairman capabilities, and a good Technical Lead (either of a Monitor evaluator, or innovator). Thinking of the projects that I have worked on these have tended to be successful. I guess dibbing up the required areas of expertise the PM definitely needs the interpersonal skills, the TL technical, and the business expertise would fall between the two potentially.

You probably need to pay both these guys as well. Looking at the other comment on here if you pay peanuts you get monkeys.

[Anonymous Coward]

Rule One is simpler than that: Define The Specification

Unless the spec (for each version) is properly nailed down, no matter who you've got in any role the project will be a fiasco.

When the goalposts for each version move around, it'll either be late, broken or both.

Rule Two is "Stop the salesmen selling more than the specification"

If they do, then either the spec will change, or the customers will be disappointed.

Or more likely, both.

Unfortunately while the former is nominally under the PM's control, the salesmen usually aren't.

[Tom Thomson]

Re Project Management #1

The AC who wrote "As a suggestion a good developer is worth 10 times more to you than a poor one, and 3 times more than an average one" is on roughly the right track but his numbers are wrong. A good developer is around 50 times as productive as an average one (he does in a week what the average guy takes a year on) and maybe -20 (the minus sign is NOT an error) times as good as a poor developer (he takes only a day to undo the damage done by the poor developer in a month - provided it's caught before it gets released, which unfortunately doesn't always happen).

There are surprisingly many good developers, but because most managers think (incorrectly, if they are in a sensible company - but in a sensible company they wouldn't be managers, would they) that their status is measured by the size of their team they recruit too many people and end up with more poor developers than good ones and far too many average developers, then encourage complexity and feature creep to justify the number of people - this results in unreliable and user-unfriendly software delivered late or not at all.

[Peter Simpson]

Read Brooks' _The Mythical Man Month_...

...if only for the quaint terminology: "secretary", "card punch", "typewriter", etc.

Seriously, though, it's an excellent book, and contains some timeless advice for managing large software projects (and software developers)

// mine's the one with the chads in the pocket

[Tom Thomson]

Re Surely number 1 should be...

If everyone follows that advice ("Always appoint or recruit a professional and experienced project manager") how does anyone ever become a professional and experienced project manager? We would run out of managers after a few decades of everyone doing that.

Sometimes it is right to go for someone inexperienced and have them learn on the job from an experienced colleague. A large proportion (actually 100%) of managers have no management experience of management before their first management job.

If you are looking at for someone with project management training, don't go for a Prince 2 expert unless he admits to hating Prince 2 and regarding it as dangerous nonsense. ITIL qualifications are actually useful, Prince qualifications are not (unless you are dealing with a customer who insists on Prince - that's where the man who is expert on it and understands what is wrong with it is really useful). And don't go for anyone who believes in any non-incremental development technique. And don't go for anyone who doesn't think that quality is a major concern right through from understanding and expressing requirements architecture to delivery, or claims that you can be certain of quality even if you do only minimal functional testing. And don't whatever you do go for someone who doesn't understand the importance of communication!

[Tom Thomson]

What number 1 really should be

I'm surprised that this didn't come up on the list of requirements for good management: - and appalled.

The number 1 requirement for a software development manager is that he must be willing to keep it simple and ensure that the team does not bite off more than it can chew. That means having the will power to reject requirements that will result in bad quality or non-delivery. It also means that the manager must understand what the developers are doing and how they propose to fulfill the requirements - how else will (s)he know which requirements can not be met?

Maybe everyone who commented on the original article (and was quoted in this article) should read Tony Hoare's "The Emperor's Old Clothes" paper, as this fundamental concern of every good manager, which is not even mentioned in this register article, is very clearly explained there. It was his 1980 ACM Turing Award lecture.

Find it at http://www.cs.ucsb.edu/~ravenben/papers/coreos/Hoa81.pdf

[Anonymous Coward]

@Tom Thomson: always appoint a pro

>> If everyone follows that advice ("Always appoint or recruit a professional and experienced project manager") how does anyone ever become a professional and experienced project manager?

Apprenticeship/mentoring. Also starting on small projects and growing.

My experience of managing a small project - myself plus between 1 and 3 others over about 18 months - was a shock. I didn't appreciate how much attention to detail, paperwork, negotiation, uncrossing wires, anticipating ambiguity and scope creep, putting up with client mind-changing, chasing up loose ends etc. etc. et bloody cetera. that was necessary to do it right. Without my own, more experienced, manager behind me it would have been worse. But it was valuable!

The most fundamental lesson *I* learnt was: always, always, *always* keep your cool. For others it may be different.

May I ask what you dislike about prince2? Never used it, only heard of it recently.

[Fozzy]

No, No, No, No,

The first rule of project management is never ever take a project on that has already been started It will be running behind schedule and over budget and don't even dare review the requirements, that is if anyone can actually point you to the current version of them (if they even exist that is)

The one business analyst that was any good and knew enough about the project told the previous P.M to jam the contract up his arse, realising weeks before the rest of the company that the previous P.M couldn't manage a root in a brothel with a fist full of $50

The development team will be furiously working away though, attempting to implement requirement #34. A requirement which added little value to the overall functionality and only impacted some sad individual in finance, which when scoped was found to add an extra $300K and 6 months to the project

Speaking of finance, finance being least impacted by this project will be screaming the loudest. Apparently their spreadsheets don't add up anymore and fuck knows what that has do to with this project.

The weekly senior management meetings held on Fridays’ are driving you up the wall. The financial controller who apparently overindulged in his liquid lunch is swaying in his seat like a punching clown, After listening to him still prattling on about spreadsheets that’s exactly what I want to use him for.

I could keep on going but you get the picture and I've digressed far enough. Just say no and run really fast…..

[James Anderson]

Rule 1 is wrong!!!!

"Protect the team from unnecessary distractions" -- is fine if that means keeping the d*ckhead who looks after the timesheets from bugging them, or, fending of the pillock from HR who wants to discuss "personal goals" and "acheivments".

But those "Sales and Marketing" droids are your clients. They know what they want! They may not be able to expalin it in a UML diagram but you really need to communicate with your customers/users/victims.

One of the most common reasons for failed/substandard projects is that requirements have been fed from the original requester, to a consultant on to a busines analyst, translated into use cases by a technical analyst and implemented by developers who have never spoken to any of the four or five people in the communication chain.

Like any good historian you should rely only on original source -- always try to find the real "requiree"s and check with them what is actually required -- up to 30% of requirements can be dropped as they were inserted by the analysts who werent paying attention and cloning the requirments from a previous project .

[Mark]

Rule 1 is wrong!!!! Is Right

Having played the role of both PM and customer in a few large and small scale development efforts for a large North American exchange, I know that rule one is know the source of the requirements and to consult with them often. Negotiating deliverables and setting expectations is the only way to deliver a product that will make the customer happy. When possible have the developers meet with the source to ask questions and better understand the mission and goal of the project. Let the Operations crew have a peak at what's coming down the pike and get some requirements from them too.

[Tom Thomson]

Project Management and Prince 2

AC asked "May I ask what you dislike about prince2? Never used it, only heard of it recently."

Well, it's top heavy for most projects, it mandates too much paperwork (have a look at the templates at http://www.prince-officialsite.com/nmsruntime/saveasdialog.asp?lID=1284&sID=455) but not most of the paperwork that a proper software development project needs (that is OK if top management realises that it was not intended to tell you what domain-specific documentation you need, but top management types are often too thick to understand that), any project management method that requires 45 little processes grouped into 8 big processes and appears to have no dataflow from any other big process (not even the project startup process) into the planning process is obviously crazy, it tends to encourage senior management to think that they can know what products are required and what it will cost to develop them before any real design work or research has been done, it has "scalability" based on advice as to which bits of it are likely to be useful for your project but the advice is such that it often leads to what's known as PINO (Prince In Name Only) projects, and Prince 2 is the mechanism mandated by our government which has been used to manage every government IT catastrophe since 1996. But the best way to understand it is read the APM websites http://www.prince-officialsite.com/ and http://www.apmgroup.co.uk/PRINCE2/PRINCE2Home.asp and maybe the OMG prince website too, perhaps look at wikipedia first (note that I'm only suggesting that you look at websites written by Prince2 advocates) and then get trained on it - and I believe that after you have done that, if you are any good you will realise that this can't be the right way to manage a software development project.

[John Werner]

Rule # 1 - What About...

"Enable your developers to work in a manner that makes them most productive."

Too many times in my career I have had to deal with managers who believe the only way to get work done is to do it the way they would. I don't just mean using the same methods, but the same work process habits. Some people can sit there for hours and crank out work continuously. Others work in "brilliant flashes followed by long blackouts." (that's a phrase one of my best managers used to use -- I loved working for him.)

A good manager will recognize the difference in how people work and enable them to work that way. If that means getting the employee access to the building from 7am to 9pm every day, so be it. If it means running interference when another employee says "He only put 4 hours of work in today, that's not fair!" so be it. Hours worked != work done.

- John

[Tom Thomson]

@Fozzy

"The first rule of project management is never ever take a project on that has already been started It will be running behind schedule and over budget and don't even dare review the requirements, that is if anyone can actually point you to the current version of them (if they even exist that is)"

There's no problem in taking on such a project provided you are prepared to fight to do the job right. Not a good idea to take on one of those as your first project management job, though (I'm really glad that when I got one of those it wasn't my first big project).

A few decades ago I was offered a project that had already been started (and just about completely screwed up) and had gone through several managers rather quickly with a brief to get it out of its hole. I took it on because the powers that were liked the previous projects I had managed for them and decided they wanted me in that slot enough to make it very much worth my while. It was hard work, and there was a fair bit of conflict with other managers who didn't like me telling them what they couldn't have, and didn't like me telling my developers that if they worked overtime or shifts they would get paid overtime or shifts (and to hell with the budget) - but it got there. So I know that recovering a broken project is not the impossible task you make it out to be.

The thing to avoid at all costs is taking on a project where the requirements are clearly unfeasible and also non-negotiable. No matter how much the MD flatters you, don't let him flatter you into accepting that one - don't fool yourself into believing it's feasible just because the big whte chief thinks it is. Trying to manage one like that is a real nightmare. Tony Hoare's comment that you should not offer to do something unless you understand how it can be done is very very true.