Artifacts and Deliverables

Throughout the project, the team generates various artifacts and deliverables. Artifacts are documents of all kinds that are generated as part of the project, and deliverables are the specific documents and applications required by each phase of the project.

Some product information remains internal to the project team. Not all project artifacts are customer deliverables; for example, meeting agendas are not deliverables. However, all artifacts are important as either documentation or aids to the process. Usually, artifacts should be kept after the project is complete, as part of the project documentation.

Deliverables are the key elements that must be developed, built, and handed off throughout the project, and are externally visible to people in the organization who are not involved in the project. Some deliverables are documents; some are code or applications. All deliverables are important and should be kept for future reference after the project is complete.

Each artifact or deliverable should be communicated in the most effective way. For example, not all documents have to be printed. Distributing an agenda through e-mail or on the organization's intranet may be just as effective and less time-consuming. If a prototype is not executable, developing it as a Web site and thereby making it available to all interested parties at the same time, no matter where their location, might be the most effective way to communicate it.

Everyone should remember that the objective is to deliver a completed, useable application that meets the stated needs, not to generate mounds of paper. The team should be creative in its use of technology to communicate artifacts, to share results, and to move the process forward.

For example, imagine that a PowerPoint presentation is e-mailed in advance to all the participants in an online progress meeting, who are located in five different countries. The PowerPoint presentation is cued up on a projector at each location. The online meeting is then started and cued up on the same projector. Finally, a Web browser attached to the Web server at the home office navigates to the Web prototype on that server and loads the home page. During the online meeting, the participants alternate between the presentation and the browser, making comments and suggestions. Meanwhile, a developer incorporates as many suggestions as possible into the prototype and then instructs everyone to refresh their browsers to see the changes. In this manner, the group moves through the prototype, and at the end of the online meeting the group agrees that the prototype meets the stated needs. Such a scenario, considered the stuff of fantasy only a few years ago, brings an entirely new meaning to the phrase "rapid application development."

Although the team might not have access to such technology, or a given project might not warrant using it, team members should nevertheless take a close look at their assumptions about communication. They should think creatively in order to deliver effectively. Above all, they must be sure everything they do is moving them through the process model and toward the project's goal: a stable, useable product that meets the stated customer needs.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: