> Project Q/A methods need to be tailored to each project. Smaller projects need less Q/A than larger ones, and large projects need these techniques in different degrees. Project Q/A is an overhead cost, and can slow projects unnecessarily if not applied with care.

> The main tool for managing project risk is communication to set expectations, provide status, and give alerts. The techniques below may appear to require a lot of unnecessary documentation. The purpose of this documentation is not simply to keep records, but to support communication.  And without the documentation, the communication will be much more of a challenge. Think of the documentation as fire-proofing. Unless you like fighting fires, this documentation can be your best friend.

The Statement of Work (SOW)

The Statement of Work, or SOW, is the "doing" part of the contract between the business and development manager.  SOW's are common in external contracts.  They are also important for internal work, because of their value in project Q/A and communication.

The SOW should be a "living document" that is referenced and modified throughout the project.  A high-level SOW can be used for sign-off on starting the project, with the details added in the project's first stage.  Sections of the SOW may repeat information from different points of view, to ensure clear understanding.  The contents of a typical statement of work will include some or all of the following.

Background/Overview:  A brief story of how and why the project came into being, and the general relationships among the players.

Objectives:  The outcome and results the project is trying to achieve.  This can be divided into two sub-sections: A) Business objectives - the goals of the overall business initiative that the project is part of; and B) Project objectives - the specific goals that the project has in supporting the business objectives.

Scope:  The processes, organizations and systems that will be affected by the project. This should also describe what is out of scope, that is, what will not be worked on.  Scope is critical in focusing effort, managing expectations, and negotiating changes to project activities and costs.

Activities:  The major activities of the project plan, in a table format, with columns for major milestone dates and key work products.  While these milestone dates and work products may be modified as the project moves forward, it is very important to record them up front, to clearly set expectations. This section should include a pointer to an appendix with the detailed project plan, which should be seen as an extension of the SOW.

Deliverables:  The concrete items or conditions of value that the project will produce. These should be described as precisely as possible ("Final report will be approximately 20 to 30 pages"; "New average repair time will be 4 to 6 days.") Again, these may be changed due to what is discovered or modified requirements during the course of the project.

Project Management:  Project management responsibilities, techniques that will be used, and schedules and attendees for review meetings.

Roles and Responsibilities:  A table, with an organization chart, listing the project players and their specific duties in the project.

Assumptions & Constraints:  Specific details of what is expected of each party, and known limitations that must be worked with. This section is often used to spell out key details that don't appear in other sections.

Risks:  A table describing A) events that might occur that would harm project progress, B) the harmful effects that would arise from these events, C) a "High/Medium/Low" rating of the severity of the harmful effects, D) "High/Medium/Low" ratings on the probability that the harmful events will occur, and E) actions can be taken to avoid the events and to mitigate their effects.  It is important to get different stakeholder groups to provide input to this section.

Change Management:  Procedures for modifying the SOW in case of changes in scope, activities, deliverables and so on.

Costs:  Estimated or contracted costs, and how costs will be calculated.

Acceptance:  Procedures for how the business manager will sign-off on the deliverables, or request that they be modified, at the end of the project.

Summary of the Statement of Work (SOW)

Again, this may seem like a lot of paperwork. However, each of these sections can be filled out in a very informal way. Think of the Statement of Work first as a communications checklist, and add detail to it as needed to make that communication effective.

Key Project Management Techniques for Quality Assurance

Certain project management techniques have particular importance for project quality assurance, particularly for large projects or multi-project programs.  These include the following:

Project Plan Maintenance and Review:  On-going plan maintenance with actual progress and resource use, and adjustments for new circumstances; in other words, project management basics.

Issues Log:  A table used to record, categorize, prioritize, and track resolution for problems that might affect progress and success.  The issues log is a major vehicle for keeping small fires from turning into big ones.

Project Timekeeping and Status Reports:  Weekly individual time and status reports, rolled up to overall project reports, help keep progress, costs and issues visible.

Project Review Meetings:  In weekly meetings, the business and development managers should review the issues log, the project plan, and certain sections of the SOW, including roles and responsibilities, assumptions and constraints, and risks.

Architecture Management:  The project plan should have an activity that monitors the "architectures" of the project, which describe at large scale how processes, organizations, software, data and equipment fit together to produce the desired result.

Communications Management:  Stakeholders need to be kept up to date on the project through regular email newsletters or other vehicles.  Managing expectations in this way can avoid surprises, overcome resistance, and ease implementation.

Benefits Management:  Executive management should get regular reports the forecasted benefits of the project, highlighting any changes in expectations.

Organization Change Management:  Project success depends in large part on how the project will impact jobs, reporting relationships and other organization factors. Organization change activities may be included in the project or operated in parallel and included in project reviews.

Vendor, HR, and Finance Management:  Vendor relationships, staff availability and performance, and overall project costs and funding should be regularly monitored, reviewed and reported on.

Again, depending on the size and importance of the project, the implementation of these techniques can range from simple lists to full time staff roles.

Summary

Business/technology development projects promise a great deal of reward, and accordingly carry a great deal of risk.  Successful project delivery requires specialized project management skills.  The business manager who is responsible for the project results may not have these skills, but still needs a way to influence project quality.  A checklist of key project management activities and techniques can help business
and development managers communicate and work together toward project success.

back to top