The Difference Between Completeness and Delivery

Delivering incremental business value is often different than a finished, complete project.

Start and finish might seem straightforward enough. But in an agile environment, the finish
line can get a little fuzzy. While a predictive project plan clearly maps out the final deliverables,
a team using agile is instead iterating toward a not-yet-concrete solution. That means it’s more
difficult during project kickoff to know exactly where the team will land when the project is
complete.

“Instead of saying, ‘Okay, I know now what you need and I’ll see you in two months,’ to the
project sponsor, you partner with the client to drive the business,” says Bhanu Viswanadha,
PMI-ACP, PMP, application security architect, NetApp, Sunnyvale, California, USA.

The Concept of Complete

Completeness refers to a finished project. The work has been executed; the final deliverables
are done. Incremental delivery, on the other hand, refers to finished work that a team shares
with the client or project sponsor while the project is still ongoing—delivering value more
often than a single, final product. The incremental delivery could be a prototype, a proposed
feature, or a minimum viable product (MVP).

“It doesn’t have to be software, but it could be any finished pieces,” says Viswanadha. Business
tends to be a big fan of incremental delivery, he says, because any feedback gathered during
this stage is meant to inform future sprints or iterations and can be used to refine proposed
features and elements. In other words, “business leaders are reassured that the right work is
moving in the right direction,” he says. “They’re able to see the value.”

These more frequent touchpoints also build trust between the client and project team and can
help sustain engagement on both sides. That’s noteworthy because “when you build the trust
of incremental deliverables, if tomorrow you miss a goal, the business leader is more likely to
understand,” he says.

Delivery Date

Typically, with incremental delivery, stakeholders are aware of the team’s general cadence of
sharing finished deliverables. There’s no hard and fast rule about how often a team needs to
share them. Viswanadha tends to default to sharing finished deliverables every week or two
weeks, depending on the project and the stakeholders.

It’s imperative at this time to have a robust system for gathering and documenting feedback.
While these elements were delivered to the client or project sponsor in an agile environment,
that doesn’t mean they’re set in stone. Future sprints might involve further refining, adding
additional features or reimagining the MVP entirely.

To do that work, the team must properly capture feedback and embrace the mindset that,
although the deliverable has been put in front of the client, the work might not be done. That
mindset is easier to obtain if team members—especially those newer to agile—understand the
difference between completeness and delivery.

Developed by PMI for PMIstandards+™ with contributions from Bhanu Viswanadha, PMI-ACP,
PMP. ©PROJECT MANAGEMENT INSTITUTE, INC.