Understanding the Deliverables of a Project

What Are Deliverables In Project Management?

A project deliverable is any unique and verifiable outcome, result, or capability to perform a service that a project is expected to produce. These can be as broad as the final product of a project or as specific as documents, plans, or software components developed during the project phases.

Why Deliverables Hold the Reins of Success

Deliverables transcend Mere outputs, which measure a project’s success and contribution to organizational goals. They offer a way to evaluate progress, facilitate stakeholder communication, and ensure the project remains aligned with its initial vision.

The Art of Identifying Project Deliverables

Pinpointing your project’s deliverables begins with a deep dive into the project scope and objectives. Engaging with stakeholders, utilizing tools like Work Breakdown Structures (WBS), and iterative refinement sessions are instrumental in this phase. The clarity gained here is invaluable, setting a clear direction for the project team.

Identifying project deliverables begins with clearly understanding the project’s goals and objectives. This involves:

• Collaborating with stakeholders to define the project’s expected outcomes.
• Breaking down the project scope into smaller, manageable parts.
• Tools like Work Breakdown Structures (WBS) are used to outline all the components and deliverables of the project.

Why Project Deliverables Are So Important

Deliverables are more than mere outputs; they measure a project’s success and contribution to organizational goals. They offer a structured way to evaluate progress, facilitate communication between teams, stakeholders, and clients, and ensure the project remains aligned with its initial vision.

Deliverables are critical for multiple reasons:

• They provide a clear vision of the project’s goals, guiding the team’s efforts.
• They serve as milestones to track and measure project progress.
• Successful delivery of these items often signifies the completion of the project, impacting the overall project success.

Challenges in Managing Deliverables

Managing deliverables is akin to steering a ship through uncharted waters. It involves meticulous planning, ongoing monitoring, and adaptability to course-correct as needed. Emphasizing quality control, stakeholder feedback, and precise documentation throughout this journey is crucial for reaching the desired destination.

Managing project deliverables can be challenging due to the following:

• Changing project scopes or requirements.
• Miscommunication or misunderstandings between project stakeholders.
• Resource constraints or unforeseen project hurdles.

Best Practices for Successful Deliverable Management

In the dynamic world of project management, the adept handling of deliverables can often spell the difference between success and setback. This guide aims to illuminate the path toward effective deliverable management, ensuring that your projects meet and exceed expectations.

Define Deliverables Clearly
Start by explicitly defining what needs to be achieved. Each deliverable should be clearly described so all stakeholders understand what is expected.

Establish Realistic Deadlines
Consider the complexity of tasks, potential obstacles, and resource availability to establish challenging yet attainable timelines.

Prioritize Communication
Foster open communication channels among all project participants. Regular updates and feedback loops can help catch issues early, adjust plans as necessary, and keep everyone aligned on the project’s progress.

Use a Collaborative Tool
Leverage technology to keep track of deliverables, deadlines, and responsibilities. A good project management tool can provide visibility, facilitate collaboration, and help manage tasks efficiently.

Conduct Post-Delivery Reviews
After a deliverable is completed and approved, take the time to review the process. Identify what worked well and areas for improvement to refine your approach for future deliverables.

Document Everything
Maintain comprehensive records of all deliverables, including specifications, revisions, and approvals. Documentation is crucial for transparency, accountability, and future reference. For documentation purposes, you can use PDF tools, particularly those that facilitate painless PDF editing as they can greatly enhance efficiency.

Implement a Quality Assurance Process
Introduce checks at various stages to ensure each deliverable meets the set quality standards. Depending on the project’s nature, this might include peer reviews, client approvals, or compliance checks.

Categories of Project Deliverables

Tangible Deliverables: Physical items or products created as a result of the project, such as a building in a construction project or a new software application in an IT project.

Intangible Deliverables are non-physical outcomes like brand recognition or customer loyalty that result from marketing campaigns or customer service improvements.

Internal Deliverables are items or outcomes produced within the project team for internal use, such as project plans, reports, or prototypes.

External Deliverables: Outcomes or products delivered to the client or end-user, including the final product, user manuals, or training sessions.

Milestone Deliverables. Marking significant points within the project timeline, milestone deliverables are pivotal achievements that often trigger the project’s next phase. They act as checkpoints, ensuring the project remains on track and aligned with its objectives.

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 constitutes any unique and verifiable product, result, or service capability that a process, phase, or project must produce for completion.

Example of Project Deliverables

Before the project starts, the project manager and the customer should agree on what results the customer expects from the project. Sometimes, it‘s not as easy as it seems. For example, define the project objectives for holding a corporate celebration and then determine the results to achieve that objective. Was that easy to do? I believe not.

For example, consider an “Implementing Professional Services Automation Software“ project in a professional services firm.

The customer has formulated the following objectives:

• Standardize how the employees work with the clients of the company
• Reduce the expenses
• Enhance client data authenticity

Thus, the expected Project Deliverables:

• Regulations describing how employees should work with the clients
• A software product that automates those regulations
• Employees who are trained to work with that software product
• A functioning support service for software users

To satisfy the client‘s expectations, the project manager should specify the requirements for each Project Deliverable.

What requirements might there be for the deliverables of this project?

There are multiple definitions.

For example, ISO 9000 states a requirement as a need or expectation that is explicit, generally implied, or obligatory.

The IEEE Standard Glossary of Software Engineering Terminology (1990) describes a requirement as a user’s condition or capability to solve a problem or achieve an objective.

Using the ISO 9000 definition as a basis, we can say that we define a requirement when we include it in a document that the customer has agreed to.

Requirement classifiers

We have already compiled some requirement classifiers. They remove the chance of overlooking some essential project requirements.

Here‘s an example of a software requirement classifier:

Karl E. Wiegers “Software Requirements”

This classification reminds the analyst 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 so 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 descriptions of requirement classes.

Let‘s think of what contributes to compiling reasonable regulations describing how employees should work with clients. I would list the following:

1. The regulations should include an accountability matrix describing the function of each process member (there can be some matrix requirements, too).
2. The document should not exceed a certain number of words (a restriction.)
3. The document should be in a specific font (you can indicate its name and size.)
4. The document must include the following parts: (You may specify content requirements for each part.)
5. The document must include a section describing all the changes made in the document, etc.

A requirement classifier for a document containing regulations would help an analyst consider all requirement classes.

To successfully implement the software, it is necessary to train personnel, conduct staff training, and provide software support.

What requirements define ‘a trained employee.’

1. Employees should have completed a training course on using the software
2. There should be a training program to educate employees, which may also have specific content requirements.
3. Training should incorporate actual company practices, which the project client must endorse.
4. At the end of the training course, an evaluation takes place. The average score must be at least… (on a scale from 0 to 10).
5. The testing system is subject to the following requirements … etc.

Requirements for an effective software support service include the following:

1. Service cost per month
2. Service hours (e.g. 8.00 – 20.00 EST)
3. Response time (e.g., 30 minutes from when the call is registered.)
4. Time to resolve issues (issues should be categorized, with each category having its standard for resolution or escalation time.)
5. Service recovery time in case of glitch
6. An opportunity for the users to track the status of their issue
7. A chance to get a call report for a certain period, etc.

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

Any missed requirement will increase the project scope, influencing the timeline and the budget. The project manager must be precise while gathering the requirements before the project starts.

Examples of approaches to requirements gathering.

There is an example of a method that is ranked on a difficulty scale:

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

User observation collects information on how a particular stakeholder fulfills his/her duties and tasks. I think this method is suitable for specifying a product that already exists when the people who use it cannot or don‘t want to state their requirements.

Questionnaires are written questions designed to collect information from many respondents quickly. They should be used when you’re short on time, dealing with geographically dispersed respondents, or operating on a tight data collection budget.

Document analysis is used to identify the requirements by analyzing the existing documentation and finding related information. There are pretty numerous such documents.

An interview is a dialogue-style method of gathering data from stakeholders. Interviewers ask prepared and spontaneous questions and note the answers. As the interview goes on, the interviewer gathers additional information from facial expressions and gestures and asks qualifying questions (which is impossible with questionnaires).

Focus groups include representatives of each stakeholder. A joint discussion helps identify their expectations regarding the product and the project’s results.

In brainstorming, participants generate and collect ideas related to project deliverables. This method is often used with other methods prioritizing the collected requirements, such as the nominal group technique, mind maps, affinity diagramming, etc.

Innovation games – with the help of a business game, the moderator involves the stakeholders in gathering and ranking requirements.

Prototyping is gathering requirements by granting a model of the expected product. This model can be physical, graphical, or computer-based, but it should reflect the future product’s appearance as precisely as possible. It‘s a quick way to get feedback on whether the product meets the expectations and specifies 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 for gathering process (or any activity) execution requirements. Graphical models enable adjustments to the structure of project operations, taking charge of individual actions and scope transformations. Practitioners frequently employ interviews, questionnaires, and focus groups for process modeling.

QFD (quality function deployment) is an approach to new product development that helps define the crucial properties. This approach builds on the requirements of future users. The matrices in this method reveal the connections between the requirements and the technical descriptions of the product, among other details. It’s important to note that this method applies to gathering and analyzing requirements.

After gathering the requirements, you should thoroughly analyze them. You should find out if any requirements 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+), and Value-Conflict Mapping +.

As the list of approaches shows, an analyst should be capable of many things to gather and analyze the requirements successfully.

In conclusion, I‘d like to claim the following: if, as a project manager, you have to take on a project with a specific 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 approach involves treating requirement gathering and analysis as separate projects, using their outcomes to set the timeline and budget for the main project. While not a catch-all solution, it certainly merits consideration.

Resume:

1. Defining the project’s goals, requirements, and deliverables from the beginning ensures its success.
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 and define project scope and labor expenditures. The more precise the requirements, the better one can predict the budget, expenses, timeline, etc.
3. The requirements must be examined for completeness to ensure they don’t conflict and to identify potential implementation barriers.
4. A requirements analyst should be assigned to projects requiring the collection and analysis of requirements. This person should be knowledgeable about different methods and strategies.
5. I usually combine the project manager and requirement analyst roles if a project is small. However, if a project is complex and the budget is sufficient, I hire professional analysts to eliminate risks.

To ensure successful project deliverables, the proper management software is essential.

Using the right project management software makes it easier to organize tasks, team collaboration, track deadlines, and control budgets, making it easier to achieve project goals.

Improve your project deliverables with Birdview PSA

Birdview PSA is a comprehensive professional services automation solution that plays a key role in ensuring the success of project results. With Birdview PSA, the project manager optimizes project management processes, from initial planning to final implementation. Birdview PSA provides robust tools for planning, resource allocation, time tracking, and budget management.

 

Good luck with the requirement collection and analysis!