The Impact of Pricing: Waterfall vs. Agile

One of my favorite things about this consulting world is that I get to see the connection between the advice and the results. In other words, I get to verify that something works:

• I see the financial results of each recommendation I make on positioning, service offering design, and lead gen. If I say that X will result in Y...but it doesn't...I'll know, and I'll have the chance to figure out why.
• I see the impact on staff and culture when I make recommendations on systems or roles and capabilities, and so those suggestions aren't being made in a vacuum, feeding a world that's just in my own head.

And so there is this self-correcting algorithm that keeps getting better. One of the more intriguing comparisons I've been making recently is around the differences and implications between agile and waterfall thinking.

Waterfall is the more ancient and frequently despised manner of working with a client. Agile is the more modern, hip, sophisticated manner. But, as you can guess, it's not quite that simple. I'm not going to get into a detailed, purist description of either—I know that would make some of you happy, but I'm not going to risk losing tens of thousands of other readers just to be absolutely precise.

In this case, I just want to contrast the two methods as they relate to pricing your work.

In a waterfall world, you have a big project that starts and stops at defined junctures, and there's a specific price that clients will pay unless they step outside the scope.

In an agile world, you set off on the journey, making constant course corrections, getting paid for what you do with every sprint. Together, you and the client determine where your efforts can be most useful.

Agile arose via software development, which was by definition far more organic and difficult to predict. But now it has migrated into many other places. Not too long ago, a PR firm was the main place where you might find a monthly retainer (outside of partial retainers in the advertising world). Now, it's common far beyond dev shops: SEM, SEO, CRO, and on and on.

Both methodologies bring pros and cons, but what impact do they have on pricing, specifically? There are very specific challenges of each.

Challenges for Pricing/Profit with Agile

• Agile requires more transparency. Clients will know who has been assigned and what you charge, at least for the team and maybe for the individuals. Since the client has a hand on adjustments to the journey, they want and need more information than you may be comfortable sharing.
• Agile requires enormous trust. You are essentially working without the real incentive of getting a specific thing done by a specific timeline to preserve your own profitability, and so your clients must trust that you are expending your best efforts on their behalf.
• There's only so much money you can make. There's a ceiling, constructed by a combination of what you charge and how much capacity you have. Yes, you can keep people busy at a higher rate, but that rate is always transparent (see above).
• Any slippage in capacity planning is going to hit your bottom line like a sack of bricks. People are used in small groups, and the small groups must be gainfully employed to make it work. The catch is that the most vocal proponents of agile are usually the ones who struggle the most with biz dev, too, and so there's this inevitable mismatch.
• Dedicated agile teams begin to resemble staff aug, and the cultural tax starts to add up. When you have an agile team, the client demands a different sort of control and they can easily become "the manager" with all the implications that come with that. But your team signed up to work for you and not the client.

Challenges for Pricing/Profit with Waterfall

• Waterfall doesn't work unless you're really good at estimating, which means that you're really good at scoping in an uncertain world. Sure, you can use a diagnostic or a roadmapping exercise to surface the true requirements (and thus development path) of a project, but you cannot wring all the risk out of the process. It's high risk...but also high reward, if done appropriately. This "estimating" reality is what drives most firms toward an agile world, and it's an understandable motivation.
• Changes in direction are more adversarial than they would be in an agile world. Both parties need to check their notes around scope and there's a constant question lurking over all requests: "did we agree to do this for that amount of money?" Changes to scope, which are essential to the waterfall method, can be less graceful. Here's where I need to shine a light on loser firms who intentionally shoot low...to get the work...and then sock them at every turn. They are one-hit wonders who move on to the next victim.
• You can lose your shirt, or you can make out like a bandit. It isn't uncommon for newer firms to spend 2x what they estimated (on time) to get the job done. But they learn, adapt, and then master it. Then they move to a more "value-based" approach and exceed what any agile-driven firm ever could.

This isn't a black and white issue. Neither system has all the answers. If you're going to go with agile, have exceptionally strong lead flow and a waiting list and keep raising prices for sprints. If you're going with waterfall, master the scoping game and make scope creep less adversarial than it needs to be.