PROJECT SCOPE AND OBJECTIVES

The client’s needs and desires are communicated to the project personnel through documents such as the project’s charter, objectives, scope statement, and specifications. The terms requirements specifications and scope have been used interchangeably and sometimes differently depending on the industry in which the project is being implemented. Construction, industrial, and process projects refer to the description of the deliverable as scope and specifications. Scope refers to a broader expression of the client’s objectives while the term specifications refers to the detailed expression of the client’s objectives. Systems and software development projects often do not use the term scope while referring to deliverables, but they use the term requirements to describe the performance attributes of the projects, such as processing speed, error rate, database size, and the degree of friendliness of the deliverables. Systems and software projects use the term specifications to describe the attributes of the hardware. Hardware specifications for systems and software development projects might be either predetermined by the client as part of the project objectives or developed by the project team as one of the deliverable components.

Sometimes the quality of the project deliverable is not explicitly addressed as part of the definition of project objectives. Ironically, it is this issue of quality—independent of the volume of deliverables—that determines the usability of the product and the resulting satisfaction of the stakeholders. For the purposes of this book, quality and scope are treated collectively.

Project specifications are usually included in the contract documents if the project is an external project, and particularly if the contract is awarded on a lump sum basis. However, enlightened organizations develop specifications documents even for their internal projects. The objectives or specifications of an internal project are usually spelled out in the authorization memo that empowers the project manager to implement the project. The rationale for using specifications for an internal project is that, although an internal project does not involve a contract, it should have a set of well-defined scope and objectives, so that the delivery performance can be carefully monitored. The premise is that evaluation and monitoring of internal projects will become an ad-hoc activity if there are no focused objectives and, therefore, no detailed specifications.

The scope document includes the client’s wants and needs, the distinction being that “wants” are those items that would be desirable to have although not crucial to the success of the project, while “needs” are those items that are essential to the success and usability of the project deliverable. Again, this information will probably be very sketchy during the early stages of project evolution, and will be refined, clarified, and progressively elaborated as more information becomes available to the client and the project team.

Definition of project objectives involves detailing the project scope, attributes of the deliverables, acceptance tests, desired delivery date, expected budget, and team structure. When the client directs the activities of the project, the description of tools and techniques used in implementing the project are also included in the specifications document.

To some extent, the acceptance procedures and validation tests determine the physical quality and performance tolerances of the deliverable. Therefore, care should be taken to ensure that the tests reflect all the important operational facets of the product, and that these tests do not reflect frivolous features. In the same vein, the team should make every effort to craft the deliverable to the spirit of these tests and not necessarily to the letter of the tests, which might miss some important facet of the product. Due diligence on the part of the project team will promote client satisfaction, which is considered one of the most important indicators of a project’s success.

The desired delivery date signifies the date on which the client wishes to begin reaping the benefits of the deliverables, and, therefore, the most important date for the project’s schedule. Notwithstanding, for a variety of historical and operational reasons, several intermediate milestones are usually defined as part of project plans. Intermediate milestones are not crucial to the execution of the project, but the achievement of these milestones often signifies or verifies the expected pace of the project and the desired quality of the deliverables. The establishment of intermediate milestones can be in response to the needs and desires of the client, the collective project team, individual team members, or the stakeholders.

A carefully drafted project objective document is essential to the project’s success. The objective statement is the focal point and the definitive reference source for managing the triple constraints of the project during the implementation phase. Project procedures must include instructions on how to treat the project objective statement as a living document to be enhanced continually, albeit the current version of this statement will be used as a base of performance reference through the life of the project. Project management procedures must highlight uniform and consistent guidelines for the development of, and making modifications to, the baseline project objectives and specifications.

Project planning documents must include details of processes, procedures, and methodologies that will be used for monitoring the effectiveness and efficiency of the project team in implementing the project deliverable. Since the characteristics of the team can have subtle but significant impact on the project’s success, the characteristics of the project team must be outlined in planning the physical deliverable of the project. Team attributes that must be addressed are the skill of team members, the administrative affiliation of team members, and the time spent on other duties during the project at hand. Further, project management activities dealing with team formation and team charter must be well defined and planned during the very early stages.

Particularly in external projects, the major items of equipment used to craft the project deliverable and to test its important attributes should be included. For external projects, the number of subcontractors and the overall contracting strategy must be carefully evaluated in the light of the best interests of the project and its business plan, and not just on the basis of the lowest initial cost. Contracting strategy will impact the communication pattern among project stakeholders, and will subtly affect project performance.

The fee structure of a contractor can profoundly affect the total project cost. Therefore, a careful analysis of direct costs, indirect costs, overhead, and the contractor’s profit margin is advisable, particularly if the contract is being awarded on a cost-plus basis.

A review of marginal or failed projects shows that the vast majority suffered from lack of detailed planning, or casual and ad-hoc procedures for managing the project’s changes. Conversely, the literature shows that organizations that encourage detailed planning of projects experience far better financial growth when compared to organizations that do not. Finally, data support the concept that organizations that employ competent project management professionals and consistent project management procedures tend to produce more successful projects.