How to Define Project Deliverables

This article is the first of the Before the Project Starts series. In this series Ill explain what a
project manager needs to do before the start of a project to eliminate any uncertainties.

In my mind, the most important thing is to define the desired project results and work through
the deliverables to each of them. The more defined the deliverables are, the easier it is to forecast
the timeline, the budget and the scope. Lets discuss the process of collecting and analyzing
project deliverables.

For the company that pays for the project there is always some value included - usually its some
financial or intangible result.

In the article Im going to use the deliverable definition that PMBOK V gives:

A deliverable is any unique and verifiable product, result, or capability to perform a service that
must be produced to complete a process, phase, or project.

Ill be talking about collecting and analyzing project deliverables, but Ill also allow myself to
change the term deliverable for the term project result while keeping the definition.

Before the project starts, the project manager and the customer should agree upon which results
the customer expects from the projects. Sometimes its not as easy as it seems. Try to define
project objectives for holding a corporate celebration, then define the results that will let you
achieve that objectives. Was that easy to do? I believe not.

Lets take the following project as an example: Implementing a CRM system in an

organization.

1
The customer has formulated the following objectives:

1. Standardize how the employees work with the clients of the company
2. Reduce the expenses for some transactions
3. Enhance client data authenticity

Thus the expected project results:

1. Regulations describing how employees should work with the clients

2. A software product that automates those regulations
3. Employees that are trained to work with that software product
4. A functioning support service for software users

In order to satisfy the clients expectations, the project manager should specify the requirements
to each project result.

What are definitions of a requirement?

There are multiple definitions.

For example, ISO 9000 gives the following one: a requirement is a need or expectation that is
stated, generally implied or obligatory.

The IEEE Standard Glossary of Software Engineering Terminology (1990) describes a

requirement as a condition or capability needed by a user to solve a problem or achieve an
objective.

Lets take the ISO 9000 definition and agree that a requirement is defined when its put into a
document the customer agreed on.

Requirement classifiers

Some requirement classifiers have already been compiled. They eliminate the possibility of
missing out on some of the important project requirements.

Heres an example of a software requirement classifier:

2
 Karl E. Wiegers Software Requirements

This classification reminds the analyst of the fact that he/she also has to specify the external
interface requirements and system constraints (besides the functional requirements of the
product.) Also, it helps to understand what to start the requirement gathering with and how to
specify those requirements (the arrows on the diagram show the sequence of requirement
gathering, but the analyst can still go back to previous stages.) Wiegers gives definitions and
examples of each category, thats why I wont repeat them in my article.

This way, an analyst already has something to base product requirement gathering on - there
are requirement classifiers and requirement classes descriptions.

Lets think of what contributes to a good regulations compilation that describes how
employees should work with the clients. I would list the following:

1. The regulations should include a process description in a notation (here you put the name of
the notation.)
2. The regulations should include an accountability matrix. The matrix should describe the function
of each member of the process (there can be some matrix requirements, too.)

3
 3. The document should not exceed a certain number of words (this is a restriction.)
4. The document should be written in a certain font (you can indicate its name and size.)
5. The document must include the following parts: ... (content requirements may be given to each
part.)
6. The document must include a section describing all the changes made in the document, etc.

Sure, having a requirement classifier for a document containing regulations would make it easier
for an analyst to consider all classes of requirements, but Ive never come across such a classifier
so far.

What are the requirements that can be applied to what can be called a trained employee?

1. An employee should have completed a training course on using the software

2. A training course should be designed to train the employees (there can also exist some content
requirements.)
3. The training should include real-life company practices. The practices used as an example should
be approved by the project customer.
4. An assessment is held at the end of the training course. An average grade should be no less than
(on a 0 to 10 scale.)
5. The following requirements are applied to the testing system etc.

A functioning software support service requirements can be the following:

1. Service cost per month

2. Service hours (e.g. 8.00 - 20.00 EST)
3. Response time (e.g. 30 mins from the moment the call is registered.)
4. Issue resolution time (a classification of issues should be introduced, each having a
resolution/transfer time standard.)
5. Service recovery time in case of glitch
6. An opportunity for the users to track the status of their issue
7. An opportunity to get a call report for a certain time period, etc.

After the project requirements are defined, the project manager can start planning the statement
of work and forecasting project scope, budget and timeline.

It should be kept in mind that any missed requirement will result in an increase in project scope,
which will influence the timeline and the budget. Thats why its vital for the project manager to
be very precise while gathering the requirements before the project starts.

What are the approaches to requirement gathering?

Here are the most widespread ones:

Those methods are placed on a difficulty scale (the placement is completely subjective):

4
User observation, questionnaires, document analysis, interview, focus groups,
brainstorming, innovation games, prototyping, process modeling, QFD.

User observation is used to collect information on how a certain stakeholder fulfills his/her
duties and tasks. I think this method is good for requirement specification to a product that
already exists, when the people who use it cannot or dont want to state their requirements.

Questionnaires are written sets of questions designed to quickly collect info from a large
number of respondents. Questionnaires are best suited for situations when the time is limited and
the respondents are territorially distributed, or when the budget for data collection is limited.

Document analysis is used to identify the requirements by analysing the existing documentation
and finding the information that is somehow related to the requirements. Such documents are
quite numerous.

An interview is a way of getting data from stakeholders in the form of a dialogue. Both prepared
and on the spot questions are being asked, the answers are noted down. As the interview goes
on, the interviewer gets a chance to get additional info from facial expressions and gestures and
to ask qualifying questions (which is impossible with questionnaires.)

Focus groups are representatives of each stakeholder. A joint discussion helps identify their
expectations towards the product discussed of the results of the project.

Brainstorming is an approach used to generate and gather different ideas connected with project
deliverables. Its commonly used along with other approaches that presuppose some
prioritization of the gathered requirements (e.g. the nominal group technique, mind maps,
affinity diagramming, etc.)

Innovation games - with the help of a business-game the moderator involves the stakeholders
into the requirements gathering and ranking.

5
Prototyping is a way of requirement gathering by granting a model of the expected product.
This model can be physical, graphical or computer-based, but it should reflect as precisely as
possible what the future product is supposed to look like. Its a quick way to get some feedback
on whether the product meets the expectations, and also to specify the requirements. Prototypes
support the concept of consecutive requirement specification in a series of iterations, holding
experiments by the end user, framing opinions and prototype revision.

Process modeling is a method used to gather process (or any activity) execution requirements.
Graphical models used give a chance to adjust the structure of project operations that are
responsible for separate actions and scope transformations. Interviews, questionnaires and focus
groups are frequently used for process modeling.

QFD (quality function deployment) is an approach that helps define the crucial properties in
new product development. Its based on the requirements of the future users. The matrices used
in this approach can show the links between the requirements and technical descriptions of the
product, etc. Note that this method is used for both requirement gathering and analysis.

After the requirements have been gathered, they should be thoroughly analyzed. You should find
out if there are any requirements that contradict each other, if they are complete and if there are
any obstacles to their fulfillment. A project manager can use the following techniques: reversive
requirement analysis, system analogue analysis, the Theory of Inventive Principles (TRIZ), Root
Conflict Analysis Plus (RCA+), Value-Conflict Mapping +.

As you can tell from the list of approaches, an analyst should be capable of quite a lot of things
to successfully gather and analyze the requirements.

In conclusion, Id like to claim the following: if, as a project manager, you have to take on a
project with a certain deadline and budget, but your team doesnt have a clear understanding of
the deliverables or is sure that the existing deliverables are too vague, your project has a level of
indeterminacy thats way too high. How do you solve this issue? One of the ways is to make the
requirement gathering and analysis a project of their own, and then rely on the results of this
project when determining the timeline and the budget for your main project. This is not a cure-all
solution, but it sure has to be considered.

Resume:

1. The success of the project is determined at the very start of it - by specifying project goals,
requirements and deliverables.
2. Collecting the requirements gives the team an understanding of what the stakeholders expect
from the project. Based on that knowledge, the team can introduce technical solutions to fulfill
those requirements, define project scope and labor expenditures. The more precise the
requirements, the better one can predict the budget, expenses, timeline, etc.
3. The requirements should be analysed to see if they are complete, whether or not they
contradict each other and if there are any obstacles to their fulfillment
4. An introduction of a requirement analyst should be planned for a project that requires
gathering/analysing the requirements. He/she should be aware of various approaches and
techniques.

6
If a project is small, I usually combine the role of the project manager and the requirement
analyst. But if a project is complex and the budget is sufficient, I try to hire professional analysts
to eliminate risks.

Good luck with requirement collection and analysis!

http://project-management.zis.by/start-proekta/chto-nuzhno-sdelat-do-starta-proekta.html

Source: http://explore.easyprojects.net/blog/how-to-define-project-deliverables