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?
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,300They 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:
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.
RSS Feed
Follow Me
My advice: Treat all vendors fair and equal, but make sure to have dialogue with the vendors, even before they submit their proposals. This could be done by allowing time for Q & A before they submit the proposal. In my experience you’ll get much better proposals as a result.
Also, negotiating price won’t take long, but getting all the terms and conditions sorted can be a lengthy process
In general, procurement is not the difficult part, implementation is.
Janus, would you recommend a single RFI/RFP for all the products, or split them? Or maybe single RFI and then decide on the RFP structure based on the responses? Procurement can be easy sometimes but you need to be careful, especially if you’re part of a very large, formal organisation.
I would not recommend a single RFI to rule them all. If you really need a new CMS, search engine, social software, analytics etc. at the same time, I would run them as separate project and ideally delay a few of them. Perhaps you could focus on CMS and then attack search next and in the mean time use Google Analytics while you figure out what you really mean by “social software”.
My concern is that if you do it all at once you will need a very lengthy evaluation process and end with a very expensive piece of software and a very risky implementation with many unknowns.
Now this sounds very sensible. However, none of my clients would be prepared to pick product A, implement something, pick B, integrate it and so on. I wish they would though.
Otherwise if you put up seperate projects the solution gets even more complex, because of massive integration work and API hassle. You rely on more unknown variables and vendors, which could lead to an unsatisified state / more islands in the end. Google Analytics could be a quick win but there is always the trust problem with Google.
DR aka disaster recovery, licenses are the most hidden of all costs. usually not included in RFP and only found later in the project when the architecture is laid out and you realise that you need 15 more licenses.
As for integration, i have to say that most of my experience with different vendors integration was not paved with gold, currently i am suffering from an oracle SOA to Java integration issues which should be a breeze, shouldn’t it?
Yep. Should be a breeze. Just like all those RedDot -> Vignette migrations you’re going to be doing quite soon if the recent Earnings Call announcement is anything to go by:
From here:
http://seekingalpha.com/article/157446-open-text-corporation-f4q09-qtr-end-06-30-2009-earnings-call-transcript?source=portfolio_wl&page=5
Within the WCM market, all of the consolidation & OEM deals has left many of the vendors with a pretty hefty SKU list. While there are some great connectors, widgets, SaaS offerings, etc. on there, they aren’t all required for the initial launch.
We caution customers against buying up the whole product suite right away. There’s no reason to procure shelfware and pay maintenance on an item that may not be implemented for another 1 to 2 years. Yet another reason not to go into a WCM selection process without having a clear multi-year implementation roadmap and know how the vendor maps to your business requirements.
Agree. I hate shelfware. Here’s a sad tale: I’ve got a client (they might be reading this) that is currently paying maintenance for a product that they’ve bought but cannot currently use due to version incompatibilities. Do you think you should start paying your maintenance from the time you purchases the software, or from the time you actually install and use the thing?
Clients need a strategic approach to procurement and to allow sufficient budgets (and contingency) to cater for *all* the licenses and costs, for each environment, each module etc. These costs quickly monut up!
Another gotcha is annual support costs which are usually based on the product list price and not the price you paid! And sometimes the first year support *isn’t* included in the cost of the licence…
Interesting to see the link re: migrating from RedDot to Vignette, can’t see it happening or being an easy sell for many of our customers to be honest.
So do you think it is reasonable to expect to understand your solution architecture fully (and therefore all the licenses you require) when you’re deciding which product to use? In your experience, does the total license cost typically stay where was it was doing RFP stage, or change once your system is fully designed?
When you’re down to a shortlist ( or the last two solutions) I would be looking at a ‘sizing’ exercise to determine what specific architecture would be sufficient for their needs, on a long list you don’t have the luxury of being able to do that! This will require some negotiation on pricing to establish at the outset what would happen in case you needed more servers/environments/sites/users (which you will need to do at some stage in the CMS lifetime).
This licence figure doesn’t usually change, unless there is a significant change in requirements! Stress testing can reveal scalability issues with some implementations but this isn’t usually down to the product and can fixed by optimising code, databases or cacheing etc.
Excellent post…. agree with everything and love the cartoons
“buy all five options rather than going through procurement to select one…………….. but the sad truth is that would be cheaper and all the vendors would be happy.”
- a question then for the procurement dept. What should be the criteria be to undertake a full RFP process so they can add value
[...] Perils of Procurements by Jon Marks from LBi. [...]
[...] Content Management RFPs will continue to be liberally strewn hither and yon like confetti at a WASP wedding, with zero regard for their efficacy or otherwise. [...]
[...] Perils of Procurements by Jon Marks from LBi. [...]
[...] http://jonontech.com/2009/08/25/the-perils-of-procurement/ [...]
Definitely consider that which you said. Your
favorite justification appeared to be at the net the simplest thing to keep in mind of.
I say to you, I certainly get irked while other folks think about worries
that they just don’t recognise about. You managed to hit the nail upon the
top and defined out the whole thing without having side effect ,
folks can take a signal. Will probably be again to get more.
Thanks
Here is my webpage: ways to earn money at home
[...] Perils of Procurements by Jon Marks from LBi. [...]
However, each can be traced with a deficiency the actual brain. There a lot of
more undiscovered benefits of human hgh products. genf20 is regarded as the well organized anti-aging vitamin supplements.
Back in the day, men actually even tied weights to their penises inside hopes to stretch it out.
The choice of medical set up is highly recommended and instructions must be used seriously.
All you need are the 2 hands and some lubrication achieve
effective penis enlarging. Traction devices have
been designed with regard to the Proextender that occasion is guaranteed to lengthen the penis.
[...] The Perils of Procurement | Jon On Tech – 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 … Categories Uncategorized Previous: Php Web Hosting Free Next: Web Server Pricing [...]
Me gusta disfrutar y visitar blogs, aprecio mucho el contenido, el trabajo y el tiempo que ponéis en vuestros post. Buscando en Yahoo he encontrado tu web. Ya he disfrutado de varios publicaciones, pero este es muy ameno, es unos de mis temas favoritos, y por su calidad he disfrutado mucho. He puesto tu web en mis favoritos pues creo que todos tus posts son interesantes y seguro que voy a pasar muy buenos momentos leyendolos.
serum bioeffect https://www.lesecretdumarais.com/es/bioeffect/2359-bioeffect-egf-eye-serum-5694230071708.html
Me ha encantado vuestro post y me ha sabido a poco pero ya sabeis lo que dice el dicho “si lo bueno es breve es dos veces bueno”. Me gustara volver a leeros de nuevo.
Saludos
dejar de fumar malaga http://stopaltabacomalaga.com/terapias/terapia-laser-dejar-de-fumar
realistic vagina
homemade vagina http://www5.goteborg.se/prod/SocialResurs/Info/Utbildning.nsf/f79078fb3dc8a25bc1256f62004cb86d/0986fd548394c386c1257f5b0010d138!OpenDocument
He leido vuestro post con mucha atecion y me ha parecido interesente ademas de facil de leer. No dejeis de cuidar este blog es bueno.
Saludos
corte-por-laser-madrid http://www.corte-por-laser-madrid.com/servicio/terminado-piezas.html