Although not about Web development per se, this excellent book is one that a lot of Web developers would do well to read. Building a Web site is a project, and good project management skills are essential to any Web developer, whether one thinks about project management in formal terms or not.
May 19, 1998
Project management is one of those management "disciplines" that often make one think of academic-sounding jargon, endless planning to plan to write reports about planning to plan, and, let's face it: wasting a lot of time and paper instead of simply sitting down at the keyboard and getting to work. For large projects, however, just jumping in and getting to work without proper planning and documentation is a recipe for disaster. Information Systems Project Management never gets lost in jargon, and is quite readable. The author is an IT professional, not a college professor, and the emphasis is on real-world workplace situations. Mr. Hallows has a healthy cynicism, as well as the type of dry humor that is perfect for this sort of a book.
Mr. Hallows never forgets that project management takes place in the real world, not in some management laboratory (my God, are there really such things?). No, one doesn't "build a project team", one makes the best of the team that the company gives you. Yes, people in authority often do fight against the project manager, for reasons that have nothing to do with the good of the company. Yes, projects do fall behind schedule, and go over budget, and this is not always a disaster. The key is to plan for such contingencies, and to minimize their negative impact. Information Systems Project Management describes such situations, and offers ideas for dealing with them, with appropriate world-wise wit.
Like a properly planned project, the book is divided into the following major sections:
Understanding the Project
Defining the Project
Planning the Project
Running the Project
A chapter on Management Skills rounds out the fun. Included here are advice on how to listen, how to gather information, how to bear bad news, managing your time, and running effective meetings.
Understanding the project includes, first of all, justifying the project. Project "justification" is a specific term that must be quantified in Dollars (or Pounds, Francs, Bhat or whatever). How much money is the project expected to make or save for the organization? It's also essential to understand the background to the project. What's the history of this project? Who are the players? What are the political issues involved? What are the client's priorities?
Defining a project means defining the scope, the deliverables, and the project team. It also includes putting procedures in place for notification, escalation, review and approval (When does higher management need to be notified of a problem? When do they need to be asked to kick a butt? When and how will they review and approve deliverables?).
Planning a project involves a fairly well-defined series of steps. Project risks, assumptions, and constraints must be identified, and plans made for various contingencies. How do we minimize the risks? What do we do if one or more assumptions is not met?
There are various ways to organize a project. The appropriate structure depends on the nature of the project, and the culture of the organization. A lot of Web shops pride themselves on their "flat" organizational structure, and some of the programmers may be pimply teenagers who are making more money than the project manager. Organizations like this will need to structure projects a little differently than would a law firm or a bank.
Perhaps the heart of project planning is the Work Breakdown Structure. Define all the activities that must take place to get the project done, identify dependencies (which activities are dependent on other activities), make estimates of manpower and other resources needed for each activity, "level" the resources (that is, plan the most efficient way to use them), prepare a schedule and budget, and there you have it, sir: a Project Plan!
Oh, yes. There is one last little detail: Running the Project. Tracking progress and making periodic reports to the bosses are important. However, as we all know, there will be scope changes, there will be problems with subcontractors, and the project will fall behind schedule (slippage). Worst of all, there will be meetings. The key, as Information Systems Project Management repeatedly stresses, is to plan for these events, and know in advance how you will deal with them.
Throughout the book, sample lists and forms are provided that you can adapt to your own projects. Some of us may never feel the need to fill out a form for every Risk and Assumption associated with a project, but these are things that we at least need to think about. Standard project management terminology is used throughout the book, but there's no gobbledygook.
One thing that delights me about this book is that it is free of errors. My eagle eye detected not a single error in spelling, grammar or punctuation. I am sorry to say that this is literally the only book I have reviewed lately (out of dozens) that did not contain errors aplenty. Guess what? Information Systems Project Management also happens to be very well-written, and full of useful information. Gee, I wonder if there's some sort of correlation here? The book is also well-bound, and printed on good-quality paper.
This is an excellent book, and is highly recommended. I eagerly await further offerings from Jolyon Hallows, the author, and AMACOM, the publisher.
