PRINCE2 Project Requirements

THE WIZARD WAY TO DECIPHER project requirements

Brought to You by Dave Litten

CAPTURING PRINCE2 PROJECT REQUIREMENTS

Early in your project, project requirements are often gathered in an ad-hoc manner with the result that those requirements may be open to interpretation making little sense of those that are most important.
A technique that is useful here is called the " voice of the customer" (VOC) which helps you understand your customer requirements.

This expression and describes information coming from the customer, perhaps through market research will face to face discussion, which enables you to determine your customers' CTQ's and what value means to them.

So what are PRINCE2 CTQ's?

The CTQ's express the customer's requirements in a way that is measurable. CTQ's a vital elements providing you with a basis to assess how well your project is performing in meeting your customer requirements.

In striving to understand customer's requirements and their perception of value, it is useful to understand the Kano model as shown below:

The Kano model in PRINCE2

The Kano model involves three main categories:

Must-be's. These are the unspoken customer requirements as they are so obviously required that they do not expect to have to spell them out. Meeting these requirements will not increase customer satisfaction as they are the absolute minimum the customer is expecting. These Must-be requirements are often refer to as 'dissatisfiers'

One dimensionals. The more of these requirements that are met, the higher the customer satisfaction, and are referred to as 'satisfiers'

Delighters. With these, the customer is surprised and delighted by a requirement that your project has met and therefore satisfaction would increase even as some other elements have not been delivered as well as they might

Obtaining the voice of the customer

Your PRINCE2 project will do this by talking with, listen to and those serving your customers - the trick is, to translate what the customer says into a measurable requirement - and these are the critical to quality customer requirements.

They are gathered in order to understand customer needs, identify the key issues, and translate them into terms that means something and that you can measure. Takes care here to focus on gathering your customer requirements and not determining solutions to meet those requirements.

Researching your PRINCE2 customer needs

As you plan your PRINCE2 project research, be aware of the following issues:

The customer may offer you a 'solution' rather than express their real needs. To resolve this, ask the customer 'why'd you want this?' Until you truly understand their real needs
Different customers may perceive the same product or service differently so you may need to capture and prioritize the differing views
Take care to remember that your customers may states how they will use of product or service but this is not always the same as how they are actually use it!

External customers generally expressed effectiveness needs - needs that relates to the value the customer receives from the product or service. On the other hand, internal customers tend to express efficiency needs - needs that relates to the amount of resources allocated or consumed in meeting the customer's requirements.

Customer interviews are helpful as a research technique, and the aim here is to understand a specific customer needs and requirements, values and points of view on service issues, product/service attributes and performance indicators/measures.

Ask open questions rather than ask in a series of closed questions that simply elicit a yes or no response. Another way of identifying your customers needs and CTQ's is by observing the customer carrying out their daily jobs and routine activities.

Considering PRINCE2 critical to quality customer requirements

When using the VOC information you need to develop the CTQ's. These should be written in a measurable form as they provide the basis for your process measurement data. Without this type of data, you will not know how your project is performing in meeting the customer requirements.

A CTQ should not prescribe a solution, but should be measurable and where appropriate, have the upper and lower specification limits and a target value.

A CTQ should be a positive statement about what the customer wants rather than negative statement about what the customer does not want.

As an example here, suppose that your project is delivering a new invoice Processing System. Taking this one of the potential CTQ's of such a system, let's consider Speed.

Examples here could be that bills are paid on time, deliveries are made on time, the response time to answer calls, and turn-around time on orders.

Measures for these could include, elapsed times and deviation from target, turnaround times, call answer rate and call abandon rate.

Prioritizing your PRINCE2 customer requirements (CTQ)

Clarifying CTQ's is obviously important, but you also need to find out which of the CTQ's are especially important to your customer. You can prioritize these in a number of ways - you could ask your customer to weight their own CTQ's or you can use a simple tools such as paired comparisons.

Paired comparisons forces the customer to make choices by looking at each year from a list of options. Rather than getting your customers to identify their top choice, you ask them to select their preference from each pair.

PRINCE2 Paired comparison of Requirements

As an example here, suppose you have five CTQ's. You ask, " do you prefer A or B? A or C? A or D? A or E?

After A, you compare B and C, B and D, and B and E and so on.

User Stories in PRINCE2

User stories are a format used to gather customer requirements. Such requirements should be small enough to be broken down into tasks. User stories all one action of value that an end user will achieve.

An example might be:
" As a shopper, I want to be able to scan a product bar code with my phone so that I can compare and find the lowest price of the same product at multiple stores"

All the user stories must be prioritized, so that at the earliest point within a project, you can be sure that the highest priority requirements have been met.

It is quite common to use three by five index cards to write out each user story. The front of the card is written in the format of " as a < user> I want to < action> so that < benefit>

The user story acceptance criteria is written on the flip side of the card, and is in the format of " when I do this: < describe the action, such as 'e-mail potential dates'> this happens < describe the results: 'I can see the sent emails in my Sent folder'>

Want to Become a PRINCE2 Practitioner?

find out how