by Ray Lightman

---

Project Management Tips: How to be a good Project Manager

Please join me as I follow the lifecycle of a project step by step. The 5 skills - organizational, communication, problem-solving, leadership and team-building - come into play in all 5 phases of a project:

1. Defining the scope
2. Creating a project plan
3. Getting the project off to a start
4. Monitoring progress
5. Wrapping up the project

1. Defining the project scope

The first thing to realize is that the client often does not know what he/she wants. Never start a project without first agreeing on clear requirements. This is what worked for me. I would start with a simple Project Overview and discuss it verbally with the client. Then I would go back and write up a detailed Functional Spec containing a Requirements Matrix. (I describe each of these documents below.) The more effort you spend here upfront, the less crises you will face in later stages of the project when things are harder or impossible to change.

A Project Overview looks like this:

• Problem description
• Goal - 1 or 2 measurable broad goals, achievable in the timeframe
• Objectives - a small list of specific sub-goals
• Success criteria - how will we know when we're done?
• Assumptions - ensure that there are no surprises later
• Risks and alternative plan - if something goes wrong, can we change direction?

Now that you understand broadly what the client wants, it's time to refine the requirements by writing a Functional Spec and a Requirements Matrix. A Functional Spec essentially tells the client and yourself what you are going to do. It should contain all the sections that were in the Project Overview, but more detailed versions of them. The Objectives should be broken up into functional categories and described in detail. What is a Requirements Matrix. It is simply a big table listing and numbering every single function that you are committing to implement. Here's a sample row from a typical Requirements Matrix that I write:

Req #	Description	Phase	Comments
39	Retrieve utilization information from deviceA	1	Will retrieve every 30 minutes

Sometimes, you may want to implement only part of a requirement. Split the requirement up into sub-requirements, number them, and relegate the unwanted ones to future phases. (You may even be able to get away with an unspecified date for a future phase item.) I might split the above requirement as follows:

Req #	Description	Phase	Comments
39	Retrieve utilization information from deviceA	N/A	Will retrieve every 30 minutes
39.1	Retrieve memory utilization	1
39.2	Retrieve disk utilization	Future

Tip: Carefully number each requirement and sub-requirement, and never change the number of a particular requirement. If you need to delete requirement number 46, don't renumber the requirements, or ongoing discussions will quickly get confusing. It's fine to have a gap between requirement number 45 and requirement number 47.

The Functional Spec should also contain a discussion of schedules and important milestones.

Tip: As you go back and forth with the client on the functional spec and the requirements matrix, it helps to keep a revision history so that people can quickly see if there have been any changes since the last time they looked at the document, who made the changes and when, and what the changes affect. Here is a sample revision history that I usually use; I put it on the page immediately following the title page. It's just a table containing the author, date and description of each revision, and it can be inserted into the (e.g. Microsoft Word) document containg the project functional spec. Keep the revision history on its own page; that way it can be ripped out once the final version of the document is ready to be handed to all parties concerned.

Date	Author(s)	Description
May 14, 2005	Ray Lightman	Initial Draft
May 27, 2005	Ray Lightman, Sammy Sidekick	Changed section 3.2 - utilization retrieval - based on discussions with Acme Corp.

While emailing back and forth various versions of documents, it is easy to lose track of which version is the latest. Always keep only 1 copy of any document, and store it in a shared directory or folder. All changes must be made to that master copy. All emails contain only a pointer to the document, not the document itself. Good organizational skills are invaluable here.

Tip: Involve a senior Architect or a researcher early in order to determine technical feasibility and to give the architect/researcher a jump start on understanding the big picture. (You may play the role of the architect yourself in small companies.) However, don't invest too much time on designing something before the contract is signed.

In this phase, you must NEGOTIATE. Negotiate objectives, success criteria, assumptions, milestones and schedules. The client may insist that their own QA (Quality Assurance) team test and validate your deliverables at intermediate milestones. This can be a huge time drain, and you should try to negotiate down. For example, you may try to persuade the client to reduce the number of intermediate checks to zero or a small number. Instead of letting their QA team actually run your code and validate it, you may be able to get the client to accept detailed designs of sub-components (algorithms and flow charts that your developers are already producing for their own benefit).

Now that you've successfully negotiated requirements, it's time to formulate a project plan.

All earnings from the ads on this page go 100% to charity. Please visit often and click on the ads - it doesn't cost you a thing.

<table bgcolor="#CCCCCC" width="371" border="0" cellspacing="0" cellpadding="2"> <tr> <td> <center> <!-- Project Management Link START --> <A HREF="http://www.anandnatrajan.com/FAQs/ray/PM/" TARGET="_top">Project Management Tips:<a/> How to be a good Project Manager.<a/> <!-- Project Management Link END --> </center> </td> </tr> </table>