Top 10 Proven Categories of Deliverables a PM Must Explore

Have you ever felt like your project requires more and more work?

Have you ever felt you needed to create yet another thing you didn’t anticipate initially?

This is the result of scope creep.

It means you failed to identify all deliverables at the start of the project.

Throughout dozens of successful projects, I identified the TOP 10 sources of deliverables you must explore.

#1: Project Charter and Scope Statement.

If you follow a structured project management process, you’ll analyze the project charter and project scope statement. These documents must describe the main deliverables.

In practice, most IT projects don’t have those documents.

#2: Typical Project Life Cycle

For example, the software development life cycle describes a lot of typical deliverables. You must decide whether to make one of them for your project.

UI designs, technical architecture documentation, and regression testing reports are examples of deliverables SDLC recommends as the best practices. You can make them internal for your own use.

#3: Architecture Diagram

An architecture diagram depicts the main components of your IT system. It’s a deliverable in itself.

I strongly recommend creating one for each project.

But likewise, all the components on the diagram are your deliverables.

#4: Internal policies and workflows

They will indicate which project management documentation and processes are mandatory.

#5: Other Project Management Artifacts

While some PM artifacts are not mandatory, they’ll help you manage the project.

However, project management doesn’t come for free. You’ll have to spend the team’s effort on most of the PM artifacts.

• You’ll have to create some documents for internal use.
• You may need to create and present a document to a larger audience.
• You may need an artifact that stakeholders must approve.

The risk register is an excellent example of a non-mandatory but valuable deliverable.

#6: Requirements from SMEs

Communicate with project stakeholders, specifically SMEs. They will have requirements for product architecture, designs, features, and capabilities, which may become a separate deliverable.

For example, many quality requirements come from internal and external stakeholders, such as performance, business validation, or cybersecurity testing, which require formal reports and sign-offs.

#7: Interim Versions of the Product

Talk with project owners and key stakeholders about interim versions of the product or service you must produce for special events. For example, industry-specific exhibitions, workshops, or demos for shareholders.

#8: Putting it Together

Consider what it takes to assemble all the pieces of the product and make them available to the public. For example, what does it take to build the whole service in the production environment?

Sub-deliverables like unique interim versions or fully integrated final products usually go into a unique “integration” deliverable.

#9: Review similar projects in your organization.

In practice, it means talking with other project managers about their experience. Discover the lessons they learned and what they would do in your place.

#10: Brainstorming Deliverables

Use wildcard brainstorming. Work with your team, subject matter experts, stakeholders, and other project managers to identify different pieces of the project that may require significant time and effort to produce.

Here’s a critical idea:

A missed deliverable will impact your schedule and budget more than inaccurate estimates.

So, it’s worth spending extra time on identifying deliverables.

That’s why it’s critical to know how to create and use a Work Breakdown Structure on a project.