Organizational Architecture

In the context of the Project Framework, the role of the project manager is to recognize and adapt to the organizational architecture to accomplish the project objectives. This section on the constraints of organizational architecture describes the relationship between the quality organization’s structural composition and the project manager’s responsibility for delivering project quality.

Describing all the permutations of organizational architecture is nearly impossible. This section concentrates on accomplishing projects in two divergent organizational architectures:

1. ■ Delivering project quality in conditions where process-driven quality methodology and delivery processes are well established.

2. ■ Delivering project quality in conditions where no quality infrastructure exists.

Traits of a Well-Established Quality Organization

A well-established quality organization is recognizable by these traits:

1. ■ Integration with business units (strategic and tactical).

2. ■ Measurable targeted improvement of delivery processes for goods and services.

3. ■ Decreasing customer issues with delivered goods and service as they transition through the product life cycle.

4. ■ Verifiable and consistent level of positive customer satisfaction across the product and service portfolio.

Figure 27.1 shows an example of an organizational architecture that integrates the quality organization and project management into the business enterprise. Note how this organizational structure aligns the chief quality officer with the chief information officer. The structure positions quality assurance and control groups to deliver financial benefits to the enterprise. Although the cost of quality is measurable, the groups are rarely organized as a business unit.

Division of Responsibilities

The responsibility for maintaining project quality and for delivering a quality product resides with the project manager. The specific quality management tasks, however, are distributed (shared) between the project manager and the quality managers who are assigned to manage the test preparation, execution, and reporting.

The quality-related project responsibilities include the following:

1. ■ Reporting the project status—communicating whether the test cycles are tracking to the plan.

2. ■ Assessing the project status—analyzing the test results to predict whether the test cycles are tracking to the plan.

3. ■ Communicating changes—project change management activities including project scope, schedule, and cost, as well as quality.

4. ■ Defect tracking and review—validating that obligatory rework is logged, assigned, completed, and validated.

5. ■ Ensuring that resources are engaged—rolling on and off the project according to the benefit of the project.

6. ■ Continuous process improvement—capturing and applying the knowledge gathered from analysis of the inputs and outputs of quality processes. The analysis includes evaluating the efficient use of tools, understanding how test techniques and processes might be enhanced, as well as appraising the parity between technical training and test environments.

7. ■ Ensuring that the quality organization aligns the producer’s view with the customer’s view.

Organizational Relationships

The project manager’s relationship with the quality organization either enhances or reduces the probability of project success. An often-overlooked dynamic is how the project manager interacts with the QA and QC teams.

Table 27.1 summarizes the positive and negative perceptions that affect the project manager’s relationship with the quality organization.

Using the Project Framework Where No Quality Infrastructure Exists

Project managers who encounter an organizational structure where no formal quality infrastructure exists usually find signs of ad hoc testing. Although ad hoc testing (exploratory testing) is a productive approach when combined with formal testing, ad hoc testing described here is done with either little, or no, documentation or planning and is the sole testing approach.

The following are some of the organizational behaviors that characterize ad hoc testing:

1. ■ The releases of new functionality and bug fixes are allowed to “soak” in a preproduction environment to determine if the modifications caused unintended results in existing code.

2. ■ The end users validate whether the product meets their needs when developers release versions of the product with new functionality, including bug fixes, into the production environment.

3. ■ The product support effort is equal to, or greater than, the development effort. The same relationship exists between support costs and development costs if they are tracked.

4. ■ Product engineers are inundated with a backlog of user requests for bug fixes and enhancements.

5. ■ There is no consistent effort to measure the comparative quality of goods and services across the product and service portfolio.

Ad Hoc Testing and the Project Framework

The key to harnessing ad hoc testing for project benefit is to exploit the Project Framework’s emphasis on the traceability between requirements and the test effort.

In an earlier section, we established the link between the project scope and product scope by saying that the product scope describes the characteristics of the product (or service to be delivered); the project scope specifies the work that must be done to deliver the product. In effect, the project manager uses the ad hoc testing activities to align two views of quality: the producer’s view and the customer’s view.

Using a Traceability/Validation Matrix

The project manager uses a simple matrix to track the progress of ad hoc testing and estimate the level of product quality. The matrix combines requirement traceability with functional validation, as shown in Table 27.2.

The matrix format organizes the business and technical (system) requirements into functional areas for validation by the end user. When the end user determines that a functional requirement meets expectations, he or she indicates acceptance in the matrix. The matrix also shows functionality that is rejected, but does not show when the functionality is ready for retest. The project manager follows the project change control process to manage and report the progress of test and retest.

The traceability/validation matrix relies on the availability of written functional and technical requirements. If no formal requirement documents exist, then the project manager and his team will compile basic requirements using artifacts that capture the user’s and the producer’s interpretation of requirements. Artifacts from which requirements are derived include written requests for functionality, business workflow diagrams, process models, UML diagrams, and design documents.

Reporting the Progress

Once the validation is under way, the project manager is responsible for communicating the progress of testing to the project sponsor and stakeholders. The project manager’s test summary report is the result of analyzing the coverage of the requirements in concurrence with tracking functionality that meets the end user’s need. A report that captures the affiliation between requirements and user acceptance is represented in Table 27.3.

Ad hoc testing implies that the testing is unplanned, but the end of testing is rarely an arbitrary point in time. The project manager uses the aforementioned report to estimate the impact of testing on the project schedule. The impact is determined by the variance between the project’s planned end date and the projected end of the validation effort.

Even if the project end date should move to accommodate unplanned work, reality dictates that the project schedule will extend only so far. The benefit of creating the traceability/validation matrix and the test summary report is that quality of the product and the project becomes tangible measurements to guide the project sponsor’s business decisions.