Quality of the Deliverables

Every project must produce a deliverable to finish. A project to create a new application must, obviously, produce the application. A project to create a Windows 2003 domain must result in planning, designing, and producing the expected environment. No project manager would set out to create a new application and end with a print server—it just doesn’t make sense. Every project must have a clearly stated objective as to what the project will produce.

Producing a Service

Imagine a project that is designed to establish Routing and Remote Access Service (RRAS). The goal of the project is to allow users from the field to connect to resources on the LAN. Resources could include e-mail, printers, file servers, and databases. To end users, the experience must be just like it is when they are on the local LAN.

The project manager and his team complete the research, create a plan of action, and implement the new service. Of course, it’s all a bit more complex than this, but you see the big picture: conceive, plan, and achieve. The users, from home or anywhere in the world, connect to the resources within the LAN through a Virtual Private Network (VPN), as in Figure 10-1. A VPN allows users to connect to company resources through an Internet connection.

Figure 10-1: A project can deliver goods or a service such as a VPN.

To produce this service, the project manager had to see, and know, what the end results should be. The project manager worked with the project team and the project stakeholders to determine the exact requirements of the project deliverable. Research allows the project manager to create the vision of the project, leadership allows the project manager to transfer the vision, and dedication to the project allows the project team to implement the plan.

The good of the service is measured in value by several factors:

Value of the implementation What did it cost the company to create the RRAS solution and what are the measurable results? There is a cost-benefit ratio for the project. The cost of the project, let’s say it was $75,000, is in ratio to the benefits of secure, remote access. An ongoing process, as described in Chapter 8, must be executed to see the true costs and benefits of the implementation.
Value of the service After the project, there must be a process to measure the value of the service. Metrics are needed to measure the value of the organization before and after the project. The measurement of the service can be accomplished through tools to log the service’s usage. From the logged data, calculations can be enforced to see the amount of activity over a set period and the cost of each session. For example, the number of users accessing the LAN through the RRAS connection over a six-month period will reveal the usability while an increase in productivity through the RRAS connection can show the profitability of the implementation.
Value of the experience How well do the deliverables work? If the project manager has over promised the deliverables and the speed, reliability, or convenience of the service, then the value of the experience will diminish. For example, if the project manager has stated that the RRAS connections will be just as fast as if the user were on the LAN and this does not prove true, users will consider the service less than excellent. People may use the new ability to connect to LAN and access resources and retrieve their e-mail, but their focus will be on the slight delay through the Internet connection.

Value of the longevity How long will the service stay implemented? If the project manager and the project team have failed to adequately research the service and it is replaced within a year by faster, more reliable, and less expensive methods, the value of the longevity may be slim. In some instances, the service may be adequate for the time it is in place; in others, the service may offer little or no ROI. For example, if the project manager had offered the RRAS service through analog dial-up connections and offered no support for broadband connectivity, the thrill of RRAS would be diminished by the availability of broadband connections versus analog dial-up connections.

Value of the reliability How reliable is the implemented service? If the project is declared finished, but the service consistently fails or is unavailable, the quality of the deliverable is lacking. The service implemented must be reliable, and the underlying process of the service, whether it is hardware-related or depends on the skill sets of the individuals operating the service, must be reliable and able to fulfill the demands the service requires. For example, if the RRAS server is consistently unavailable because the hardware the RRAS software is installed on is weak and cannot handle the workload, then the hardware was not addressed properly in the planning phase and must be upgraded. The upgrade in hardware may cause delays in the service availability and additional costs to the organization.

Projects that produce services must be planned and implemented toward the end result of the service. A service deliverable must live up to the promises of the project manager, and the project team must have the skill sets and funding available to install the service for reliability and availability, and in proportion to the expected longevity of the service. As Figure 10-2 illustrates, a balance between the reliability and the cost of the implementation must be obtained.

Figure 10-2: Project managers must balance cost and reliability to obtain quality.

Project managers must work to ensure that the proposed service is not going to be replaced with faster, stronger, and better services within a timeframe that would squelch any ROI on the service. This is derived from the research and planning phases of the project manager versus the demand from management for an immediate solution.

Producing Goods

A project that requires deliverables be a tangible object, such as network, an application, a database, or an application server, has traits similar to those of a project creating a service. A project that creates a thing, however, has different measurements to gauge the quality of the product.

For example, imagine a project that involves creating software to allow customers to design a landscaping scheme. The application will walk users through a wizard that will build an ideal garden based on their area of the country, the amount of sunlight their lawns receive, the amount of color they’d like, the care of the plants, and other factors.

The software will be sold and used online. The interface of the software is not a typical web browser, but it does take advantage of the Internet connection to retrieve plant names, photos, and nursery information in the customer’s ZIP code. This application’s quality will be judged differently from that of a service, though it may have similar attributes.

Values used to judge a product are dependent on what the product is. For example, an application will have some characteristics of a service, whereas a laptop, a physical piece of hardware, will have different attributes of quality. For any goods, however, there are measurable values:

Value of the product Is the product worth the cost? A product that must be created, such as an application, has to allow the customer to get some level of satisfaction, enjoyment, or benefit from the product that has a perceived or measurable level of worth. For example, a computer game that sells for $39 must be, to the consumer, worth that money in enjoyment. The $39 investment is measured in the ability of the application to create fun, in this instance. In other words, does the product deliver on its promises in relation to the cost of the product?

Value of the usability Is the product usable? A product must deliver on its promises to be usable. The usability factor stems from the need for the product to exist. For example, a laptop is expected to complete certain duties. The need of the laptop is mobile computing. A project manager who manages a project to install and configure laptops for the sales team must know the level of usability the sales team anticipates from the hardware. The product itself is not the deliverable of the project—the satisfaction of the usability is the deliverable.

Value of the reliability Is the product reliable? A product must be reliable, functioning, and usable by the customer. A project manager who implements a device, such as a Personal Digital Assistant (PDA), is responsible for the quality of the device implemented. A PDA with batteries that burn up too quickly, doesn’t synch properly with a workstation’s software, or is difficult to use is not a reliable product. The project failed not because of the hardware—but because either the requirements of the stakeholders were not established or there was inadequate planning to meet the stated requirements.

Value of the longevity What is the product’s life cycle? Like the process of delivering a service, a product must also have a life cycle in proportion to its cost. A project manager who is installing web cameras for all workstations throughout a company does not want to learn after he’s purchased 2,546 web cams with moderate resolution that a new high-resolution camera has been released for less than the model he has just purchased. Today’s technology, or so it seems, is always outdated as soon as it’s purchased. A project manager, however, must be able to judge the life cycle of a product in relation to the ROI of the product. The project manager must calculate the cost of the product and how long the product must be used before the product becomes profitable.

Quality Versus Grade

Quality, within a project, is the capability of the project to meet the requirements of the project customer. Grade, however, is the ranking or classification of a thing or service. For example, you’re managing a project for the art department within your organization. The project requires six new printers for the artists. Two of the printers are inexpensive color inkjet printers, two of the printers are moderate color laser printers, and the remaining two printers are high-end image setters that print directly to film.

You have six different printers ranging in price and capability. All of the printers deliver on what they promise, but do they differ in quality? No. The printers differ in grade. Each printer is capable of printing under the specifications its manufacturer says it can. While the inexpensive inkjet printers are of a lower grade, they can still deliver on what they promise.

Consider also the grade of paper you may use with the printers. You can buy slick, photo-ready paper or cheap copy paper. Paper is paper, but the grade of paper can differ.

Low grade may not be a problem, but low quality is always a problem. Say one of your new printers consistently jams the paper, fails to print, smokes, or has other defects—that’s a quality problem.

Super Business - Project Management Articles

Quality of the Deliverables