The Life of a Project

Projects have a lifetime all their own. Some are short-lived; I've written programs that were used for two weeks and then discarded when the business project was complete. Some programs go on forever, with continual improvements made over a series of version iterations. I'm typing into such a program right now.

As a developer, you should be aware of the lifetime of your project. Once you understand the lifetime, you can apply business processes to each major phase of the project's life. The skills needed to guide a project to its conclusion, or through each successive version of the project, are collectively called project management. Many organizations have dedicated project managers, especially for larger projects. For small projects, the programmer may have to carry the project management burden alone.

Fortunately, most project managers don't just make things up as they go (although I have met some who did). They work within a system, called a project methodology framework, which is a management system that keeps the project plan on track. I will hit the highlights of a typical framework in the remainder of this chapter. If you go back to the bookstore where you received a discount on this book, you will find a full shelf of project methodology framework resources. Microsoft even has its own recommended framework called the Microsoft Solutions Framework (MSF). Because most of the projects Microsoft develops are renewed through successive versions, the MSF is cyclical or iterative. For applications that, at least for now, will have one major release only, a linear approach works well. (See Figure 3-2 for both approaches.)

Figure 3-2. Two basic approaches to project management

Because this book will end with a completed project, and neither the next edition nor the movie rights have been arranged yet by my publisher, I will use the linear approach. Whichever approach you use, there are several major events that happen between the start and end of the line or iteration, beginning with the project kickoff.

Project Kickoff

Once everyone agrees that there should be a project, they all come to a big meeting to get things started. Everyone who is considered to be in charge of any part of the project is there: the technical lead (you), the key user, the project manager, and the person with signature authority. If you're writing a program for yourself, only you will be in the room, but you can still provide bagels. This event, the project kickoff, marks the official start of the project. This meeting of the minds usually determines the initial schedule for information and resource gathering.

Documentation

It's important to document everything as you go through the entire project, especially in the early design stages. Not only will this help you recall essential aspects of the project later during the development phase, but also it will help you keep all involved parties informed about the status of the project. Imagine this conversation with your boss:

Boss:		Management is asking about the status of the Hazel project. Do you have anything up to date that I can give them?
You:		Sure, I've got the project plan right here. I'll print you off a copy.
Boss:		That'd be great. Hey, did you see the new car Bernie in accounting just got?
You:		I know! How does an accountant afford a car like that?
Boss:		Beats me. It makes you wonder if he's cooking the books or something.
You:		Hey author, weren't we talking about documentation?

Oh yeah, documentation. Proper and complete documentation is important in any project. Precise documentation will keep Bernie from accounting out of the big house. And it will keep you in step with the project from initial kickoff to final delivery.

Depending on the scope of the project and the requirements of your organization, your project may need just some basic documentation, or it may need several three-inch binders filled with design documents that examine every nook and cranny of the system. Some project management documents require a signature before the project can continue. Others are informational only. As a programmer, the two most important documents are the main project design document (from which you will build the application) and the schedule (that lets you gauge progress during the project).

Project Goals

The first important item you will document is the set of project goals. If a project (or iteration) has a definite end, it should be possible to identify the major accomplishments needed for that ending event. These goals should be general, broad, and concerned with the final project deliverables. Deliverables are those items that are produced as a result of a project. They generally include software, user and technical documentation, installation media, and related materials. They can also include contractual and project management items, such as a proposed schedule for the next phase or iteration of the project.

The project's goals help determine its scope, the extent of the features and supporting materials that will be produced during the project's lifetime. Determining scope is important because it sets the constraints, the limits that will keep the project from going out of control. Although some aspects of the project may change throughout its lifetime, if you allow a project to continue without restraint, you will end up with something like Windows Vista: a useful product that was over a year late and had some features delayed until post-release.

Design and Planning

My mother recently gave me a rather old piece of paper with a drawing of a house floor plan. As I examined this paper in more detail, I found that the design matched the house in which I grew up, a house that is, alas, no longer part of the vast Patrick family real estate holdings. Yet it is still part of the vast Patrick family memory cells, and the home I remembered from my childhood was remarkably similar to the simple sketch. Some forgotten builder was able to take that sketch, add wood, windows and doors, red shag carpeting, and an avocado-green refrigerator, and turn it into a home.

Home builders don't work off of rough sketches. Between the sketch and the builder was an architect, a designer who set down on paper precise details about how to build the house. An architect provides a lot of detail, although not everything. The builder still has the choice of basic materials and construction methodology. But without the project planthe blueprintsthe builder would just be hammering boards together at random, and applying red shag carpet where it didn't belong.

During the design phase, you play the role of an architect, crafting the user's dreams and wishes into a design that can then be turned into a software creation. The level of detail required in these specifications will vary by project and organization. For the Library Project, the bullet items listed at the start of this chapter comprise the bulk of the design detail. (It parallels the level of detail my clients have agreed to in similar projects.) Other organizations require excruciating detail, demanding flowcharts, functional specifications and diagrams, and pseudo-code that is nearly as detailed as the final source code. For projects that include multiple programmers, you will likely have to specify the interfaces, the function or class member details that allow the code written by two different programmers to communicate accurately.

Whatever level of detail you include in your plan, you will also document certain key events that will happen throughout the entire project schedule. These milestones identify interim deliverables, results expected at specified moments throughout the timeline of the project. Comparing the milestone schedule against the actual results produced during development provides an overall view of how the project is progressing over time. Failing to meet several milestone deadlines may require an adjustment in the project schedule, cost, or scope.

Project Approval

A design document gives both the programmer and the user a point of agreement. Both sides can look at the design and say, "Yes, this is it; this is the plan." If the completed program is different from the proposed design, the user can say, "Hey, that wasn't what we agreed to." Sometimes the opposite happens; the programmer develops the application according to the plan, but the user claims that he requested something different. When this happens, the programmer can point to the design and say politely, "This is what we agreed to, and this is what was built."

To provide additional stability, the completed design usually includes a project approval document. This paper, signed by both the user representative and the development representative, says that (1) both sides have read the design document, (2) they agree with what it says, and (3) they commit to seeing the project through to completion as designed. As each representative signs off on the document, they pledge to give their support to the project.

The approval process also covers the project cost and schedule. A realistic estimate of the total time and costs needed to complete the project is as important as the project design itself. Any adjustments in the time and cost throughout the lifetime of the project can also provide valuable feedback on the progress being made.

Software and Other Development

Software development usually consumes most of a project's lifetime. Although the majority of work is done by the programmer or programming team, the user sometimes has a role in this step. By reviewing prototypes of specific portions of the application, and testing beta versions of the nearly completed product, the user remains an active participant in this long project phase.

Changes to the Project

In general, developers always complete projects on time, under budget, and with all features included, and the satisfied user joyfully installs the software, using it daily to meet demanding business challenges.

Ha ha. Now that you've had a good laugh, let's continue on with the chapter. Many projects do go well, and generally stick to the plan agreed to by the user and the developer. But other projects don't. Somewhere in the middle of the project's life, a change occurs. It may be due to difficulties in building the project, resulting in a schedule change. It may be due to new requirements in the user's needs (or desires), or in the related business process, resulting in a scope change.

Minor project changes may happen that neither the user nor the programmer is overly concerned about. But other changes can have a significant impact on cost or schedule, or both. Such changes can be documented and agreed to by both sides through a scope change document, sometimes called a "change order." If the development team must adjust the schedule, or reduce or change the included features of the application, communicating this to the user through a scope change document keeps the user from being surprised at the ever-advancing end of the project.

Using scope change documents, and requiring sign off from both sides, also helps prevent scope creep, the continual adjustment or expansion of software features included in the final product. As users see the progress you are making on the project, and what a great job you are doing, they may show their confidence in you by adding to the project, certain that you can complete the additional work well within the original timeline. Funneling all change requests through the scope change process provides a reality check to the user, giving him a sense of the effort (in terms of cost and schedule) required to develop software.

Acceptance Criteria Testing

There will come a day when you will say, "There, that's the last line of code I need to write for this project." Of course you will be wrong, but it will feel good to say it. The real last day of coding won't be for several more weeks, after all of the testing is done.

Unit testing concentrates on the individual components, even down to the class and method level. It ensures that each component or code block returns expected results when given specific input. Both good and bad inputs are sent into the components, and the results analyzed. Unit testing is actually the most cost effective form of testing, because it is not concerned with the complex interactions of the various components that make up the entire system.

Interface testing is concerned with these interactions. Components that interact with each other are tested as a group, to make sure that they work and play well together. Components that expose public interfaces are also tested for consistent results and secure access. System testing gives a chance for users to have at the product, doing all they can to certify that the entire application works in a real-life setting. Beta testing is part of the system testing process. System testing may also involve stress testing, where the system is tested in extreme computing conditions to see if it can support the load. Testing various installation scenarios ensures that the new software does not negatively impact other software or operating system components.

All of these testing phases are important, but there is one more type of testing that has a direct impact on the progression of the project: acceptance criteria testing. This involves a checklist of testable items that both the user and the programmer agree must pass successfully before the project is considered complete. This phase may cover items found in the other phases of testing, but it might also check for basic elements and features, such as the inclusion of quality documentation, or the delivery of the software on a certain medium, like a CD-ROM. Once acceptance criteria testing is complete, the user signs off on that phase, and the project moves to final acceptance.

Project Acceptance

You've worked long and hard. It's been difficult at times, and perhaps you weren't sure if you would ever finish. And I'm just talking about this chapter. Some projects take quite a while to complete, and by the end everyone should be ready to see the fruits of their labor. The final step in the agreement portion of the project is the project acceptance document. This paper, signed by the user, says that the project was completed as requested (or as modified through change orders). Once signed, the project is officially complete. The programmer is now handsomely paid, and takes a well deserved three days off.

Deployment and Distribution

The project is now ready for installation on each user's workstation. The method of distribution and delivery depends on the project and target audience. Whether it's an internal network distribution, CD distribution to a small number of locations, web-based distribution to the general public, or boxed media product for sale in retail stores, the programming team usually has limited interaction with the target workstations. Of course, that can change quickly once the technical support phone line is plugged in.

Ongoing Support

After the product has been in use by the user population for a while, reports of application errors or desired enhancements may trickle in to the development team. These can be collected for consideration in a future versioned release, or acted on immediately in "service release" updates of the product. As you may have multiple versions of the product in use within the user community, it is essential that you are able to identify and test against any particular release. Source code control systems (including Microsoft Visual SourceSafe that ships with some editions of Visual Studio) allow you to maintain version-specific images of the source code. You can also maintain an inventory of release executables and other files for later testing.

If your application was written for a single customer or organization, there may be a warranty period where some or all errors that are reported during the length of the warranty are fixed free of charge.