Chapter 23

The Project Management Framework

The Project Framework

The Project Framework is a simple and useful way to unite quality processes with project phases, and synchronize project quality management with the system, or software, development approach.

The Project Framework, described in the following sections, uses the Project Management Institute’s Process Groups to:

  1. ■ Embed the quality processes into the project phases.

  2. ■ Align quality planning, assurance, and control activities with the output of a system or software (or system) development life cycle (SDLC).

The phases of the Project Framework require the project manager and the test manager to cooperate so that the end result of the project is a quality product.

For more information on the Project Management Institute (PMI), go to www.PMI.org.

Product Quality and Project Quality

Project managers are ultimately responsible for product quality and project quality. The difference between product quality and project quality, drawn from The Project Management Institute’s Project Management Body of Knowledge® (PMBOK), is abbreviated here:

Images

Figure 23.1   Project Framework.

  1. Product quality is meeting explicit criteria for conformance to requirements and fitness for use.

  2. Project quality is delivering the required product, or service, within the agreed project scope and meeting the approved schedule without exceeding the project budget.

Together, product quality and project quality comprise project quality management.

Components of the Project Framework

The Project Framework, illustrated in Figure 23.1, treats the Project Management Institute’s five Project Management Process Groups as overarching project phases. The resulting alignment implies flexibility and assumes that overlapping activities will take place across the SDLC phases.

The Project Framework and Continuous Quality Improvement

The project manager and the test manager share responsibility for continuous quality improvement. They use the Project Framework to infuse continuous quality improvement into each SDLC phase.

The Project Framework works well with Deming’s modified Plan–Do–Check–Act cycle shown in Figure 23.2.

Examples of using the PDCA cycle are nearly unlimited. Here are several examples:

Plan: Clearly define the project and product scope; understand the conditions, policies, and methods required to achieve the project objectives.

Images

Figure 23.2   The Plan–Do–Check–Act cycle.

Do: Create the conditions and procedures to complete the work according to the approved project scope.

Impart training as needed so that the required skills are available when needed.

Ensure that project team members understand both the project objectives and their project work.

Check: Determine if the project deliverables are completed according to plan and whether the results are as expected.

Act: Respond to variances by adjusting the quality processes to prevent variance from project and product quality. Actions include the following:

  1. –   Validating changes to requirements and scope.

  2. –   Determining if project deliverables meet quality assurance measurements.

  3. –   Ensuring that project documents (such as the project schedule and budget) are updated.

  4. –   Assessing the impact of changes in conditions to detect and correct variances from project quality standards.

  5. –   Performing root cause analysis for any major variance and adjusting the process to prevent recurrence.

The Project Framework Phases

Initiation Phase

Project initiation signals the sponsor’s commitment to fund the project. Initiation activities include producing a project charter that summarizes the high-level scope of the product and the project, as well as authorizing the project manager to assume project leadership. Early requirements definitions, project team mobilization, and stakeholder analysis are initiation activities that set the foundation for the planning phase.

The quality definition for the project begins in the Initiation phase, using progressive elaboration to develop the detailed expectations for product acceptance by the customer. Writing a preliminary quality statement, or initial quality policy, during the initiation phase helps jump-start the test planning by establishing a context for customer acceptance.

Planning Phase

Planning the quality management approach for the project is accomplished in parallel with developing the scope and requirements for the product and the project. The project assumptions, dependencies, and risks are inputs to the test strategy. Other inputs include application and architecture models as well as integration requirements.

Development activities during the planning phase, such as conducting a proof of concept or demonstrating a prototype, provide opportunities to assess whether the project requires changes and additions to existing quality policies, test environments, test tools, and test methodologies.

The fundamental quality outputs from the planning phase are the final quality policy (quality standards) for the project and the test strategy derived from the functional and nonfunctional requirements.

Planning for quality assurance and quality control is incomplete until resources are assigned to the quality tasks in the work breakdown structure (project schedule). Planning the QA tests and user acceptance tests should be coordinated to avoid unnecessary duplication of effort.

Executing, Monitoring, and Controlling Phases

This phase incorporates the project execution activities with the monitoring and controlling activities because the processes are mutually dependent. Project work is inspected to detect variance from, or confirm compliance to, project requirements. Project scope is validated, too, during this phase, because a well-scoped test plan detects unauthorized work.

The multitiered testing activities in this phase are distributed across SDLC phases. The work is done by the application development organization, the infrastructure organization, and the test organization if one exists. An example of the work allocation is as follows:

Detailed Design:

  1. –   Validating that the functional and nonfunctional requirements are complete.

  2. –   Validating the test approach against the final designs for application and system interfaces.

  3. –   Validating the test approach against specifications for system performance.

  4. –   Validating that the customer, the application developers, and the infrastructure team accept the quality standards.

  5. –   Validating that the development and testing environments meet specifications prior to the build and test activities.

Build and Test:

  1. –   Conducting code and unit testing for interfaces (and test data conversions if applicable).

  2. –   Finalizing the test approach for application reports, integration, and performance.

  3. –   Finalizing the test approach for hardware integration and performance.

  4. –   Creating the Test Plan for the functional and nonfunctional requirements.

  5. –   Creating and validating the test cases against functional and nonfunctional requirements.

  6. –   Creating the User Acceptance Test Plan and test cases.

Customer Acceptance Test and Go-Live Preparation:

  1. –   Performing application reports, integration, and performance testing as required to meet the quality standards.

  2. –   Performing hardware integration and performance testing as required to meet the design standards.

  3. –   Performing user acceptance testing as required to meet the definition of fitness for use.

  4. –   Testing reports completed and signed off.

Implement Phase

The last phase in the Project Framework is characterized by user acceptance sign-off and the cutover to production (successful go-live).

The project manager has many administrative tasks to accomplish before signaling that the project is officially closed. A prerequisite to project closure is ensuring that all defects are resolved per the predetermined project quality thresholds, and that the defect log is closed. Even then, the project is not complete until all of the test artifacts (including scripts) are archived for reference by other projects.

Scoping the Project to Ensure Product Quality

The PMI states that project scope verification is concerned with the acceptance of the work results, whereas quality control is concerned with the correctness of the work results. Because scope verification begins in the earliest stage of project definition, project managers who exploit the interdependencies between quality control and scope verification in the initiation phase avoid project overhead in subsequent project phases.

Product Scope and Project Scope

Defining product scope is the precursor to defining the project scope. The association is straightforward: 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.

As the product’s features and functionality take the form of requirements, the project team estimates the work (tasks) that is necessary to meet each requirement.

Taking the proactive approach to quality management, the project manager extends the work estimate to include the probable resources and projected time to validate the requirements.

The benefit of estimating the validation activities in the initiation phase is that the customer, the project manager, and the test manager negotiate the acceptable level of project quality that the project must deliver. During the negotiation, the project manager and the test manager learn the general acceptance criteria for the products’ features and functionality, and formulate the boundaries of project quality. The formal endorsement of the project scope usually takes the form of a Project Charter. The detailed description of the project scope is developed in the Scope Statement.

The Project Charter

The Project Charter is a living business document that officially recognizes the funding of a project. The charter presents the project sponsor and the customer with a brief summary of the product scope and the project scope, and authorizes the project manager to mobilize the project team. The charter is updated when the project scope changes.

The charter categorizes the project resources and assigns high-level roles and responsibilities to the resources. The charter also provides the project stakeholders with an aggregate list of future deliverables that includes the test plan, test specification, and test results.

The Project Charter should be simple and nontechnical. Project charters usually include these sections:

  1. ■ Scope

    1. –   Product scope

    2. –   Project scope

  2. ■ Stakeholders

  3. ■ Project resources

  4. ■ Business impact

  5. ■ Business objectives

  6. ■ Project justification

  7. ■ Project benefits

  8. ■ High-level deliverables

  9. ■ Project approach

The Scope Statement

The Scope Statement is a living project document that the project manager updates as the project team develops detailed requirements. In the initiation phase, the Scope Statement contains early estimates of the project resources and costs.

Even in its earliest stage, the Scope Statement is vital to project quality management because it limits the project scope to the work that must be done to deliver the product. The work to deliver the product encompasses quality assurance and quality control.

Scope Statement formats differ among organizations and departments, but scope statements usually contain the following sections:

  1. ■ Executive summary

  2. ■ Background

  3. ■ Business objectives

  4. ■ Project costs

  5. ■ Scope

    1. –   Product scope

    2. –   Project scope

    3. –   Out of scope

  6. ■ Success criteria

  7. ■ Dependencies

  8. ■ Assumptions

  9. ■ Constraints

  10. ■ Known risks

  11. ■ Estimated time frame, including the initial work breakdown structure

  12. ■ Scope management approach

The Role of the Project Manager in Quality Management

Project managers are responsible for coordinating and communicating the impact of authorized scope changes across the spectrum of project stakeholders. Project managers use the Scope Statement to detect deviation from the project scope. Scope deviations are not negative if authorized, but the impact of any unauthorized change must be analyzed and the root cause examined.

Project scope definition and quality management are intertwined such that any change in product scope affects the project scope. Changes to product scope directly influence the allocation of project resources to quality assurance and quality control because the project scope includes testing the product.

The earlier project managers define product scope and how to manage product scope change, the more effective they will be at managing the resources, sequence, cost, and project duration.

In summary, by defining and managing the project scope, the project manager is instrumental in helping the test manager verify that the requirements are defined and testable; that scope changes are communicated; and ultimately, that the product is fit for use.

The Role of the Test Manager in Quality Management

The test manager is responsible for ensuring that a product meets an acceptable level of compliance with functional and nonfunctional requirements. The project quality management that is required to ensure the level of compliance with requirements is rarely done without organizing the QA and QC activities into a series of phases that either blends with, or complements, the software (system) development life cycle.

The following task descriptions are not necessarily sequential and will overlap. In some cases, the work is accomplished in parallel activities.

Analyze the Requirements

Early in the Initiation phase of the Project Framework, the business users begin formulating their requirements by describing how they want their business processes to work in the future compared to the current processes.

Many organizations rely on business analysts to turn the business users’ descriptions into business requirements that summarize the users’ expectations regarding new features and functionality. Experienced business users are prone to making assumptions about system conditions because they typically focus on the business processes and not on the system behavior. For this reason, business analysts may not detect that some expectations of business users are based on assumptions about system conditions. If an implicit condition is not tested, then the testing is not complete and will not satisfy the end-user requirements.

The test manager should review the business requirements with the business users to identify the implied system conditions. The reviews are best done while writing and reviewing the test strategy and the test scenarios during the Planning phase.

Perform a Gap Analysis

The test manager should begin a preliminary gap analysis early in the Planning phase to identify the disparities between the requirement and specification documents.

If possible, a comprehensive gap analysis spans the Planning and Executing phases. The analysis includes baseline documents such as use cases and system design documents. Identifying and solving the gaps are essential in giving the business confidence in their final requirements.

The gaps between the requirement documents and the functional or design specifications become obvious after the product is released into the production environment (post go-live) and a business scenario does not produce the expected result. The gap analysis reduces the rework required to fix problems traced to conflicts between requirement and technical documents.

Avoid Duplication and Repetition

During the Planning phase, the proactive test manager ensures that the test cases are comprehensive, and at the same time, that the test cases avoid repetitive coverage. Unless addressed during planning, there is a risk that executing the same class of test cases for different conditions will increase the duration of test cycles by slowing the testers’ advance to untested functionality.

Equivalence class partitioning, described in Appendix G, is a valuable technique for avoiding repetitive test case coverage. The technique classifies business functions on the basis of input conditions that cause the same kind of processing and output. The result of equivalence class partitioning is a concise set of test cases that increase the testers’ ability to locate defects.

Please note that redundant testing caused by poor test planning and test case design is not the same as repeating test cases for the purpose of verifying the resolution of anomalies concentrated in a specific area of code.

Define the Test Data

Defining the test data is a vital part of the test planning activity in the Planning phase. The test manager is responsible for ensuring that the data required for executing the test cases is available in the test environment and that all of the test cases are executed with the correct data sets.

The data guidelines should be defined during test planning with the help of the business analyst and developers. The location of data sets for the test cycle should be determined in the test plan, as well as the method and time required to refresh or restore the data sets.

Validate the Test Environment

The test manager defines the test environment in the test strategy document. The definition must be complete and identify all of the interfaces that are required to execute the test cases. In addition, the test manager must write a statement that summarizes the risks to the test effort when the interfaces that affect test execution are outside the control of the test engineers.

After defining the test environment, the test manager prepares a checklist to verify that the test environments are functioning as expected. The checklists are also useful for restoring test environments at the end of each test cycle. Normally, the initial test environment is validated during the detailed design phase of the SDLC.

Analyze the Test Results

During test execution, the test manager is responsible for analyzing the test results to identify the test scenarios that require correction or clarification.

For example, a specification document defines the ranges for start dates, durations, and end dates. An analysis of test results shows that the results of range testing are correct; did testing the date ranges validate that the start date cannot be greater than the end date?

Deliver the Quality

The primary responsibility of the test manager is to deliver a product to the business with so few variances from requirements that it meets the business user’s needs. The test effort was adequate if the customer accepted the product. The test effort was successful if the customer accepted the product and testing concluded on time and within budget.

Advice for the Test Manager

Request Help from Others

During test case development, the test manager and test team should take the initiative to ask the business users and developers to help validate the team’s expected test results. The benefits of collaboration are multiple: The developers understand the tester’s verification methods, the testers understand the end-user definition of functionality, and the test manager understands the business view of the development process.

Communicate Issues as They Arise

Test management requires effective communication between test managers, testers, developers, and the project stakeholders. Issues that surface during test execution must be conveyed to the stakeholders as soon as possible. Keeping stakeholders informed regarding status and progress helps focus decision makers on issues that impact quality.

Effective communications require the test manager to understand the unique need of the stakeholders and the types of information that they need to make well-informed decisions. For example, the percentage of complete test cases will mean different things to different stakeholders. The test manager is responsible for learning which type of stakeholder will use that statistic for decision making and which stakeholder will ignore it because is has no value to him or her.

Always Update Your Business Knowledge

Software development supports the business enterprise. To develop deeper testing capabilities, test managers and their teams must extend their business knowledge. If they do not, then they will not be able to convince either the developers or the business owners about the importance of the system defects that the testing effort uncovered.

Learn the New Testing Technologies and Tools

The software industry is a fast-changing industry. Test managers’ skills will be outdated very quickly unless they learn how to apply next-generation software testing technology, tools, and methodologies. A result of outdated skills is the inability to take advantage of the cost savings from high-efficiency tools and methods. Test managers who are resistant to change will not be in a position to support the business as expectations for quality increase but budgets and schedules decrease.

Improve the Process

The test manager should take responsibility for continuous process improvement. One way to do this is by taking advantage of the lessons-learned activity for the overall project. New concepts for enhancing testing efficiency and product quality are discovered as the project team reviews the results of the end-to-end processes used to deliver the product.

Reviewing production support issues will give the test manager a great deal of useful information. Issues that are discovered after the product is released into the production environment are indications that test methodology and planning might have gaps that should be addressed.

Create a Knowledge Base

The expertise gathered in various projects should be documented so that the knowledge is reused in other projects. The test manager should document the positive and negative factors that were encountered in each test project execution and organize the information so that members of other project teams can reuse the information.

The Benefits of the Quality Project Management and the Project Framework

The benefits of integrating the Quality Project Management processes with the Project Framework processes are:

Initiation phase

  1. ■ Project scope validation begins and is input for the test plan.

  2. ■ The context for customer acceptance is established.

  3. ■ The project manager and the test manager negotiate the acceptable level of project quality.

Planning phase

  1. ■ The product requirements for the product are developed in parallel with the quality management approach.

  2. ■ The project assumptions, dependencies, and risks are input into the test strategy.

  3. ■ Preliminary resources are assigned to quality tasks (in project schedule).

  4. ■ QA tests and user acceptance tests are planned to avoid unnecessary duplication of effort.

  5. ■ Project scope is validated using the test plan to detect any unneeded work.

Executing, Monitoring, and Controlling phases

  1. ■ Unauthorized scope changes are detected and the root cause examined.

  2. ■ The development and testing environments meet specifications prior to the build and test activities.

  3. ■ Test approaches are finalized for software and hardware.

  4. ■ Multi-tiered testing activities are distributed across SDLC phases.

  5. ■ Emphasis on continual improvement enhances product and project performance.

Closing phase

  1. ■ Quality defects are resolved.

  2. ■ The customer accepts that the product is fit for use.

  3. ■ All testing artifacts are archived for future reference and reuse.

In order to realize the benefits of integrating the Quality Project Management processes with the Project Framework, the test manager and project manager should integrate their respective roles and responsibilities as well as their methodologies. If they do, then they will greatly increase the probably of meeting the customer’s expectation for product quality and the business goal of project quality.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset