MANAGING PROFESSIONAL SERVICES PROJECTS:PROJECT DEFINITION

2. PHASE I: PROJECT DEFINITION

Project Definition Purpose

Project definition is arguably the most important phase of a project. It entails defining the objectives, scope, and deliverables of the project; selecting the most appropriate approach; developing high-level estimates of time and cost; defining the project-management process; and identifying and addressing potential problems and risks. The project-definition phase ensures that the stakeholders and project team have a common understanding of the project’s purpose, objectives, and benefits. Many failed projects have been linked to inadequate development of a project definition.

A sound project definition enables the organization to begin the project in a systematic manner; it sets the tone and establishes the project’s direction, opens channels of communication, forms a basis for client and stakeholder trust, and tends to bring to the surface any client concerns or chal- lenges. The risks of not having a sound project definition include false starts, inadequate communi- cation, confusion among the participants, and failure to meet the client’s and other stakeholders’ expectations.

The Project Definition Team

A core team is established to prepare the project definition (and usually the subsequent project plan). The core team may include the project manager, functional personnel, technical personnel, and pos- sibly other professionals drawn from outside the firm.

Expectations need to be communicated clearly to the core team members, including their ac- countability for the project deliverables and outcomes as well as their required time commitment throughout the life of the project. The time commitment, which might be full time during the de- velopment of the project definition and the project plan, should also be explained to the core team members’ supervisors (performance managers).

The specific technical expertise required of the core team members is dependent upon the nature of the project. However, at a minimum, they should have a sufficient top-level understanding of the technical issues to be able to define and plan the project effectively as well as to manage the resources that may be recruited to work on the project.

Project Definition Components

A project definition should contain at least the following components:

• Project objectives (outcomes)

• Scope

• Deliverables (outputs)

• Approach

• Resource and infrastructure requirements

• High-level time and cost estimates

• Project risks

Each of these components is described below. Examples are provided based on a typical project to identify, evaluate, and select a manufacturing business planning and control software system. Software evaluation and selection assistance is a fairly common professional service provided by consulting

firms to clients (in this example, ABC Manufacturing, Inc.). This example project will be carried throughout this chapter to illustrate the various aspects of professional services project management.

Project Objectives (Outcomes)

Objectives are the destination, target, or aim of the project. They are needed to clarify the client’s and other stakeholder’s expectations. They also help to:

• Establish a common vision

• Guide the team during project plan development and execution

• Keep the team focused as the project progresses

• Provide a basis for communications during the project

• Establish a means for assessing success at the completion of the project

Good objectives state what will be achieved and / or the results sought, not how the team will get there. They are specific, unambiguous, and measurable, containing a time frame for the intended achievements. Examples of outcome-oriented objectives include: select a business planning and con- trol software system in six months; implement the selected business planning and control software system in 18 months; increase product throughput by 50% in two years; decrease inventory investment by 75% by year end.

Scope

The statement of scope sets the boundaries of the project, in that it defines the confines, the reach, and / or the extent of the areas to be covered. It clarifies what will be included in the project and, if necessary, states specifically what will not be included.

Scope may be defined in terms such as geographical coverage, range of deliverables, quality level, and time period. The statement of scope must be clear, concise, and complete, as it will serve as the basis for determining if and when out-of-scope work is being conducted during project execution. In the professional services field, performance of unauthorized, out-of-scope work on a project usually will result in a budget overrun, unrecovered fees and expenses from the client, and unsatisfactory project financial results. Potential out-of-scope work should be identified before it is performed and negotiated as additional work, along with its attendant cost and schedule requirements.

An example of a scope statement is: ‘‘Assist ABC Company in selecting an appropriate business planning and control software and hardware system and implementing the selected system. The assistance will include defining business system requirements, evaluating system alternatives, making a selection that will support manufacturing and accounting functions, and facilitating the implemen- tation of the selected system.’’

Deliverables (Outputs)

A deliverable is anything produced on a project that supports achievement of the project objectives. It is any measurable, tangible, verifiable outcome, result, or item that is produced to complete a task, activity, or project. The term is sometimes used in a more narrow context when it refers to an external deliverable (handed over to a stakeholder or client and subject to approval).

Examples of deliverables are system requirements definition document; request for proposal (RFP) document; systems-evaluation criteria; software and hardware configuration design; system- implementation project plan; and facilitation assistance during the system-implementation process.

Project Approach

The project approach defines the general course of action that will be taken to accomplish the project objectives. For example, the project approach may be defined in such terms as the methodology to be used, the timing / phases of the project, and / or the types of technology and human resources to be applied. The approach section of the project definition explains, in general, how the project will be carried out.

An example of an approach statement for developing a system requirements definition document is: ‘‘We will conduct interviews with personnel in each functional area to develop and define the system requirements, based on a system requirements profile. We will provide advice in the definition of critical system requirements, such as system performance (timing, volumes, and the like). This phase will culminate with the development of a system requirements definition document.’’

Resource and Infrastructure Requirements

Resource and infrastructure requirements for professional service projects typically fall into any of three categories: human resources, facilities and equipment, and information technology (including knowledge bases). Human resource requirements, often the major cost of a project, should be defined

in terms of the roles, responsibilities, and skills that are needed for the project to be successful. The roles and responsibilities then are translated into a depiction and / or description of the planned or- ganization structure for the project.

Arguably the most important role in the project is that of the project sponsor, the person who authorizes or ‘‘legitimizes’’ the project (often referred to simply as ‘‘the client’’). If the sponsor is not committed to the project, the chances of successful completion are reduced. Sponsorship often can be extended by the formation of a project steering committee, which, if constructed properly, can be particularly useful in clearing barriers that are likely to come up during project execution.

An example of a resource and infrastructure requirements statement might be: ‘‘We will require designation of a project team leader to assist in scheduling interviews; arranging for the collection of information, reports, and documentation; and assisting in the coordination of administrative sup- port. Knowledge of existing systems is also important to provide valuable background information. In addition, office space with a telephone and computer access to the internet is required.’’

High-Level Time / Cost Estimates

The purpose of high-level time / cost estimates is to gauge and validate project size. A high-level estimate sets out resource and staffing levels by project phase or activity and elapsed time by activity.

High-level time / cost estimates are top-down estimates made while developing the project defi- nition. A high-level estimate can be developed by reviewing and drawing upon estimates from pre- vious similar projects and any estimates developed in project definition work sessions. Assumptions, initial estimates, and associated calculations should be documented. During project planning (Phase II), detail calculations are summed and compared to the high-level figures as a way of validating the estimates.

An example of a high-level time / cost estimate is: ‘‘It is estimated that it will take 14 weeks to reach the point at which software has been selected. Once the hardware and software are installed, it will take approximately 10 months to implement the system. Based on the scope of work and the approach, it is estimated that the project will cost $350,000 to $375,000.’’

Project Risks

A project risk is any factor that challenges the project team’s ability to manage the budget, resources, time, and quality of the project deliverables and acceptance of the deliverables. Risks would include any factors that could disrupt the project. They are uncertainties or vulnerabilities that could cause the team to deviate from the project plan.

Risks may be managed through a risk management plan. Establishment of such a plan entails identifying the risks, determining the potential impacts, defining preventive actions, estimating the costs (both monetary and nonmonetary) required to reduce the risks to acceptable levels, developing contingency plans, and obtaining management’s commitment to the risk management plan.

Risk management is valuable in that it minimizes the unfavorable impact of unplanned incidents on a project. It enhances the probability of successful project implementation, creates a sense of urgency when unplanned incidents occur, and facilitates their timely and effective resolution.

Risk management typically involves assessing a number of dimensions of each identified risk. These dimensions include:

• The impact of the risk if it were to occur

• The likelihood that the risk will occur

• How difficult it would be to detect the risk

Each of these dimensions can be assessed separately for a specific area of risk and assigned a numerical low-to-high rating. The three dimension ratings then can be combined (e.g., averaged or added) to produce a relative risk value for the area, which can be compared with the ratings of other identified project risk areas to determine where emphasis needs to be placed in the risk management plan.

One way of judging overall project risk is through a constraint matrix, where three levels of flexibility (low, medium, high) are charted against the elements of schedule, scope, and cost. The purpose of a constraint matrix is to assess the degree of relative flexibility within a given project and the related risk. For example, a project profile that exhibits low flexibility in all three elements (schedule, scope, and cost) is a profile associated with high-risk projects and one that will demand extra careful management.

An example of a project risk management statement is: ‘‘A mechanism is provided for identifying and assessing any adverse consequences of a tentative system selection so their effects can be con- trolled during implementation. A structured approach will be used for developing relative priorities of individual requirements. Shortfalls in the functionality of a tentative selection will be evaluated. Alternative solutions to providing the functionality will be considered and the impact on the effect-

iveness of the overall system will be evaluated prior to making a final selection. Additionally, ar- rangements for holding the source code in escrow will ensure the availability of the source code in the event the software company cannot sustain ongoing viability.’’