• Unicode verstehen
• Mastering UTF-8
• Text Inspector (UTF-8)
• IT Procurement
• Rsync über SSH
• Perl5-Objekte
• Tips für Web-Profis
• HTML-Primer
• HTML Primer
• Effizient Tippen
• Tipp-Trainer
• HTML Redirect Tool
• Mail URL Tool
• My Code
•  

• 

•  
• Homepage / Kontakt
• Impressum, Rechtshinweise
• Datenschutz
• Legal Notice

Agile IT Procurement

Agile - just another buzz word?

When dealing with software development, two sources helped me a lot: The Pragmatic Programmer and the Agile Manifesto.

Especially the second one, the Agile Manifesto, might be more relevant to software procurement than average IT buyers might think. Understanding the nature of post-waterfall software development projects is so helpful for understanding the supplier relationship and finding an appropriate negotiation style. Although most IT procurement managers do not know too much about software development, they should read the Manifesto and discuss it with IT stakeholders. Side effect: Some hardcore IT stakeholders will be amazed that their procurement person is interested in their world as well.

So what does it have to do with procurement? I would say it can help to shape the negotiation style and to set own expectations for the contracting part.

Negotiation Style

Some purchasers feel they are strong negotiators because they are hard negotiators. They can talk sellers to death and according to their own words, they can »squeeze« suppliers to get incredible discounts. I developed my doubts when learning from negotiation masters: They all taught listening and respectful collaboration rather than talking and demanding.

There might be places where »squeezing« practices still work, or let's say where good conditions are achieved despite of a »hard« negotiation style. Example: Buying consumables and mass-produced, over-supplied goods might work in any style. Putting producers of the same 8mm screws or 2mm sheet metal in competition is not too difficult, and whether you approach them aggressively or collaboratively might not make too much of a difference for the specific deal. But still: On the long run, it can pay back to establish a partnership by applying a collaborative win-win negotiation style, no matter how strong the buyer's position looks like.

Software & IT Service Contracting

To buy software and respective services, it helps to understand the impact of two (out of four) principles from the Agile Manifesto, where the authors have come to value:

Customer Collaboration	over	Contract Negotiation
Responding to Change	over	Following a Plan

Now this is from the view of a software developer. For the purchaser, the key to good negotiation is to understand what the people on the other side of the table want. Above two principles show that in today's software projects do not go well together with the desire to negotiate conditions for 100% agreed deliverables. Good suppliers want to make their customer happy on the long run by collaboration and by responding to the real needs - even if they change during the project. That is a good thing, but it also means that you cannot just specify what you want and ask for a pricing. That would make none of the involved parties happy:

• Users will find out what is missing (or turns out to be redundant) once they try out the software. They will continue to change their preferences with each new version. That is a good thing: Working with an early version of a software is different from judging about flow charts, screenshots, or mockups. Responding to early feedback from users is the key to efficient solutions.
• Business requirements change fast; often during a software project. That means that we need to be prepared to change objectives or directions while a project is ongoing.

It is not possible to frame a contract around things that you cannot know yet. Negotiating a contract with deliverables and a fixed price is useless. »Squeezing« the suppliers is either impossible or counter-productive: Good sales people will agree to everything. No need to be proud of price reductions through »squeezing«, because they are short term wins with high follow-up cost. Been there, done that, believe me. The real money is in the Change Requests. But just avoiding Change Requests and following the specs in a waterfall approach would mean you get what you ordered - but that might not be what you need. In reality the product in accordance with your specification might not be what the users were expecting. It might even no longer correspond to your updated requirements any more. (A lot of things can happen during the lifetime of a project.) That's to say: Just insisting on initially agreed specs does not sound like Return On Investment.

The following recommendations are based on personal experience:

• Don't contract features for money, but collaborate continously with the suppliers to get delivered what is needed at the best possible conditions.
• Buyer and Seller need each other's trust. For some of the »tough negotiators«, trust may sound as old-fashioned as their negotiation style is, but it is more important than ever. Of course we need to know whom to trust, and that requires a lot of experience, subject matter knowledge, and soft skills.
• Keep your initial requirements to that of a so-called Minimum Viable Product (MVP) and be open to change after each version. (A version means here the outcome of a very short development/test cycle, i.e. an iteration towards the product you need.
• Make sure you put a long-term rate card in your contract. At the end of the day you are buying the time of software experts. By the way: This is also very important in case you stick to the waterfall approach (contracting features for money), where you will end up with Change Requests that you will have to pay based on daily rates. Think long-term when negotiating the rate-card: It can include annual increases or, better, a to-be-specified cost-of-living index.

There are no silver bullets or very secret weapons, but indeed there are useful models, ideas and strategies to deal with software and IT service procurement in a more dynamic way. However: It does not help to recommend an approach before understanding what your business case is and - very important - what those on the other side of the table want and what they can agree to. That's to say:
Listen!