Project Management

We re afraid the days of considering building a model car project are over. Software development is a full-time job, and indeed many organizations have at least one individual who operates under the title Project Manager to help make sure that a project is completed successfully.

So far, we have talked about gathering requirements and the design and analysis phases, and the preceding section described change cases to handle program changes. We ll now discuss the final topic (which really isn t technically a programming issue): project management. We ll begin our discussion differently from any of the previous topics with the assumption that the designing, coding, and testing phases are already or nearly completed.

You can choose from a number of commercial packages to assist you in project management, such as Microsoft Project for general projects and StarBase StarTeam for software development projects. These applications basically help you to track and plan project progress.

We will take a hierarchical view of project management. Starting at the top, we will begin to drill down into the smaller details and identify some of the key aspects of each level.

Clients

This is a really a good place to start because the clients are the people who pay us. Keeping track of your clients is, of course, a primary goal. A client is usually a company, though some organizations develop software internally, in which case a client may be another department or cost center.

You should make sure you keep track of every contact at your client company, even if they leave. Keep their name , address, e-mail address, phone number, cell phone number, and so on. Make sure you have a good relationship with them, and know what they are responsible for. Identify who pays the bills, who approves the bills, who defines the business rules, who provides technical support, and so on. This sort of data is fairly common in all businesses, so it should be fairly straightforward.

It never hurts to provide a follow-up call on a project just to check the status and satisfaction of the client. Software development is a service-based business, and if your clients feel that you are providing a professional service, your success is all the more ensured.

Projects

Clients have one or more projects. All the design and analysis work we have done so far is organized into a project somewhere. A project is typically an application, system, or major change. An application is an individual program, whereas a system is a set of applications. A major change is an extensive amount of work needed to modify or change an existing application or system.

Projects should be documented with a brief description, a more detailed paragraph describing the system, the scheduled completion date, and the status and priority of the project. When we define the status of a project, we typically say it is either Initial Design, Pending Approval, Approved, In Progress, In Release, Completed, or Deferred. Priority is simply High, Medium, or Low.

Work Requests

Projects are made up of work requests, which define specific requests of the client. This is a very broad definition. A work request may be found at the very start of a project for the very first client meeting, or for a bug found in the system after it is placed into production.

Work is typically assigned one of the types shown in Table 10-1.

Table 10-1: Work Assignment Types

Type	Description
Work Request	A request to do some thing, such as create a backup, generate some statistics, or attend a meeting.
Defect	A defect is a bug report or a bug within the system.
Support	A request for assistance on a specific issue on the system.

Work requests typically have a brief description and a more detailed Notes section. The following items refer to the request, and a Solution section may also be present:

• Project University Registration

• Work Request Identify why reports are printing in landscape orientation

• Type Support

• Notes All reports printed in room 212 are printed in landscape.

A work request also has a priority (High, Medium, or Low) as well as a status and a responsibility. The Responsibility field identifies the person in your organization responsible for completing the work request. The status of a work request is typically one of the options shown in Table 10-2.

Table 10-2: Status of a Work Request

Status	Description
Pending Approval	The request must be approved before it's begun.
Approved	The request is approved and ready to begin.
Deferred	The request was deferred and may be reinstated later.
Closed	The request was closed and will not be reinstated later.
Duplicate	The request was a duplicate of another request.
Documented	Typically for bugs , this status indicates that the user misunderstood how the system operates, and they think a particular operation is problematic when in fact it isn't.
Completed	The request has been completed by your company.
Verified Completed	The client has agreed that the request is completed to their satisfaction.

Systems can also determine whether a work request may generate other work requests. That is to say, someone may be assigned a work request of Design registration system. That person then creates work requests for their employees , breaking this monolithic request into smaller requests, and so on. Managers use work requests in this manner.

Finally, a work request may be considered a milestone or significantly important somehow. The milestone may be the completion of a project or the end of a work request that indicates another pending request may now be started. Where applicable , you should document the milestones as well for the requests.

Tasks

Tasks represent the lowest detail of work, and work requests are linked to them. Tasks are often used for the purposes of estimating and billing. As a programmer, you may receive a work request of Create enrollment form. You would then enter one or more tasks to complete this work, with an estimate of the amount of time each will take you.

Once the tasks are begun, you would normally record the amount of time each task takes. Companies may have various rules of thumb on how these tasks are organized, such as stating that a single task should not take more than eight hours. So, what do you do if you estimate a task will take 40 hours? You break that single task down into smaller tasks.

Clients and end users normally don t see the tasks, as they are intended for the people who normally do the actual work (such as programmers) and their managers. They provide the estimates and hourly accounting needed to manage a project. Where possible, you should put in as much detail concerning your tasks as possible.

Tasks also have a priority and a status, with the status typically being one of the options in Table 10-3.

Table 10-3: Task Status

Status	Description
Open	The task is defined, but not yet begun.
In Progress	The task has begun.
Completed	The task is completed.

Estimation

Estimation can be an art form. No one but you can guess how long it will take you to perform a certain task. However, by knowing what needs to be done, breaking the estimates down into manageable tasks, and knowing your own abilities through your own experience, you ll find that estimation isn t very hard. Although an estimate is just that (an estimate, not a guarantee), you should make every effort to provide fair and accurate estimates.

The first step in the estimation process is to quantify. If asked to create a form, you have to know whether there are two edit boxes on that form or 20. For those edit boxes, you have to know which ones are stored in a table and which aren t. You also have to know which tables in a database are affected by the edit boxes, and so on.

Hopefully, these items are completely addressed in the design and analysis specification, like the user interface prototype described earlier.

You also have to know how to estimate each individual item. If the task is for something you are familiar with, this will be easy. If it s not a familiar task to you, however, this is where the real estimation process comes in. Based on your own talents, you have to guess how long it will take you to complete a task you may never have done before.

In these situations, you would do a small amount of research, try to gauge the task s difficulty, and compare this with your own expertise and ability to learn new things. Don t look at a new task and think, Okay, two hours. Instead, do some research and try to be accurate. Then again, you don t want to suffer from analysis paralysis, where you spend all your time thinking how you will perform the task.

Programmers have a tendency to fall into dangerous waters with estimates. Case in point: I had a specification for a program I knew had to be completed in two weeks. I gave that spec to a programmer and requested an estimate. About four hours later, the programmer returned with an estimate of exactly 80 hours, or two weeks. Although this was great news, I really had to question the programmer about the coincidence of the estimate matching exactly my deadline. Sure enough, the programmer s response was, Well, you said you needed it in two weeks, so I ll do it in two weeks.

Such thinking makes a project manager s job a nightmare. Estimates aren t used just to see how long you think something will take, but rather to manage a project. If the programmer came back to me with a three-week estimate (which turned out to be the real case), I would know that I needed to add another programmer to the project. However, by trying to fudge his estimate to make me happy, he denied me the ability to make that decision.