Customer analysis

Don’t assume needs

Every project exists to satisfy a customer need.
This may be a direct customer, for example, manufacture of a car or it may be indirect, for example, the design of a heating and ventilation system for a Project Sponsor on behalf of another customer.

Whoever the customer, one needs to know that the project will produce what the customer actually wants and not what the project team think he or she wants.

There needs to be some sort of formal mechanism to make sure that the project team gets this right.
You can’t assume you know exactly what those needs are.

Challenge requirements

Whilst the customer may well have an idea of what he wants he will need to be challenged to clarify the details and resolve any technical issues.
Just accepting what the customer suggests can also lead to problems if views alter later in the project.

It isn’t really good enough to receive some information from the customer and to begin planning on this basis.
There should be dialogue with the customer to clarify and agree exactly what he or she wants.

Quality issues

Performance

What performance is expected? Is it basic or state of the art?

Materials

One would need to clarify quality of materials.

Dimensions and tolerances

Physical dimensions including tolerances.

Technical limitations

Need to agree analytical techniques, test procedures for measuring performance.
What are the technical limitations?
Does the customer really mean what he or she says?

Cost and time limitations

Until the project is ‘costed’ in some form it will be difficult to assess the cost differences of a variety of designs and strategies.
However, one should have a feel of the magnitude of costs and the customer should have a limit of expenditure.
If any agreed product design alterations mean extra costs the customer must either to agree the extra expenditure or forego them.

Does the customer have any time restrictions?
The cost of a project can soar if time lines need to be cut.
Certain technical issues and delivery lead times may have a large impact on requested delivery dates.

Scope

What is and isn’t included?
This requires agreement allowing you to clarify the scope.

This information needs to be reviewed with the customer in face to face meetings.
It is up to the project team to challenge the customer’s wishes and remove all uncertainty.
The exact nature of the discussion with the customer will be dependant on the project and will probably require more than one visit to clarify all of the issues and agree the product specification.

There are other techniques you can use to clarify the needs of the customer which are more aligned to marketing e.g. Quality Function Deployment (QFD).
The method used to ascertain and clarify customer needs should be recorded in the Project Notebook.
The control of these areas will impinge upon the Quality Plan, for example, there should be Quality Control procedures that check the specification of raw materials.

PRINCE2® 2009 use the process of Configuration Management for product control.

Configuration management is the technical and administrative activity concerned with the creation, maintenance and controlled change of configuration throughout the life of a product (or item).

A configuration item is an entity that is subject to configuration management.
The entity may be a component of a product, a product or a set of products that form a release.

For example:

A component of a product: an electronic motor that is part of a piece of machinery
A product: a piece of machinery
A release: a piece of machinery, the refitted machine room, training materials, and the necessary health and safety certificates.
[see Change - Change defined - Configuration management]

Modifications to the product are under PRINCE2 [see ‘The Complete Project Management plus PRINCE2’] use a common approach to dealing with requests for change, off-specifications and problems/concerns.
[see Change - The PRINCE2 approach - Issue and change control procedure]

Issue and change control procedures ensure that all issues and changes which may affect the project’s agreed baselines are identified, assessed and either approved, rejected or deferred.
[see Change - Change defined - Issue and change control]