After weeks of effort, Jack, a software programmer in the information systems department of a medium-sized manufacturing company, is about to show his supervisor the screens and logic for the new PC-based accounting system. The new system is an in-house project taken on at the request of the accounting department. Company accountants will now have online access to a roll-up of all monthly departmental expenses, thanks to custom-made GUI screens. It had been a difficult project but, as project manager, Jack felt it was a successful one. After all, the new system would go online just in time for the year-end accounting crunch, and the company spent only a little more on the project than intended. All in all, it's just the system the company needs. Or is it?
Unfortunately for Jack, his supervisor had recently been “burned” on another IS software project that failed to live up to the “client” department's expectations. Upon thoughtful review of Jack's efforts, the supervisor comments that it would be helpful if the individual department managers had online access to their own monthly expenses. Also, where are the budget variance reports the accounting department needs? Can variable and fixed expenses be broken down further? Pretty soon, Jack's “successful project” is transformed into a “patchwork” of add-ons and quick fixes.
While the story told here is a familiar one, it helps drive home a point that should be near and dear to the hearts of project managers everywhere: Project success is measured in terms of client satisfaction, and is accomplished by identifying and responding to client needs. Better planning and defining of project scope offers a much greater opportunity for project control and success.
Jack's mistake was that he got caught in the trap of not truly knowing his client or the client's needs. But how does a project manager zero in on a client's requirements when there is no written statement of scope and only verbal instructions and suggestions with which to develop the project?
Use the Right Tool
A simple, straightforward tool that can help a project manager determine client needs and control client expectations is the Project Definition Statement (PDS). The purpose of the PDS is to identify and control scope throughout the life of a project and also to provide the basis for a formal project plan, if warranted by the size or complexity of the project. You can use the PDS as a tool to acquire up-front client approval of the defined needs, deliverables, approach, schedule and budget. It's also a good way to obtain the buy-in of key project stakeholders.
The project manager must understand the needs and expectations of the client he or she is serving. Depending on the project, a client can be either an individual or a group. In every case, the client is the entity that requests the work and provides the budget to complete it.
Everyone involved in the project needs to understand that reaching agreement on the PDS is an iterative process. Also, changes in scope will likely be negotiated as work progresses and the PDS must reflect any alteration in budget, schedule and work parameters.
In the true spirit of the project management discipline, the PDS format is flexible and can be used on a project or subproject level. An effective PDS is brief (a maximum of three pages) and contains information that can easily be presented in concise bullet points. The PDS is meant to represent a meeting of the minds on project scope that is acknowledged by the sign-off of the client, project manager and key stakeholders.
PDS Contents
Key Project Stakeholders. The “key” stakeholders are those with the greatest influence on the project. Identify the key stakeholders, including the client or sponsoring group, by listing the organizations that are affected by or can affect the project either positively or negatively. It is best to name the specific individuals who represent the key stakeholders and have each review and approve the PDS. Also, be sure to include those interests outside your immediate organization. In the case of Jack's software program, some key stakeholders, in addition to the client accounting department, may have been his supervisor and the individual department managers.
Client Needs. Describe why the client needs assistance and for what purpose. Pinpointing your client's needs is the most important part of the PDS, since you develop the remaining elements from these defined needs. If and when the needs change, you can modify the balance of the PDS accordingly, including the budget and schedule. This will allow the impact of the change to be recognized in terms of time, cost and potential resources. Jack would have been much better off if he had identified the specific reports and versions required by the client before starting work. Then, if the accounting department requested additional reports, Jack could have revised the PDS and reflected the impact on the overall schedule and budget.
Objectives. State what will be done to satisfy client needs. The objectives should be as descriptive as possible since they will also be used to define quality parameters. The definition of quality, in terms of a relationship to need, is often stated as “conformance to requirements.” In the context of a project, if the objectives are properly tied to client needs (requirements), then the quality performance requirements have been set. If the objectives are then met, a quality product has been delivered. One objective should be a permanent statement in the PDS: To meet the established project schedule and budget while performing to client expectations. An example of an objective that could have been included in Jack's PDS would be to “develop a flexible database which allows the user to specify, view and print individual reports.” This objective is directly related to the individual reports previously specified as client needs.
Deliverables. List the work products, using as much detail as possible. By including interim as well as final products, you will have the opportunity to assess your client's expectations throughout the project. Once agreed to, the deliverables can be related to the work breakdown structure if a project plan is necessary. A final product deliverable for Jack's project would have been “database software required for report generation.” However, including an important temporary deliverable such as “one set of interim, online sample screens and related hard copy reports for client review and comment” would have given Jack the opportunity to re-verify the project scope with the client.
General Approach. Describe how the objectives will be accomplished. What steps are necessary to complete the work? Who has to be involved? How will the project be managed? This section will establish the methods you need to carry out the project. Remember, the PDS is most effective when developed in a bullet format, so keep the contents concise. Depending on the project, it may be a good idea to include management strategies (in Jack's case, using packaged software versus a custom application development) or an identification of the technology being used (old, current, or new). If the size or complexity of your project warrants a project plan, the information contained in the PDS can then be expanded in more detail.
Summary Technical Scope of Work. Develop a technical description of the work to be performed. For example, since Jack's project dealt with software programming, descriptions such as “analyze, design and code database; test and debug GUI screens” would have been listed.
Work to be Done By Others. Identify work that is not within the project scope, but is required to complete the project. This includes activities essential to the project progress and completion, such as periodic and timely client reviews of project deliverables, the issuance of permits, and training on new application software.
Schedule. List key milestones for your project. Milestones are events that do not contain effort or duration but must occur to complete the project. These events are listed in the order they must happen so that project objectives can be achieved. Every project, regardless of size, must have a milestone schedule with a minimum of two milestones: Begin Project and Complete Project. As the negotiation process with the client revises scope, the impact can be related to the client through the milestone schedule. Depending on the type and complexity of your project, a more detailed bar chart or CPM schedule can be constructed from the PDS milestones as part of the project plan. The milestones in Jack's schedule would have changed if the accounting department had reviewed the interim deliverables and then realized the need for more detailed fixed and variable expense reports.
Budget. List major budget category totals or define the terms if the project is going to be billed on a time and material basis. These budget totals are estimated based on the scope of work as determined from the client needs, the project objectives and the deliverables. Be aware that the final budget can be determined only after your client concurs with the content of the PDS. As with the milestone schedule, the effect of any changes in scope can be shown in the overall budget estimate.
No More Patchwork
Don't expect to obtain complete buy-in to the PDS on the first try. As seen in Figure 1, there are a few loops in the process of obtaining a signed PDS. Once the client and remaining key stakeholders read the “needs list” as you interpret it, and then the subsequent objectives and deliverables, a number of things may occur. New or additional ideas or needs may develop. Or perhaps you will find that your client is hesitant to sign off on the PDS. This hesitancy may be an indication that your client doesn't really have a clear knowledge of what his or her needs are. Also, the schedule and/or budget you prepared based on the client needs may not be acceptable to your client. What better time to clarify the purpose, duration and cost of a project than before valuable resources are committed or expended?
Figure 1. Reaching Agreement on the PDS is an Iterative Process
Providing clarity is exactly what the PDS is supposed to accomplish. It is a method to capture and focus on client needs and allow for change on the front end of the project and also during the project. Once the contents are acceptable to all parties and the PDS is signed by the key stakeholders, it can provide a “jump start” for a detailed project plan, or can be used as-is for planning and controlling scope for smaller, less complex projects. By using the PDS, you will be much less likely to have your efforts turn into a “patchwork” project.
Gary R. Thompson, PE, is a senior consultant with Consultants to Management in Chicago, Ill., specializing in project management consulting services. He has more than 20 years of management experience.
