Chapter 3. Introducing the Project

You’re sitting in your office, surfing the . . . I mean, reading up on the latest technology issues most pressing to software developers. You’re minding your own business, when boom, someone walks up to your desk, and offers to pay you money to write them a program. It happens every day, all over corporate America; and sometimes it just makes me sick.

But enough about my health problems. This desk-hovering somebody informs you that you must develop a software application, possibly a database application with a user-friendly interface. Although the feature set will be specified by the primary users, you, as the lead (or only) programmer, will design, document, develop, and deliver discs dripping with distinguished, dazzling, and dynamic digital . . . um . . . software. (Darn.)

Well, that’s what happened to me. A client of mine had a large collection of books that needed to be organized as a traditional library. Seeing that I was a reasonably codependent software architect, the client asked me to develop some software to manage the books and such. Out of this request came the Library Project.

As you read through this chapter, you will have to keep my day job in mind. I write custom Visual Basic applications for small- to medium-sized organizations. Most of the projects are sized so that I can complete them by myself, including all design and documentation requirements, in less than a year. All of my projects involve a “key user,” one person—or sometimes a very small group—who speaks for the user community. These projects also involve someone who has “signature authority,” a person authorized to pay for the project, or decide on its continued existence. This individual may be the same as the key user.

If you were developing, say, a replacement for Microsoft Word, you would likely lack a “key user.” To obtain the specific requirements for the project, you may have to conduct general user interviews with dozens of user candidates. Or you might create a “virtual user,” a fictional person who represents your intended target audience. Whichever method applies to you, the general discussion in this chapter should guide you to the happy conclusion: a design document that you will use to build the application.

The Library Project

My client needed a program that would manage a database of books and media items, and control how those items moved between bookshelves and patrons. The software needed to have both patron- and administrator-focused features. It would include various reports, including the printing of a receipt of checked-out items for the patron. And most of all, it needed to both print and read barcodes.

It sounds like a lot for one man to do, and it is a sizeable project. But I don’t have to do it alone; you will help me. Together, through the pages of this book, you and I will design that program, and develop that code, and bring joy to the users, and collect that paycheck. Actually, I will collect the paycheck, although it wouldn’t hurt to ask your boss to pay you to read this fine book.

The remainder of this section documents the key features of the Library management application.

Library Item Features

The Library system will manage an inventory of books and other media items, locate them, and manage the details and status of each copy of an item. To make this a reality, the Library program will:

• Allow patrons or administrators to search for items currently in inventory. The program allows searches based on several different properties of each item.
• Support multiple search methods, including by title, author name, subject or topic, a miscellaneous keyword, the name of the related publisher, the name of a series or group that contains the item, or a barcode number attached to the actual item.
• Limit search results by the location of the item, or by the type of media (book, CD, DVD, and so on).
• Support the definition and use of distinct physical locations. The client has books and media stored at three different sites within the building, including a storage closet for seldom-accessed items.
• Display the details of a retrieved item in a familiar browser-style interface. For instance, when looking up a book by title, the user clicks on the author’s name to access all other items by that same author.
• Allow access to each library item through a barcode scan. As is common in most libraries today, the items in this library’s collection each have a barcode affixed, which serves as a unique identifier for the individual item copy.

Patron Features

In addition to books and other items, the program manages a list of patrons, the “customers” of the library who are permitted to check out items. To support interaction with patrons, the application will include these patron-specific features:

• Items can be checked out to patrons, and checked back into the library inventory.
• All patrons are assigned a “PIN” that acts as their password.
• Patrons can check out items without librarian and administrator assistance. They can use a barcode scanner to scan a patron library card and library items.
• The “media type” of an item determines its checkout (and subsequently renewal) duration.
• Patrons can view their library record, including all books currently checked out, and a list of fines owed to the library.
• If permitted on a specific item, the patron can renew an item he or she has currently checked out.
• Patron-centric online help is available through the standard F1 key. This help file includes no information on administrative features, so as to reduce experimentation.
• Patrons can be divided into “patron groups” for the reporting and processing convenience of the administrative staff.

Administrative Features

Administrators include librarians, information technology staff, and others who need advanced access to application features. They are the primary users of the system, not the patrons. The application includes the following administrator-specific features:

• A login feature provides access to the administrative features of the application. Only authorized users can log in through an assigned password. The login feature is normally hidden from view from ordinary patrons.
• Administrators can view patron details just like patrons can, but they also have access to additional patron details. Specifically, administrators can add new patrons and manage their identity and demographic details. Administrators can also disable a patron record to prevent further item checkouts.
• Administrators collect and manage patron fines, including the ability to add non-standard fines, or dismiss unpaid fines.
• Administrators define the records for each item managed by the system’s inventory database. This includes the basics of each item, such as title and authors. Each item includes one or more copies, which represent physical items that can be checked out. Barcodes are assigned to copies.
• Beyond the items and copies, administrators define all supporting values and lists, including author names and categories, the list of media types, publishers, book series names, status codes that identify the disposition of each item copy, and locations.
• Designated administrators can add, edit, and remove the accounts of other administrators. Each account includes feature-specific authorization settings (group rights).
• In addition to the scanning of barcodes, the program can assist administrators in the design and printing of both patron and item barcodes.
• A simple program-managed process allows the administrative staff to process overdue items and fines on a regular basis.
• The application allows holidays to be added and maintained. When a patron checks out a book, the program adjusts the due date of the item to avoid holidays.
• Administrator-centric online help provides assistance to the enhanced features of the application through the same F1 key available to patrons.
• The application includes some basic administrative reports, and the ability to “plug in” reports as needed in the future without the need to update the program itself.

The Application as a Whole

Beyond the basic features of the program as experienced by the patrons and administrators, there are a few other requirements.

• The program is “user friendly” and easy to navigate, especially for patrons, without much training or assistance.
• The application stores its data in a SQL Server database.
• Distribution of the application is done by administrative staff that has local administrative privileges, so a standard Windows installation package is sufficient.
• Configuration of the application uses standard XML methods.

Except for these general and feature-specific requirements, I was given design freedom. But where did the listed requirements come from? They came from the users, the masters of the application. It was their needs—the needs of my customers and theirs, who would be using the product day in and day out—that determined the list of requirements.

The Needs of the Users

Back in the old days of computers, there were no users. Who needed users? The only ones manly enough to approach the hallowed inner sanctum of the computing systems were the programmers. Only they touched the vacuum tubes, connected the cables, toggled the front panels, and fondled the punch cards that provided access to the heart of the machine. These programmers were tough, and their programs, tougher. “We don’t need no stinking users” was their mantra.

Then came the ’80s, with its Greatest American Hero-inspired attitude and its personal “personal” computers. Now there were users everywhere. They were like the Blob, only with fewer computing skills. But they were the masters because most programs were written for them. Programmers rarely used the programs they wrote; they were simply the interface between the user and the heart of the computer. Programmers provided the element of control needed by both the computer and the users. In fact, that is a programmer’s job: to provide highly controlled access to the computer and the data it contains.

Users have a lot of needs, most of which can’t be met by a computer. But for those that can, the needs come in five parts: data and information, process, usability, commonality, and project-specific needs. The design process involves an examination of these needs and the subsequent massaging of those needs into a software product. By examining the current data and procedures, conducting user interviews, and performing other need-extraction methods, you gather the details you require to craft the right solution.

Data and Information

Your ability to provide convenient and specific access to the data and information required by the user is what makes you, the programmer, so loveable. Most users got along just fine before computers. They kept their information on 3-by-5 index cards, legal pads, scrolls of parchment, or in hermetically-sealed mayonnaise jars. But they had a reason to move to a computer-based storage medium: the convenience.

Data is the raw information stored by your program: names, numbers, images, or any other stand-alone values. Information is data in context: a customer record, an order, a slideshow. When you provide a quality program that moves data up to the level of information, you are providing the level of convenience the user needs to move from mayonnaise jars to silicon chips.

Process

When the user demands data back from the computer, you have three options.

1. Dump every single byte of data to the screen, printer, or disk, and let the user sort it out. Actually, this is the system that some users had before they started using a computer.
2. Protect the data from user access, insisting that the supplied password is invalid or expired, or that the data is unavailable. “Abort, Retry, or Fail” anyone? Actually, this is the system that some other users had before they started using a computer.
3. Present the data as information, in a format that is both usable and accessible.

Although the first two choices are indeed tempting, the third option is the best. And given the amount of data that your application will likely manage, you will have to dole out the interaction with it a bit at a time, and in an appropriate sequence. This is process.

Through the implementation of a valid process, you not only control the user’s data, but also you control the orderly interaction with that data. Most users need to supply or retrieve only a small portion of their data at a time. But when they do, it will usually be in the context of some process. For instance, in an order-taking situation, the user (1) enters or confirms the customer’s contact information, (2) enters or updates the order details, and (3) prints or electronically communicates the order information so that it can be fulfilled. Your application (surprise!) manages this three-step process.

Usability

If your program presents data and information to the user, and in a specific arrangement or order, but is difficult to use, your users will hate you. They will loathe you. They will spread mean stories about you, true or not. And when they appear in groups, their vehemence can get downright ugly. I heard this story about an Excel user’s group . . . but perhaps it was just a rumor.

As a programmer, it is your job to make the computer, and the software that runs on it, as usable as possible. And while you may not be able to control many of the basic system features, you are the king when it comes to your own software.

The more ease and usability you design into your programs, the happier your users will be. But I must warn you, ease-of-use for the user always means more work for the developer. Always. It’s one of those unfair laws of the universe, and there is no way around it. But sometimes we try—to the user’s peril.

Many, many years ago, I wrote some programs to demonstrate a hot new version of BASIC that ran on the Motorola 6809 processor. This release could handle programs that were twice the size of the previous version: a whopping 32Kb of source code. I was charged with testing the system, writing “big” programs that would show off the new functionality. I set to work in a fever of activity, but as my program approached about 27Kb, things started to happen, things that involved a shaking table and the smell of smoke. Seriously!

Since then, I have subconsciously feared the development of programs that I felt were too large for a particular system. So when I went to work on Visual Basic, I brought to my projects some of this apprehension. I tried to make my programs easy to use, but I also held back on the number of forms I would add to my projects. It wasn’t an irrational fear; the original versions of Visual Basic did impose limits on code size, the number of unique variable names, and the maximum number of forms. I once hit the limit on the number of unique variable names, but I never came close on the number of forms. Still, I held back. I was sure that if I added too many forms, my users would require medical attention for smoke inhalation.

Unfortunately, my users were still suffering. I had put too much data on each form, to the point where it was no longer communicating information. My phone would ring constantly with the same user-sponsored question: “How do I use the fields on such-and-such a form?” Of course I always said, “Why don’t you press the F1 key?” But it didn’t make a bit of difference, because my online help pages were as long and complex as the forms they sought to simplify.

There did come a day when I escaped my phobia of form-laden applications. And on that day, I came up with the following rules for my own programs.

1. Don’t put too much information on a single form. When in doubt, move some information to another form.
2. Only present the most necessary information and data to the user by default. Only show additional information if the user requests it.
3. Make it easy for the user to access the enhanced data, but allow the program to run properly without it.
4. Use text, graphics, and colors to the user’s advantage.
5. Simplify the application so that user documentation becomes unnecessary.
6. Always provide user documentation. Make it simple enough so that calls to technical support become unnecessary.

These rules are generic enough to work with any type of application, and in-your-face enough to make them meaningful to us, the programmers, and to them, the users.

Commonality

Microsoft constantly touts innovation, and the ability to innovate has moved software products forward at a tremendous pace. But unfortunately, users can handle only so much innovation at a time. Consider the telephone. I inherited an old oak-boxed telephone from my grandparents (see Figure 3-1).

Figure 3-1. What a great phone!

It’s a fun phone and so simple to use. When you want to make a call, you pick up the handset and crank the handle on the side of the unit for about three or four seconds. When the operator comes on the line, you tell her whom you wish to call. What could be simpler? What could be more user-friendly? What could be more expensive than an operator-assisted call? But it was simple, and everyone instinctively knew how to use it.

Today’s phones use buttons instead of cranks. Most of the buttons are simple digits that let you directly dial a specific phone number. But there are other buttons as well: Mute, Redial, Pause, Flash, #, and *. I’m afraid to push the Flash button, and what’s with the SND and CLR buttons on cell phones? The problem is not the buttons themselves, but that every phone has a different selection of buttons. They have lost the commonality that made crank phones easy to use. Sure they have many more features, but if the average person can’t figure out how to use that functionality, what is the benefit?

Getting back to software: Even new and innovative programs must retain some commonality with the operating system, and with other installed programs. As you speak to users about their needs and think about the great advancements in software technology you will provide, don’t forget about commonality. Don’t forget about one of the user’s core needs: the need to not be overwhelmed by new ways of doing tasks they thought they already could do. Users need consistency.

Project-Specific Needs

Beyond the general user needs required of every project, there are needs specific to each project. As an application designer or software architect, this is where you spend most of your time. If you have a lot of programming experience, you may be able to fulfill the other needs without ever meeting with a user. But the project-specific needs require an understanding of the tasks that the user needs to accomplish with the proposed application.

Once the users discover that you have a real interest in their needs, they may dump on you. They might start listing off a whole wish list of features, more features than they could ever use. That’s okay. When they hear how much time it will take or how much it will cost to implement, they may back off of a few requests. The important thing is to document everything. Write down what the user asks for, combine it with a reasonable time schedule (always) and cost estimate (if required), and return it back to the key user for confirmation. If possible, have the user sign a document that says he agrees with the specific requirements listed in the document.

It is essential that there be agreement on the project design, at least for the initial phase or release. Because user’s needs are so often a moving target, it is vital that an agreement on the project exist at some point in time. Later, after you have begun work on the project, the user will come to you, probably on a daily basis, and say, “Hey, that’s not what I asked for.” When that happens, point to the agreement and say, “Hey, yes it is.” Changes will occur; I’ll discuss how to handle those a little later in this chapter.

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:

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 plan—the blueprints—the 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.

Summary

Projects are more than just source code. From design documents to project management tools to online help integration to web-based support functionality, a project encompasses resources that go way beyond the basic task of coding. If you are a lone developer, you will have to wear many hats to fully support the application. Those who are part of a larger product team don’t have to worry about every possible component of the project, but they also lose out on some of the joy that comes with working on every aspect of a project.

Project

There are many tasks to complete before coding begins in a large project. The actual coding of the Library Project starts in Chapter 5, “.NET Assemblies.” For this chapter, I will complete the project agreement document that describes the Library Project features.

This chapter does not include a Visual Studio project template that you can load and examine in Visual Studio. Instead, you must access the Chapter 3 subdirectory from the book’s installation directory. This subdirectory contains three files.

• Project Agreement.doc. This is the primary project document that identifies the features of the completed project. It is agreed upon by both the developer and user representatives. Deviation from this document only occurs through the “Change Order” process.
• Change Order.doc. This file is used to modify the original project through the “Change Order” process. When using this document, include a description of the change to be made to the project, and any schedule and cost impact.
• Project Acceptance.doc. This file is used when the project is complete, and the user is ready to accept the finished product. This document combines the “Acceptance Criteria Testing” and “Project Acceptance” elements described earlier in the chapter.

Please feel free to use these documents to support your own projects. However, the legal team at Addison-Wesley would like to remind you that if you choose to use these documents, you’re on your own, bucko. These documents are meant as examples only. You should talk to a lawyer in your state if you wish to craft your own documents similar to these and have them be contractually binding.

The remainder of this section presents the “Project Agreement.doc” filled out with the details of the Library Project. Its primary content is a copy of the bullet items listed in the “The Library Project” section near the start of this chapter. It also documents some other project-specific requirements, and includes a typical estimate of project costs. For demonstration purposes, I have used an hourly rate of $25.00.