How to Define Project Deliverables

This article is the first of the ‘Before the Project Starts’ series. In this series, I’ll 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. Let’s discuss the process of collecting and analyzing project deliverables.

For the company that pays for the project, there is always some value included – usually, it’s some financial or intangible result.

In the article I’m 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.

I’ll be talking about collecting and analyzing project deliverables, but I’ll 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 in the customer expects from the project. Sometimes it’s 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.

Let’s take the following project as an example: ‘Implementing a CRM system in an organization’.

The customer has formulated the following objectives:

• Standardize how the employees work with the clients of the company
• Reduce the expenses for some transactions
• 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 client’s expectations, the project manager should specify the requirements to each project result.

What are the 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.

Let’s take the ISO 9000 definition and agree that a requirement is defined when it’s 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.

Here’s an example of a software requirement classifier:

© 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, that’s why I won’t 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.  

Let’s 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. 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 I’ve 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. That’s why it’s 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):

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 don’t 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 analyzing the existing documentation and finding 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 and discussed of the results of the project.

Brainstorming  is an approach used to generate and gather different ideas connected with project deliverables. It’s 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.

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. It’s 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. It’s based on the requirements of 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 analog 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, I’d 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 doesn’t have a clear understanding of the deliverables or is sure that the existing deliverables are too vague, your project has a level of indeterminacy that’s 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 analyzed 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/analyzing the requirements. He/she should be aware of various approaches and techniques.

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 the requirement collection and analysis!