Good Requirements vs. Rework – Part 3

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

As we concluded Part 2, we discussed what we all really already know – that bad requirements usually lead to cost or budget overruns, project timeframe slippages, frustrated and overworked employees, dissatisfied customers, lost profitability, and quite possibly shortened tenure with your company.

The ultimate cost of requirement errors and omissions can be huge beyond just the rework factor. Requirements drive more than just project and product quality. They drive product end-user usability. They drive the personnel skill levels for both product development and operation. They determine how the product will be used. Requirements for ease of operation, for example, lead to products that require less training before use and less time to accomplish tasks. Omitting operability requirements will result in a product that is inexpensive to purchase but costly to use. Worse, end-user operators may make more mistakes in the product’s use. Read more »

The Project Quality Assurance Role

Quality Assurance is often seen as an integral function that monitors and coordinates the quality used within the project management life cycle by evaluating the processes and procedures. Quality control, on the other hand, can be seen as a focused area (such as software testing) that compares the product to the specification or plan, with a focus of detecting and remediating errors or anomalies.

Therefore, the Quality Assurance role is a critical factor in the success of the overall project as it is focused on key quality functions throughout an engagement. In his book “Project Management Nation,” Jason Charvat identifies the following key duties for the role of quality assurance throughout the project management life cycle.

The Role of QA on the Project

The person who is responsible for QA has many duties and responsibilities. The following section lists many of the things that a QA person would be expected to do.

• Participate in the change management process to assess the risk of putting fixes into the environment during acceptance testing.
• Assist the test team in isolating the source of discrepancies between expected and actual test results. If the error is in software design, thoroughly analyze the ramifications of any design changes. Design diagrams and structure charts before proceeding with corrections to code.
• Complete preparations for acceptance testing, including the establishment of the acceptance test environment. Unlike system testing, acceptance testing always takes place in the targeted environment. It is therefore extremely important to schedule computer resources well in advance.
• Check the simulated data to ensure that required test data have been produced.
• Obtain expected results from the acceptance test plan and review them for completeness.
• Calculate any missing expected results.
• Be certain that the introduction of new load modules is according to test configuration management procedures. When a new, corrected load module is received, first rerun tests that previously failed because of software errors. If these tests succeed, proceed with regression testing.
• Analyze and report test results. Evaluate test results as soon as possible after execution. Wherever possible, use automated tools in the analysis process. Record analysis procedures and keep all relevant materials. Remember that records and reports should give complete accounts of the procedures followed. If a test cannot be evaluated, note the fact and report the reasons for it.
• Compare all test results with expected results and note that all defects are documented, regardless of how minor they appear or whether they will be corrected.

Another Take on the Statement of Work Document

In an attempt to continue to provide PM Tips readers with various templates and descriptions of key documents that are normally part of the project management process, I’d like to present this article with additional information on the always-critical Statement of Work (SOW) document. I’ve already provided much of my viewpoints on this extremely important piece of project information and it’s role in project inception and kickoff in the article “The Statement of Work.”

Here will present more information on this document as described by Carl Pritchard in his book “The Project Management Communications Toolkit.” Mr. Pritchard provides a discussion of the purpose and uses – from his point of view – of the SOW as well as a sample layout of the document.

Since many of the PM readers are looking for help in putting together good templates and understanding how some of these types of documents are laid out and used (especially for the newer PMs or individuals considering a PM career) I feel it is critical to provide our readers with as many examples of these tools as possible.

The Statement of Work

Purpose

The statement of work serves as a guideline of the agreements on performance between a purchasing organization and a seller of goods and/or services. It is frequently an attachment to a contract or a memorandum of understanding between two organizations. The SOW affirms how the purchasing organization wants the work to be performed and the context of that performance, including any specific management practices or protocols the contractor must follow.

Application

The SOW is normally used as an attachment to the contract or agreement and is one of the very earliest documents developed to clarify communications between organizations. As a component of the contract, it is frequently used to settle disputes over what work should or should not be included in a project. It establishes expectations for a variety of issues in the contract relationship, including (but not limited to) the following:

• Overall project scope
• Primary tasks and/or deliverables;
• Costs
• Reviews and reports
• Testing
• Support
• Performance requirements
• Period of performance
• Payments and invoicing

Because the SOW is normally an attachment to the contract or agreement, it is a primary reference document for the project manager throughout the life of the project.

Content

Because the SOW is most often developed by the organization requesting the project product or service, it normally reflects a functional, rather than technical, perspective. Although the customer may have technical expertise, the work they will identify in the SOW is frequently performance oriented or performance based.

An outline for a SOW might look like the following:

1.0 Project Scope and Objectives

This is often a rewrite (or a copy) of the scope statement for the project, providing a general, overall perspective on what the project is intended to accomplish.

2.0 Description of Deliverables/Services

If the project can be defined into the key components or elements of the deliverable or service, they should be defined in sufficient detail to guide the project organization on the buyer’s desired approach. This may include physical deliverables or reports, testing, and support components of the project. The description of deliverables and services is normally the single longest section of the statement of work.

3.0 Costs

In an internal or cost-reimbursement contract situation, a table for the anticipated costs by deliverable, month, quarter, or fiscal year may be provided. This would not be included in a firm fixed-price contract. This may include personnel and materials usage and rates, particularly in a time-and-materials contract.

4.0 Reviews and Reports

This is a detailed description of the regular reporting requirements associated with the project and the level of depth anticipated for those reports. It may include not only timing for the reports, but also the forms and formats required.

5.0 Testing

The testing component details what types of tests are considered mandatory and how and when they must be applied. This may include both formative (in-process) and summative (upon completion) evaluations.

6.0 Support

This component may describe support both during and immediately following the project. It should include some details about response times, type(s) of support (telephone, on site, e-mail, chat, and so forth), and what general areas may or may not be covered as a component of the support agreement.

7.0 Performance Requirements

If any specific organizational protocols must be followed, they should be included in the SOW. This might include security, team behavior, configuration management, risk management, and other managerial requirements of the purchasing organization.

8.0 Period of Performance

This should be a date-certain window of performance for the contract, from [date] to [date], with no work to be performed outside that window without a contract amendment.

9.0 Payment and Invoicing

This should provide specific guidance on any provisions for interim payment and identify any specific individuals responsible for ensuring payment in a timely fashion. It may also cross-reference any protocols for invoice submission.

Approaches

In some contracting organizations, the SOW is used as a place to incorporate any special contractual clauses that may not normally be embedded in the contract. If the organization does not normally have a “furnished property” clause or other clause that may directly affect performance, such clauses are sometimes included here. In other organizations, clauses that are nestled deep within the contract, but which are often overlooked, are repeated here for emphasis. The purpose of the SOW is to clarify what work is to be performed by the project organization. If those clauses have direct influence over how the work will be performed, their inclusion here may be appropriate.

Some organizations use SOWs even for internal projects. In such environments, the SOW is used to emphasize the contractual nature of the relationship among the functional managers who may be responsible for the effort.

Considerations

Project managers frequently use the SOW as virtually the sole arbiter of how they will move forward on the project. In some organizations, the SOW is the only customer-authored documentation the project manager ever sees. The project managers may not have access to the full contract, but they almost always have access to the statement of work. As the guiding force for project performance, regardless of legal consequence, the SOW is likely to be seen by the project organization as the final determinant of what the customer wants.

Phases of a Construction Project Life Cycle – Part 4

In Part 4 we will examine the final two construction project phases as described by F. Lawrence Bennett in his book “The Management of Construction – A Project Lifecycle Approach.” In this final installment, we review the project operations and project closeout and termination phases.

Project operations phase

In presenting the contractor’s activities on the construction site, we will suggest, perhaps too simply, that the responsibilities involve three basic areas: monitoring and control, resource management and documentation and communication. Five aspects of monitoring and controlling the work are important. Actual schedule progress must be compared against the project program to determine whether the project is on schedule; if it is not, actions must be undertaken to try to bring the program back into conformance. Likewise, the cost status must be checked to establish how actual performance compares with the budget. An equally important part of monitoring and control is quality management, to assure that the work complies with the technical requirements set forth in the contract documents. In addition, the contractor has an important role to play in managing the work safely and in a way that minimizes adverse environmental impacts.

In managing the project’s resources, the contractor will, first, be concerned with assigning and supervising personnel and assuring that the labor effort is sufficiently productive to meet schedule, cost and quality goals. In addition, materials and plant must be managed so that these same goals are met. Because construction projects require large amounts of paperwork, a special effort is required to manage this documentation effectively. Examples include the various special drawings and samples that must be submitted to the owner or design professional for approval prior to installation, the frequent need to respond to requests for changes in the project after the on-site work has begun and the all-important process for periodically assessing the value of work completed and requesting payment for this work. Various on-line and other electronic means are available to assist contractors with document management and project communications.

Project closeout and termination phase

Finally, as the project nears completion, a number of special activities must take place before the contractor’s responsibilities can be considered complete. There are the various testing and startup tasks, the final cleanup, various inspections and remedial work that may result from them and the process of closing the construction office and terminating the staff’s employment. In addition, a myriad of special paperwork is required, including approvals and certifications that allow the contractor to receive final payment, a set of as-built drawings that include all changes made to the original design, operating manuals, warranties and a final report. The contractor will also be responsible for transferring and archiving project records and will conduct some sort of project critique and evaluation; operator training may also be part of the contractor’s contractual responsibilities.

Phases of a Construction Project Life Cycle – Part 3

In Part 3 we’ll look at the next two phases of a construction project as described in F. Lawrence Bennett’s book entitled “The Management of Construction – A Project Lifecycle Approach.” In this article, we’ll allow Mr. Bennett to take us through the contractor selection and project mobilization phases.

Contractor selection phase

In anticipation of selecting a contractor, the owner must decide whether an open invitation will be issued to all possible vendors or whether only certain contractors will be invited to submit offers and whether any sort of pre-qualification process will be invoked to limit the number of tenders. On the other side, contractors will have to consider a number of factors in deciding whether they will make the effort to assemble a proposal for a particular project. If a contractor finds the prospective project attractive, two major tasks will be required. First, a series of planning steps will be carried out, including studies of various methods and equipment that would be employed and the development of a preliminary project program setting forth an approximate time schedule for each major activity. Second, a priced proposal will be prepared, including the direct costs of labor, materials, plant and subcontractors, various overhead charges and a sufficient added amount for profit. The last step in this phase is the submittal, opening and evaluation of tenders, the selection of the successful contractor and the finalization of the construction contract.

Project mobilization phase

After the contractor is selected, a number of activities must be completed before installation work can begin at the project site. Various bonds, licenses and insurances must be secured. A detailed program for the construction activities must be prepared. The cost estimate must be converted to a project budget and the system for tracking actual project costs must be established. The worksite must be organized, with provisions for temporary buildings and services, access and delivery, storage areas and site security. The process of obtaining materials and equipment to be incorporated into the project must be initiated and arrangements for labor, the other essential resource, must be organized. With the completion of this phase, it is finally time to begin the actual field construction.

Next

We will conclude this series on Construction Project Management Phases in the next article – Part 4. In that final installment, we’ll review of Mr. Bennett’s description of the project operations and project closeout and termination phases. If any of you have experience with construction project management and wish to comment, I would definitely like to hear your feedback as this is not an area where I have any prior experience.