What makes a successful project?

Waterfall project management tells us it’s about meeting scope, time and cost goals.

Do these success metrics also hold true to agile projects?

Let’s see.

• In agile projects we learn new information all the time. It’s likely that the scope will change over time, because we find out things we assumed the customer wanted were wrong, while features we didn’t even think of are actually needed.
• We know that we don’t know everything when we estimate scope, time and budget. Visibility is incomplete. This is true for both kinds of projects, but in agile projects we admit that, and therefore do not lock those as goals.
• The waterfall project plan is immune to feedback. In agile projects, we put feedback cycles into the plan so we will be able to introduce changes. We move from “we know what we need to do” to “let’s find out if what we’re thinking is correct” view.
• In waterfall projects, there’s an assumption of no variability, and that the plan covers any possible risk. In fact, one small shift in the plan can have disastrous (or wonderful) effects on product delivery.
• Working from a prioritized backlog in agile projects, means the project can end “prematurely”. If we have a happy customer with half the features, why not stop there? If we deliver a smaller scope, under-budget and before the deadline, has the project actually failed?
• Some projects are so long, that the people who did the original estimation are long gone. The assumptions they relied on are no longer true, technology has changed and the market too. Agile projects don’t plan that long into the future, and therefore cannot be measured according to the classic metrics. Again, visibility matters because the actuall status is visible, not past estimations and assumptions.
• Quality is not part of the scope, time and cost trio, and usually not set as a goal. Quality is not easily measured, and suffers from the pressure of the other three. In agile projects quality is considered is first-class citizen, because we know it supports not only customer satisfaction, but also the ability of the team to deliver in a consistent pace.

All kinds of differences. But they don’t answer a very simple question:

What is success?

In any kind of project, success has an impact. It creates happy customers. It creates a new market. It changes how people think and feel about the company. And it also changes how people inside the company view themselves.

This impact is what makes a successful project. This is what we should be measuring.

The problem with all of those, is that they cannot be measured at the delivery date, if at all. Cost, budget, and scope maybe measureable at the delivery date, including against the initial estimation, but they are not really indicative of success. In fact, there’s a destructive force within the scope, time and cost goals: They come at the expense of others, like quality and customer satisfaction. If a deadline is important, quality suffers. We’ve all been there.

The cool thing about agile projects, is that we can gain confidence we’re on the right track, if customers were part of the process, and if the people developing the product were aligned with the customer’s feedback. The feedback tells us early on if the project is going to be successful, according to real life parameters.

And if we’re wrong, that’s good too. We can cut our losses and turn to another opportunity.

So agile is better, right?

Yes, I’m pro-agile.

No, I don’t think agile works every time.

I ask that you define your success goals for your product and market, not based on a methodology, but on what impact it will make.

Only the you can actually measure your own version of success.