Skip to main content

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.

Comments

  1. Hi Paul
    You know, I have to tell you, I really enjoy this blog and the insight from everyone who participates. I find it to be refreshing and very informative. I wish there were more blogs like it.
    Thanks for sharing
    regards
    digitization services

    ReplyDelete
  2. Thanks! It's also was nice to get feedback, whether good or bad. You might also like Allen Kelly's blog: http://allankelly.blogspot.com.

    It's also rather difficult to work out who you actually are....?

    ReplyDelete

Post a Comment

Popular posts from this blog

Write Your Own Load Balancer: A worked Example

I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv

Bloodstock 2009

This year was one of the best Bloodstock s ever, which surprised me as the line up didn't look too strong. I haven't come away with a list of bands I want to buy all the albums of, but I did enjoy a lot of the performances. Insomnium[6] sound a lot like Swallow the Sun and Paradise Lost. They put on a very good show. I find a lot of old thrash bands quite boring, but Sodom[5] were quite good. They could have done with a second guitarist and the bass broke in the first song and it seemed to take ages to get it fixed. Saxon[8] gave us some some classic traditional heavy metal. Solid, as expected. The best bit was, following the guitarist standing on a monitor, Biff Bifford ripped off the sign saying "DO NOT STAND" and showed it to the audience. Once their sound was sorted, Arch Enemy[10] stole the show. They turned out not only to be the best band of the day, but of the festival, but then that's what you'd expect from Arch Enemy. Carcass[4] were very disappoin

Catalina-Ant for Tomcat 7

I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml . For example: <tomcat-users> <user name="admin" password="s3cr£t" roles="manager-gui, manager-script "/> </tomcat-users> Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin : tomcat-juli.jar and three from TOMCAT_HOME/lib: catalina-ant.jar tomcat-coyote.jar tomcat-util.jar There are at least three ways of making the JARs available to Ant: Copy the JARs into th