August 2009
M T W T F S S
« Jul   Sep »
 12
3456789
10111213141516
17181920212223
24252627282930
31  
«  
  »

The Perils of Procurement

There’s kissing in the valley,
Thieving in the alley,
Fighting every inch of the way.
Trying to be tender
With somebody I remember
In a night that’s always brighter’n the day.
- SEVEN DAYS

Picture the scene

You work for a big organisation. You’ve initiated a new major WCM project. You’ve got your board approval, you’ve had your budget signed off, and you’ve a vague idea of what you want:  a friendly CMS, a decent Search Engine, something to handle User Generated Content and some kick-ass Analytics. You’ve got a team of pragmatic-developer-ninjas waiting in the wings to integrate them beautifully. You’re in a good place. Time to procure some products. That should be easy. Let’s start with a cartoon which I made using the wonderful Project Cartoon.

You don't want this to happen, do you?

You don't want this to happen, do you?

How Many Tenders?

So you need WCMS, Search, UGC and Analytics. We’re going to call these The Four Pillars for today. First question: How many RFIs/RFPs do you issue? Just the one so that a single vendor (or consortium) supplies all of the products? Or how about a single one with “Lots” allowing vendors to only respond to part of it? Or, on the other extreme, a separate RFP for each product? Some of you won’t have this choice as it is dictated by your procurement rules, but let’s pretend you do.

While each product certainly covers a Separate Concern of the site, the reality is that there will be a lot of integrating to do. The world doesn’t have mature enough standards to allow you to switch them in and out like the proverbial Lego blocks. The products will also certainly have large functionality overlaps. If you go for separate RFPs or split it into Lots, it is exceptionally important that you explicitly list the integration points between them. I’d suggest that WCMS and Search probably have the most integration points and should get special attention. User Generated Content/Social products often have widly different architectures and so should also get a lot of focus. They won’t all slot neatly into your solution in the same way. On the other hand, the major Analytics products all have the same basic architecture and so is, in my opinion, the one that is easiest to tender for in isolation. Because I am nice and want to help you all, I plan to write a followup blog post listing the most common integration points soon.

If each product is being selected in isolation, you need to be extremely careful. You could follow the selection and evaluation criteria by the book and end up with four products that are each “best of breed” and match your requirements wonderfully. But throw them into the same architecture diagram and they behave like four cats on heat. On the other hand, if you go for one process to select all the products, you could end up with a monster that you don’t really understand and that would need to be replaced in its entirety should one part of it become obsolete. I think its a fairly safe bet that you’d want to replace at least one of the Four Pillars within the next 2 or 3 years. You need to make very sure that this doesn’t mean you need to replace the other three. Finally, make sure your developer-ninjas have input into the selection criteria. You don’t want your team of C# developers to all have to rush to a COBOL training course.

Give a budget range. Seriously.

Janus Boye started a discussion about this on his blog entry CMS Selection: Reveal budget in the RFP? I’ll repeat the comment I left on his blog:

I’ve seen 2 RFPs in the last few months in which client didn’t specify a range and got something like this (I’m paraphrasing, of course):

2000 Ford Taurus SES – $2,482
1993 Toyota Camry LE – $3,582
2008 Lexus LS 600h L – $99,995
2002 Hyundai Sonata GLS – $4,300

They wanted to buy the Lexus, but their procurement was having none of it. They had to extend the RFP to attract more responses that allowed a “like for like” comparison. If think they’ve even had to go back to the Ford, Toyota and Hyundia salesman and ask them what they could do for more money … If the RFP had given a range (say $75,000 – $150,000) they’d have saved themselves a load of time and effort.

Also, if you have a weighted scoring matrix, make your selection criteria transparent so vendors allocate an appropriate amount of time to each section. Procurement like a fair fight. If they don’t think it’s fair, they might throw the whole thing back in your face.

Other Procurement Gotchas

The whole process can take a lot longer than you think. Many of the RFPs we respond to are extremely clear that they will never, under any circumstances, extend the deadline for submission. However, many of these delay the announced decision dates by weeks or even months. That’s not really fair now, is it. Give yourself enough time. Remember, the longer your RFP, the longer you’ll need to read and evaluate the submissions. In addition to procurement, include your legal department early too. Dotting i’s and crossing t’s isn’t as quick as it sounds.

Some clients I deal with have to go to procurement for everything. It seems a pity to go through a massive process to by a $99 Web Server Plugin. Make sure you know the thresholds so you can start the process in good time. I recently suggested to a client going through this that they buy all five options rather than going through procurement to select one. I was sort of joking and it probably isn’t legal, but the sad truth is that would be cheaper and all the vendors would be happy.

Something else I’ve seen a couple of times recently revolves around cross-country procurement. The rules in different countries are often different and, if you plan to use the software in multiple regions, you might need to go through “global procurement” or some equivalent. I still don’t really understand how to define when software is “used” (and so needs to be procured) in a region. If I have a server farm in country A and country B each hosting their respective country sites, then I’ll probably need to procure for both. But what if I have a single farm serving all coumtry sites? Or what if the whole shebang is *aaS hosted out of the Cayman islands? Bearing in mind you probably won’t know the architecture of the product when you issue the tender, it is even more important you understand the procurement rules.

Another gotcha I’ve seen a few times recently – falling foul of procurement’s “we’ve already got a Global Enterprise Unlimited Uberlicense for product X so best you used that instead”. Dilbert explains this better than I ever could:

Dilbert Procurement

Finally, make sure you cover license costs for development, staging and pre-production environments. And think about disaster recovery licenses and maintenance fees. Sometimes this isn’t as easy as it sounds as you haven’t procured all the products so probably don’t know your architecture yet. For example, having an Active-Active DR environment often means very different license costs from an Active-Passive.

My advice: involve procurement in the process early to ensure you understand the process. Although procurement exists to ensure you negotiate a good deal (which is great) in a fair, ethical manner (which is even more important) you need to make sure you don’t get hammered by a process that screws your plans or timelines. You’d be surprised how often software procurement is on the critical path and delays a project.

  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Digg
  • LinkedIn
  • StumbleUpon
  • Technorati
August 25th, 2009 | 865 comments | Tags: , , , , , | Category: Ramblings

865 comments to The Perils of Procurement