Project Management: Best Practices for IT Professions

by Richard Murch (ISBN: 978-0130219145 )

Although I have actively, and sometimes passionately, resisted the move into any sort of management beyond team / technical leading for many years, I'm finding recently that I'm becoming more interested in project management. It's a sobering fact that where I am now I have a team and I need to manage them better.

Project Management by Richard Murch was (how shall I put it?) strongly recommended and presented to me by my current boss. It's a reasonably sized hardback book at 220 pages, plus appendices. The information on each page is, in most cases, both verbose and spread out, so it could have been a much smaller book. I would have scrubbed the final chapter on the internet altogether until I noticed the publication date of October 2000. It's a book of its time and therefore describes the more traditional project management techniques based around quite lot of documentation and rigid process. As such there is no mention of XP or Agile, neither of which could be ignored in a modern text. I read it cover to appendices in a little over a week and I learnt a lot.

There were a few things that irritated me about the book. Murch states very early on that all projects must cater for change. I couldn't agree with him more, but in several other places in the book he talks about eliminating scope creep. I may be being a little harsh as most of the scope creep Murch refers to is the “wouldn't it be nice if” type. What he seems to have missed is that all scopes in software development creep. The reason they creep is that software engineers strive to give users what they asked for and, invariably, users ask for what they think they want, not what they actually need. Any well managed project will have the users involved from beginning to end (a point Murch does make) and as the users see what they're getting they're able to help direct the engineers to what they actually need and scope creeps. Scope creep could of course be eliminated by gathering requirements and then isolating the users until the project is complete, but then the users wont have what they need.

The book also shows its age when describing testing. Unit Testing no longer refers to testing a unit of work. It is an automated test testing a single unit such as a class. These test should be written by the software engineer and not left to another party following development.

I haven't encountered Rapid Application Development (RAD) in the project management sense before. From Murch's description it sounds like the only teams it would suit are those that are simply stringing together existing components, where there is no learning to be done and very little to zero chance of scope creep. This seams totally unrealistic to me. Software engineers innovate and to innovate they have to learn. When people are learning they make mistakes and RAD doesn't allow for mistakes.

That said, let me reiterate that I learnt a lot and there is plenty of good advice in this book. As I read it I made a list of the things to remember and to try and make use of. I ended up with 19 points and page numbers. To my surprise a lot of these did revolve around documentation, but I still feel it should be minimal and I'm still undecided about how much should be hard-copy and how much electronic.

Murch states that project managers should stay positive (P.15) about all aspects of the project while, at the same time, be able to handle often relentless stress (P.18). This is a very accurate observation that all project managers should bear in mind.

A lot, but not all, software engineers and managers are aware of the risks that might effect their projects. Murch talks about risk management objectives (P.163) and documenting and constantly reviewing risks that effect the project. The scoring system and examples presented are sensible and I can see them being useful. Once identified, all risks should have a risk management plan (P.166). This all makes perfect sense, especially when you consider “the first step in avoiding a trap is knowing of its existence”. This way there are less surprises for all concerned.

Software engineers are often left to battle on with a problem on their own, be it pride or the illusion that someone else's time is better spent on a separate problem or on development. Murch points out that problems are solved quicker and more easily when more than one person investigates the problem (divide and conquer P.176). He also describes a repeatable problem solving methodology (P.177) that helps the team to understand and document the problem for future reference, plan and implement a solution.

Problems do occur in projects. In most cases these problems are fixed and the team assigns them to history and moves on. This kills the learning process as soon as the problem is fixed, which leaves it liable for repetition in the future. Murch describes Lessons Learned reviews (P.28) which are a type of post mortem designed to help the team learn from problems and mistakes to help avoid them in the future.

All projects, even Agile and XP projects need a project plan (P.41) and no project should be started without one. Projects should be divided up into phases and/or milestones with a phase check list (P.64) so that it is clear to the team and to project and senior management if a phase has been completed successfully. Regular project review reports (P.32) enable the team, the project manager and senior managers to monitor and understand the progress of the project. Projects also need a set of standards (P.29) that are reviewed regularly to make sure that everyone is producing the right level of quality.

Murch explains, as we all know, that people are the most important part of any project. It is important to retain staff and make them feel secure. Murch suggests that the best way of doing this is with incentive packages, usually consisting of a high salary, options, dental plans etc. Although I agree (what software engineer wouldn't) the people you work with are often the biggest factor. Therefore, when expanding the team, it is vitally important to find people who will fit into the team, not just those that are the right price or have the right level of technical skill. Evaluating the skills within the team over time (P.24) is important. It helps make sure that team members learn and maintain the skills that are going to be of most use to the team currently and in the future.

Murch describes two roles that would be useful in any team: A scribe (P.157) who is responsible for recording and collating discussion in any team meeting (formal or otherwise) and a release manager (P.193) who is responsible for overseeing releases, release planning and managing any problems that arise.

I wouldn't recommend this book as an absolute or only guide to project management, especially as it is so out of date, but it is a good place to start if you are going on to read other things. As for me, I have Agile Project Management: Creating Innovative Products (ISBN: 978-0321219770) lined up next.