Comments on: The Perils of Procurement http://jonontech.com/2009/08/25/the-perils-of-procurement/ Just a nerd trying to save the publishing industry. Again. Fri, 11 May 2012 17:43:33 +0000 hourly 1 http://wordpress.org/?v=3.3 By: ITSM Antipodean Podcast ~ Episode 17 | Macanta http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-317382 ITSM Antipodean Podcast ~ Episode 17 | Macanta Sun, 06 May 2012 23:37:46 +0000 http://jonontech.com/?p=1077#comment-317382 [...] http://jonontech.com/2009/08/25/the-perils-of-procurement/ [...] [...] http://jonontech.com/2009/08/25/the-perils-of-procurement/ [...]

]]> By: Ways of improving checklist RFPs | J. Boye http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-193738 Ways of improving checklist RFPs | J. Boye Mon, 10 Oct 2011 16:00:20 +0000 http://jonontech.com/?p=1077#comment-193738 [...] Perils of Procurements by Jon Marks from LBi. [...] [...] Perils of Procurements by Jon Marks from LBi. [...]

]]> By: Bottom 10 Predictions for 2010 « The CMS Curmudgeon http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-5887 Bottom 10 Predictions for 2010 « The CMS Curmudgeon Sat, 09 Jan 2010 22:44:55 +0000 http://jonontech.com/?p=1077#comment-5887 [...] 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.  [...] [...] 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.  [...]

]]> By: J. Boye | Ways of improving checklist RFPs http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-5283 J. Boye | Ways of improving checklist RFPs Sat, 19 Dec 2009 23:28:20 +0000 http://jonontech.com/?p=1077#comment-5283 [...] Perils of Procurements by Jon Marks from LBi. [...] [...] Perils of Procurements by Jon Marks from LBi. [...]

]]> By: Zahoor Hussain http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2618 Zahoor Hussain Sun, 30 Aug 2009 10:10:41 +0000 http://jonontech.com/?p=1077#comment-2618 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. 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.

]]> By: Piero Tintori http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2609 Piero Tintori Sat, 29 Aug 2009 09:26:58 +0000 http://jonontech.com/?p=1077#comment-2609 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 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

]]> By: Jon Marks http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2606 Jon Marks Fri, 28 Aug 2009 19:49:13 +0000 http://jonontech.com/?p=1077#comment-2606 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? 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?

]]> By: Jon Marks http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2605 Jon Marks Fri, 28 Aug 2009 19:45:53 +0000 http://jonontech.com/?p=1077#comment-2605 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? 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?

]]> By: Zahoor Hussain http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2591 Zahoor Hussain Thu, 27 Aug 2009 17:47:04 +0000 http://jonontech.com/?p=1077#comment-2591 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. 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.

]]> By: Tony Bailey http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2590 Tony Bailey Thu, 27 Aug 2009 14:15:42 +0000 http://jonontech.com/?p=1077#comment-2590 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. 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.

]]> By: Jon Marks http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2589 Jon Marks Thu, 27 Aug 2009 13:40:07 +0000 http://jonontech.com/?p=1077#comment-2589 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: <blockquote cite="John Shackleton ">Actually, it probably be the other way, Paul, where we would migrate the RedDot to the Vignette platform. We will be showing a detailed road map at the conference in October, so I think you'll get a good clear. But it looks pretty interesting, the way that things are shaping up.</blockquote> From here: http://seekingalpha.com/article/157446-open-text-corporation-f4q09-qtr-end-06-30-2009-earnings-call-transcript?source=portfolio_wl&page=5 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:

Actually, it probably be the other way, Paul, where we would migrate the RedDot to the Vignette platform. We will be showing a detailed road map at the conference in October, so I think you’ll get a good clear. But it looks pretty interesting, the way that things are shaping up.

From here:
http://seekingalpha.com/article/157446-open-text-corporation-f4q09-qtr-end-06-30-2009-earnings-call-transcript?source=portfolio_wl&page=5

]]> By: Yuval Ararat http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2588 Yuval Ararat Thu, 27 Aug 2009 13:28:47 +0000 http://jonontech.com/?p=1077#comment-2588 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? 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?

]]> By: Jon Marks http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2573 Jon Marks Wed, 26 Aug 2009 11:26:05 +0000 http://jonontech.com/?p=1077#comment-2573 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. 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.

]]> By: Jurek Hille http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2572 Jurek Hille Wed, 26 Aug 2009 09:51:27 +0000 http://jonontech.com/?p=1077#comment-2572 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. 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.

]]> By: Janus Boye http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2569 Janus Boye Tue, 25 Aug 2009 20:44:56 +0000 http://jonontech.com/?p=1077#comment-2569 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. 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.

]]> By: Jon Marks http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2567 Jon Marks Tue, 25 Aug 2009 20:06:35 +0000 http://jonontech.com/?p=1077#comment-2567 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. 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.

]]> By: Janus Boye http://jonontech.com/2009/08/25/the-perils-of-procurement/#comment-2566 Janus Boye Tue, 25 Aug 2009 19:54:26 +0000 http://jonontech.com/?p=1077#comment-2566 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. 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.

]]>