Technology procurement is my primary area of commodity expertise.  When I'm at industry events, like ISM, folks sometimes ask me, "what's so special about technology procurement?"  Among other things, my answer always includes a discussion of risk. Technology procurement is just downright risk-intensive and requires that procurement folks step up their game.  It's unlike any other commodity, and takes a special type of procurement pro to be successful at.

Look at it this way. Let's say that your company decides it's going to build a small office building, maybe about $7 million dollars in cost. In many ways, that's very similar to implementing an ERP system, like SAP or Oracle--where you're going to pay about the same amount in software license fees, implementation costs (external and internal resources), maintenance and support, training, and the like.

For now, let's focus on the office building... Just imagine the team and process involved. Certainly, you'll need an architect to flesh out your requirements right down to the last square inch. You'll also need a space planner to design the interior. You'll need site plans, floor plans, and engineering drawings. Of course, all of this needs to be within code and approved by an inspector.  All of the plans and drawings will be an attachment to the future contract with the builder.  You'll select a builder through a rigorous RFP process and likely develop a contract with very, very detailed requirements and detailed payment schedules (with holdbacks and liquidated damages). The parties spend a significant amount of time negotiating the contract. I've seen 50+ page contracts for construction services to build a relatively small building. During the building process, there is intense day-by-day project and budget management. Change orders are clearly documented and nothing happens unless both parties are engaged. Inspectors come and go, and where inspections reveal deficiencies, the building contractor is under intense scrutiny to fix them as soon as possible. Otherwise, not much else can move forward. Finally, when the building is at completion, there's a punch list that the building contractor must complete before the building is accepted and an inspector issues a certificate of occupancy. Frequently, a customer won't accept a building and a contractor will be out a big chunk of money until the certificate of occupany is issued. Imagine the detailed contract documents that paper all of this. If you don't source construction services, you may be familar with how detailed and intense the procurement process is if you've ever built a house... In any case, trust me, it's a rigorous procurement and contracting process.

Now compare the above with a typical software license purchasing scenario for an ERP system like SAP or Oracle. In most cases, your customers' requirements will be ill-defined, so the resulting RFP isn't very substantial. The RFP process is relatively rushed, because your customers want to get this project started ASAP. The ERP account execs may be running amuck during the RFP process, influencing your customers. The vendors want to do the deal on their paper, which doesn't seem very comprehensive. The implementation services are also ill-defined and seem more time and materials based than deliverables based. For the license agreement and the services agreement, the vendor doesn't want to commit to anything (in fact, they disclaim even remotely possible UCC warranties) and the contract likely explicity says that they don't guarantee their software will work. They howl about revenue recognition when you want holdbacks and liquidated damages for non-performance. They don't want to give on acceptance periods, and want you to basically take their software as-is. During implementation, project management on the vendor side is spotty. Change orders are typically verbal and rarely documented. Scope creep and budget overruns become major issues. Both the customer and the vendor try to get the system slammed in so they can declare success. Users are bent out of shape when the system is finally delivered.

So why is the process between procuring construction services and technology so different? Particularly, when the process of "constructing" a building and "constructing" a system are quite similar?

It boils down to process rigor. People just accept that the procurement of construction services is going to be a detailed and very thorough process. Imagine a building contractor not agreeing in their contract that the building they will construct will habitable. That contractor would quickly go out of business because that position would be unacceptable to customers. But that's what a lot of software license agreements essentially say--vendors don't agree that their software will meet your needs (software vendors typically disclaim the UCC warranty of fitness for particular purpose).

When it comes to IT and technology, money doesn't seem to be an issue, and customers pretty much can get what they think they want. And vendors know that. That's why technology procurement is so risk-intensive--it doesn't (in many cases) have the same process rigor that procuring construction services does.

The crux is creating a process, mindset, and culture around technology procurement that your customers become familiar and comfortable with. As procurement pros, that means it will take you purposeful effort and time to make that culture happen.  You can't slam-dunk it either.  It needs to be slow, but steady, progress.  You need to work closely with your customers so they see the value of a more disciplined process from a "what's in it for them" perspective (one example is a software system that works).

You also need to work with your vendors so they also understand the value. And that's where the whole "vendor management" philosophy comes into play with your technology vendors. Unlike the construction industry, you'll need to invest much more time developing your technology vendors and working with them to create coherent and process-based procurement.  Unless you (we) do these things, technology procurement will continue to be the most risk-intensive commodity of all the commodites that procurement pros source.  I've been successful in making technology procurement less risk-intensive, but I can tell you that it does take a significant investment in effort and time.  If you're a procurement pro that likes commodities that are cut and dry, technology procurement isn't for you.