Clear and accurate definition of a project is one of the most important actions you can take to ensure the project's success. The clearer the target the more likely you are to hit it. Defining a project is a process of selection and reduction of the ideas and perspectives of those involved into a set of clearly defined objectives, key success criteria and evaluated risks.
This definition process should culminate in the production of a Project Definition document, sometimes called a Project Charter. The Project Definition document should be approved and issued by a manager with the authority to apply organisational resources to the project activities. Therefore, the seniority of the manager or the management team will be commensurate with the size, cost and business value of the project. As a minimum, the Project Definition should include a statement of the business need that the project seeks to address and the description of the product, service or deliverable business objectives that will be its output. When a project is performed under a contract between seller and buyer, the signed contract may well serve as the project charter for the seller. However this may not necessarily be the case for the buyer whose project may include more than the product or service purchase under the contract.
The way to define a project is to ask a standard set of questions of yourself (as project leader) the project team, colleagues with particular expertise and senior managers. The questions fall into the categories given below.
The Purpose (or Mission)
This is the reason for doing the project
These are the targets we want to meet
The Beneficial Gains or Scope
This is how our organisation will gain. Here we define our performance criteria and set our quality standards for the project.
First, imagine that you have no constraints. Use brainstorming and other techniques to generate ideas that most succinctly describe the Purpose, Goals and Beneficial Gains. Now reduce these down to the fundamentals.
We need to define specific measurable objectives from our broad aims. These objectives will tell us if we have met our goals and to what standard.
From our list of specific goals for the project we must develop a set of measurable objectives that will confirm that we have reached certain project milestones (or way points) including the final one of project completion.
The measurable objectives (when achieved) demonstrate the extent to which the beneficial gains have been achieved, the goals have been met and that the purpose of the project has been achieved.
Key Success Criteria (KSC)
These are the objectives that, if all else fails, we must meet and/or those that we must meet for the project to be deemed successful even if other objectives are met and achieved.
From the list of objectives select those that are critical or key to the success of the of the project. These are the items that are critical to those who will benefit from the project and those with the responsibilities for judging success criteria (Managers, Customers, Members, Shareholders, Stakeholders etc.).
The purpose of this is twofold. Firstly, to clarify in the minds of the project team and service managers what are the essential benefits that the project will deliver. Secondly, if circumstances change within the life of the project then it is often extremely useful to see what were the agreed success criteria at the start of the project.
The project may then be replanned to ensure the KSC are met or the KSC may be formally changed (by Senior Managers in the light of changed circumstances) and the project redefined and replanned to ensure they are met.
The fundamental objective of a project is to deliver something new.
It is not always easy to distinguish between aims (goals), objectives and deliverables. If the project is to create new products or modify existing ones, then the list of deliverable items may be as simple as a set of part or product numbers. It may be 3 sets; new parts or products, obsolete parts or products and products or parts not affected by the project. These deliverables are easily distinguishable from the goal; which may be to increase market share by 7%, and the objectives; to have the product shipping by the 3rd quarter of the year, at a works cost price of £300, with shipments reaching or exceeding 5000 per month by end of the year.
However, the deliverable items may be less easy to distinguish in some projects. A project to deliver the implementation of a new integrated housing management computer system will deliver parameter set-up, data transfer, staff training, etc. But these look very little different from the objectives; parameter set-up by 30th March, data conversion by 15th June, and staff training by the end of July.
In the first example, a new product will have a specification (or a set of specifications) which defines its essential elements, its functions, its quality standards, its marketing requirements, etc. These will form part of the project's deliverables or they may have been deliverables of a previous research project. Thus the deliverables may be reduced to a simple set of inventory numbers.
The deliverables of the second project should concentrate on the qualitative and quantitative aspect of the project. For example, the set-up phase will deliver the responsive repairs functions of the Repairs Module but not the programmed works functions. The data transfer will deliver the defect description but not the itemised repair for completed and paid orders for the last 4 years. The training in July will not include the production of statistical data.
In effect, the deliverables list becomes a set of specified outputs (a quantity and quality specification) for each milestone or way point of the project.
Every project has constraints. The primary ones are the trade off between Time, Resources and Performance Criteria. We must define our project so that we can manage these constraints.
To define our project we have to make some hard choices to select and balance these constraints. Let us look first at Resources and Performance Criteria and then Time.
Resources are people, equipment and money. They may be internal or external and include suppliers, contractors, partners, statutory bodies, governments, banks, loans, grants, expert opinion (Lawyers, Accountants, Consultants), etc.
Generally, we are reasonably good at estimating or obtaining estimates for the use and costs of external resources. Where we aren't we can obtain expert opinion (another cost). Where we often fail is in estimating the cost of the use of our internal resources, particularly people.
Aside from the employment costs, there are:-
Because internal resources are so constrained it is vital that we select our projects with the utmost care to maximise the use of that resource. Defining projects helps us to make this selection objectively and rationally. Consider these definitions :-
Work in a project is proportional to the number of Objectives and the Performance Criteria
Clearly, if we reduce the number of our objectives and the performance standard (e.g. 5% rather than 10% improvement of sales or reduction of costs then we can reduce the work required to complete the project.
Number of resources deployed x Time = Work
So, another way of expressing work is in the number of resources we will need and the time those resources will have to be deployed on the project. If we can reduce the work we can reduce the time and/or the number of resources. It must be borne in mind that the relationship between the number of resources deployed and the time it takes to do a given amount of work is not linear. Often, just adding people to a project can increase the time because they have to be trained, managed and their work co-ordinated with others. All this takes work and therefore time.
If we decide that all the objectives must be met and we cannot reduce the work then what other options do we have?
Time =Work ÷ Resource Capability
Sometimes we can speed up the work by using bigger, faster, more powerful machines (computers, plant and machinery) but, of course, this has a cost. When the resource is people we can employ more highly skilled, more intelligent and more capable people (if we can find them and persuade them to work on the project). But, whether it is machines or people :-
Resource Capability is normally directly proportional to Resource Cost
Work x Resource Cost = Total Cost
Therefore, to reduce the cost of a project and/or to conserve resources for other projects we need to keep the work to a minimum consistent with achieving the aims and objectives of the project. But as the Work is reduced by increasing the Resource Capability there is a trade off between resource cost and Total Cost. There may also be a reduction in overall project time and this may have its own opportunities, benefits and/or cost savings.
The Performance Criteria are the things the project will deliver and to what quality standard they will be delivered. For example:-
2. Every external employee must have access to corporate E-mail and one departmental server via ISDN connections
3. Every employee must have access to all corporate computer systems via ISDN (from home) and modem (from hotels)
The equipment costs; the number and complexity of tasks and the knowledge requirement associated with each of these performance criteria is very different. For example it is not possible to deliver the same performance using a modem as it is using an ISDN line so further definition is required if performance criteria 3 is selected.
One of the main reasons for producing a well defined Project Definition is to ensure that the Performance Criteria are set and agreed. We must define what it will NOT deliver, what it will deliver, and to what quality standard. The clear aims and the measurable objectives derived from the definition process enable us to set the Performance Criteria and the quality standard. Why is this important?
The number, size and complexity of
Project Tasks are directly proportional to the Performance Criteria
which have been set for the project. The Performance Criteria, therefore, determines the amount of work to be done.
When looking at resource decisions we have seen that these are directly affected by the amount and type of work that has to be done. Therefore, the time the project will take and the amount that it will cost can be expressed as follows:-
Performance Criteria are directly proportional to the
Resource Days required
divided by the Resource Capability available for each task
And: as Resource Days x Time = Work
And: Time =Work divided by Resource Capability
And: Resource Capability is proportional to Resource Cost
And: Work x Resource Cost = Total Cost
Increased Performance Criteria = Increased Project time and Project Cost
So, to increase the performance criteria it is almost always necessary to increase the Work or to obtain resources with greater capabilities (i.e. they can perform the same work in a shorter period of time). For example by using machines or highly skilled staff we can decrease the Resource Days or we can choose to keep these the same and increase the Performance.
If we choose to reduce the Resource Days by increasing the Resource Capability this will not necessarily reduce the Total Cost because the reduction in resource days may be out weighed by the increased Resource Cost.
However, improved Resource Capability will reduce the task time and there is often a delivery Time Cost associated with a project so that the cost to the organisation will be less or its income improved. This is the so called 'window of opportunity' factor.
So it is self evident that there is always a trade off decision to be made between Time, Resources and Performance Criteria. This is why the Project Definition is so important. It allows us to define that trade off, to have the senior managers approve it and the consequent allocation of resources.
We need to identify, quantify and make contingency plans to deal with project risks.
The constraints on a project are one form of risk. The project may well have specific constraints that lead to identifiable risks. What do we mean by project risk? A risk is anything that will have a negative impact on any one or all of the primary project constraints - Time, Resources and Performance Criteria.
Some examples might be:-
A person selected to do work on a project may not have the skills to do the work. If this risk is identified then the project plan can allow for training time and learning curve time. Alternatively, another resource may be identified.
A vital machine may be scheduled for maintenance during the time it is required for the project. Both the fact of the maintenance schedule must be known and the effect of early or late maintenance or even machine substitution must be assessed and built into the project plan.
Let us take the example of a new computer system implementation and look at what is often one of the most time consuming tasks (one that is so often prone to increased duration) and see how we might reduce the associated risks.
What are the risks?
That the 'live' date will be delayed.
That the system may not operate correctly.
That the customers will be dissatisfied.
That the organisation will be publicly criticised.
That, in consequence, the organisation will lose income or market share.
Risk can be reduced by analysing what is essential data, what is accurate data and what is merely nice to have. Risk is minimised by transferring only essential data that is also accurate. Re-enter essential but inaccurate data and store the rest on CD-ROM when the data transfer part of the project is complete. You may never use this data but you will have a warm and comfortable feeling for having done it. Obviously, putting only your best people on the project will also substantially reduce the risk of delay and the consequences of having inaccurate data.
From this Project Definition process comes the information to construct and outline Project Plan.