Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The Procurement Problem and Agile Methods

December 4th, 2007 · 4 Comments

OK, I’ve had enough; it’s time for another rant. Once again I find myself bewildered and befuddled by the sound and fury of the Agilistas as they seek to dethrone the PiMPs. Tell me something all you clever people out there, if Agile is sooo good, why has it not taken over the entire industry by now (it hasn’t, trust me)?

You could say it’s a standard ‘paradigm shift’ and that it will just take time for everybody to slowly get on board. It would be nice to think that but, I’m here to tell you that, unfortunately, it won’t be that easy. Why? Because the waterfall methodology still solves problems that Agile doesn’t solve.

“What?” you say. “Impossible!” you say (ahh yes, I can almost hear the rotten tomatoes hurtling toward me now).

It’s true. The real problems that waterfall was designed to solve (and perhaps even what it evolved and adapted to solve (gasp!)) are procurement problems. Let me say that again: Procurement Problems.

Let’s brush up on a little Capitalism 101. People with money frequently want to trade some of their money for something else of value to them. When the something else is raw material or oil or some commodity item, it is relatively easy to work out the deal. “I need 200 more gallons of Foo to add to my inventory so I don’t run out. Who has the best price on Foo this month?” When you get into more specialized items like CPU chips, price is still very important, but there is now another consideration: timing. “I’ll pay $90 per chip, but you have to get 4000 of them in my warehouse by the end of next month. Who can promise me 4000 chips right now?” And if you get into even more specialized things, like acquiring a company or getting plastic surgery or a trial lawyer, there is something even more important still: risk reduction. You’re only getting one and it will be really expensive. All kinds of things can go wrong if you choose poorly. You need the best supplier of whatever it is that you can get.

A real business person who has their own budget authority and who wants to buy (outsource) a software development project fits this mold. Yes, they’d like the developer to be inexpensive, but what they want more than that is to get the value they expect out of the application. There’s a real business need for having this application (which has maybe 40 features) and the sooner they can start realizing that value, the better. And what they desperately need is for the developer to reduce the project risk as much as possible. Perfect for Agile, right?

Yes, except that the business person is not too savvy at evaluating technical talent or organizational capabilities, so the business person is left to try to measure a developer’s ability to reduce risk by evaluating whether the developer is oozing with experience and confidence and talent and provides a beautiful proposal with mature-sounding procedures and cool business cards. You don’t have to use an Agile method to do that.

If you’re proposing an Agile project, what risk are you taking away from the buyer (from her perspective)? What exactly are you promising to do? Are you promising to work efficiently and constantly keep her involved in your project to collaborate and see progress? What if your competition promises to finish all 40 features of the desired system for a fixed price, by a specific date as long as the business person doesn’t change her mind about what she wants. Which sounds more attractive? Which proposal sounds less risky to the un-initiated?

It gets worse. The reality is that business person with her own idea of what she needs and her own budget authority accounts for a small amount of the total dollars spent on projects. In my experience, she’s less than 50% and I’ve worked in companies that specifically target that kind of customer. It’s probably much less than that overall.

What is much more common is to have a business person who has an idea of what they want, but they have to get money approved through a corporate purchasing function. This means that the real root of all this methodology evil will be involved in your project – procurement people.

Procurement people constantly screw up the process of buying a software project because they treat it the same way as buying 200 gallons of Foo. This is especially true in government and manufacturing organizations. They do this in the great hope that it will benefit their organization enough that they can keep their job another year. I’ve heard that some of these people get a commission on how many discount dollars they can wring out of suppliers’ prices. So, price is always supposed to be as cheap as possible and fixed, the date is always supposed to be guaranteed, the scope is…well luckily they don’t know what scope is, so they skip that part, but yes you do need to have customer references and insurance and blah blah blah to prove you’re an excellent supplier of Foo and if you just sign their standard terms and conditions stating that anything of value you might ever achieve in life can be claimed by them to be their own intellectual property, then your proposal will be reviewed alongside the six other submissions for the job.

The business person is still there, but the only thing they have to cling to is their vision of what features the application should have. In fact they probably had to write a spec so the procurement people could put it out for bid. So, if you are going to propose an Agile project on a spec that was written by somebody else, how would you do it? What, exactly would you be promising? You will be required contractually to have a fixed price, you might also have a constraint on the finish date and you have a fixed specification to bid against. How will your waterfall-loving competition bid? Again, ask yourself which proposal is going to sound more convincing to the uninitiated?

When people who run consulting businesses think very hard on this problem, most will come back and say, “Well, if I have to fix the price and the date and deliver that pile of scope in your spec, then I’ll do it for $[x] as long as you don’t change anything in the spec. If you change something then I’ll have to charge you more, but it will be on a case by case basis.” They’ll say this because they have to make payroll and they are trying to keep their staff happy. They’ll say it because they know the customer will change their mind because the spec is crap, so they’ll get to up the price anyway and it will be after they have gotten past the procurement people and are just dealing with the business people.

People define projects and bid them out because they want somebody else to be responsible. Procurement departments try to increase competition, squeeze prices down, and outsource as much risk as possible.

Is it any wonder that services firms developed ‘change management’ procedures in the 80’s and 90’s to deal with government and business procurement problems? Is it any wonder that the idea of dumbing down the roles and responsibilities and using ‘better’ processes and cheaper resources gained ground as boilerplate proposal content (if not real practice)?

The waterfall methodology was not created and does not survive today because it is a good approach to develop software. It was developed because it was a good approach to navigating a procurement minefield and winning software project contracts. Until Agile can find a way to win the procurement battle (or somehow change that game), waterfall methods will stick around.

– Tate Stuntz

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Agile

4 responses so far ↓

  • 1 MarcNext » Blog Archive » Testlinks voor 12-12-2007 // Dec 12, 2007 at 7:30 pm

    […] The Procurement Problem and Agile Methods – Projecten, fixed prices, Agile of waterval: een kritische blik. […]

  • 2 nma // Oct 1, 2010 at 6:57 am

    operating system problem

  • 3 Angry Dude // Sep 26, 2012 at 4:01 pm

    Federal procurement sets the stage for waterfall from the get go with it’s unfriendly approach to continuous improvement. That is – it’s OCI provisions (FAR Part 9.5).

    The idea that one company specifies the solution and another implements it may work for commodities, but is a disaster with custom software.

    See for a longer exploration of this issue.

  • 4 Tate // Oct 5, 2012 at 3:21 pm

    You are right on the money angry dude!

Leave a Comment