• Knowledge Management
• Wissensmanagement
• IT Procurement
• Unicode verstehen
• Text-Inspector (UTF-8)
• Mastering UTF-8
• Rsync über SSH
• Perl5-Objekte
• Tips für Web-Profis
• HTML-Primer
• HTML Primer
• Effizient Tippen
• Tipp-Trainer
• Lotus Notes alive

• My Code
• HTML Redirect Tool
• Mail URL Tool
•  

• 

•  
• Impressum, Rechtshinweise
• Datenschutz
• Legal Notice

Agile IT Procurement

Agile - just another buzz word?

Two impressive references that were guiding me when dealing with software development as a programmer and as an IT manager were the Pragmatic Programmer and the Agile Manifesto.

In my current job I deal rather with buying software, but the Agile Manifesto is still relevant. It helps understanding the nature of IT projects today and that is required for the respective contracting.

Negotiators

Some people 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. The funny part is that I had opportunties to learn from negotiation masters and they all teach listening and respectful collaboration rather than talking and demanding.

There are places where »squeezing« works or at least seems to yield results. Buying consumables and mass-produced, over-supplied goods for example works in any style. Putting producers of the same 8mm screws or 2mm AlMg3 sheet metal in competition is not too difficult. On the long run, however, the respectful listener will also here see commercial or risk level advantages - plus make the world a slightly better place.

Software & IT Service Contracting

To buy software and respective services, it is crucial 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 or seller. For procurement people 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 there is no room for negotiating a price for agreed deliverables. Sounds weird, but is a fact.

• Users start to understand what they need when they start using the first version of a software. And they will continue to change their opinion.
• Business requirements change fast today, while projects still take significant time. That means: We need to be prepared to change objectives or directions.

It is not possible to put in a contract what you do not know. 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. The real money is in the Change Requests. Avoiding Change Requests usually means getting delivered what had been specified, but that is most likely not what is needed.

Thus, my recommendations:

• Don't contract features for money, but collaborate continously with the supplier(s) to get delivered what is needed at the best possible price.
• Buyer and Seller need each other's trust. For some of the »tough negotiators«, trust may sound like a word as old-fashioned as their negotiation style, but it is more important than ever. Of course we need to know whom to trust, for which we, Buyers and Project Managers, need a lot of experience, subject matter knowledge, and soft skills.

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. However, it does not help to recommend an approach before understanding what those at the other side of the table wants and can agree to. That's to say: Listen!