{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

When a retailer or brand decides it's time to replatform their ecommerce website, many will opt to embark on an ITT process (Invitation to Tender).

This can involve two or three distinct phases: RFI (Request for Information) and RFP (Request for Proposal).

The RFP is often huge: I've waded through several that have made my eyes bleed due to their complexity, all the time thinking that the poor souls that have slaved over the incredibly detailed document have somewhat missed the point.

My question is, therefore: Is the RFP an effective mechanism that best serves the involved parties?

I've felt for a long time that perhaps it is not, and in 2010 Forrester research produced a paper entitled ‘A Scenario Based Ecommerce Technology Evaluation Process’ on the subject suggesting there might just be a better way of going about things. 

Background

Over the course of the last year or so I've had conversations with several ecommerce agency owners who have talked to me about issues they have with the majority of RFP's they receive, namely:

  • Overly prescriptive nature: 'the system must work exactly like this…"
  • Homogenisation of technology: 'the current system works in this way, the new system must replicate the way in which the current system works'.
  • Overly detailed, rigid descriptions of every single feature.
  • Conversely, not enough information on others.
  • Little or poor attempt to describe the business problem, therefore doesn't allow a respondent to show how they can address it.


In an interview with The Register, Ian Birdsey of Pinsent Masons, the law firm behind Out-Law.com, said that organisations often make the mistake of trying to replicate outdated or inefficient processes and work methods.

He says organisations that are overly prescriptive in their briefs to suppliers risk not getting their desired outcomes when updating IT systems.

On a lot of levels it does not make sense to replicate old methods and processes with a new system. IT customers should challenge existing processes to determine whether they are best for them, otherwise the benefit of changing IT systems can often be diluted or lost altogether. Smart organisations use transformational IT projects to introduce more efficient and effective business process change.

Not everyone dislikes, however. Bob Curran of Buy4Now tells me he generally likes them and has historically done well via this format. In one instance recently Buy4Now managed to pip one of the 'big three' and solve a monster problem for a large retailer.

In light of this, I think a distinction needs to be made between a good and a bad RFP.

Bad:

  • Prescriptive.
  • Kitchen sink approach.
  • Overly detailed descriptions of features.
  • Not enough information on certain aspects.
  • Online tender.
  • Fixed format for responses.
  • Inability to engage and ask questions.
  • Poor understanding or communication of business issues.
  • Asks the 'wrong' questions.


Good:

  • Non-prescriptive.
  • Not fixated on rigid processes or features.
  • Focused on achieving outcomes.
  • Open format for responses.
  • Ability for respondent to formulate and ask questions.
  • Asks well framed questions.
  • Good understanding and communication of business issues.

Prescriptive and homogenisation aspects can be viewed together. Whilst a business may have business issues that are causing it to replatform it may wish for the bulk of its operations to remain the same and so require any new technology to facilitate certain processes.

However, specifying that something must work in a very specific way might rule out another very good option, or mean costs are escalated unnecessarily through customisation work.

Specifying every single requirement in detail is a monstrous task and a dangerous one too. If a vendor or ecommerce agency follows this to the letter, which is surely the intention, then nothing can be omitted or incorrectly specified. There is no room for error or interpretation with this ‘everything but the kitchen sink’ approach.

Those compiling the RFP may be unaware how different ecommerce platforms operate and it's very difficult for them to fit the platform to the process (or vice-versa). The more complex the business, the harder this becomes. Sometimes the only way to describe a desired feature or process is by referencing the way things work currently.

Because a retailer (and most consultants) most likely won't have perfect knowledge of every platform, vendor, or agency, it's incredibly difficult for them to say what's going to be best for them, and it is, therefore, nigh on impossible for them to know what to ask for – this is a really key point.

It's very possible for the client to omit features from a spec, which can cause major relationship problems down the line.

Maxwell Lamb, co-founder of ecommerce agency blubolt says:

This is a harbinger of doom - the number of times we've seen RFPs with 2000 one-line rows in an excel spreadsheet with "Yes" and "No" with indication of importance in columns, with a single row that just says B2B.

A better way?

Firstly, replicating a feature should not be confused with facilitating an outcome or a process - there is a huge difference.

Forrester recommends the formulation of 3 to 4 well planned scenarios that encompass all touch points of a business.
Personally, during my time as an intermediary between brands and agencies I found a non-prescriptive approach worked very well for my SME and midmarket clients.
My favoured process took a broad, outline approach to initial scoping, helping the client to take a step back and think about the customer, the administrator, the marketer and the customer service people, for example.

I would encourage them to come up with a short scenario that encapsulates the day to day workings of each touch point. All subsequent agency demo's and conversations with the retailer or brand are then firmly focused on the key issues, whilst retaining individuality and allowing creativity.

One well thought out scenario can encompass a large number of processes and required features, and allow freedom of expression in each response. This approach allows the retailer to gain a much better insight into an agency or platform vendor too, especially valuable in instances where agencies or SI's all use the same platform.

Here's a great example of a fictional multichannel scenario I really like, adapted from the HBR:

Amy, age 28, needs resort wear for a Caribbean vacation. She starts shopping from her couch by emailing customer services at Danella, the retailer where she bought two outfits the previous month. The representative recommends several items, emailing a link to superimposed photos of them on Amy’s avatar in the member’s area. Amy buys one item from Danella online and then drives to the Danella store near her to collect her order and try on the other in-stock items she likes.

As Amy enters Danella, a sales associate walks her to a dressing room stocked with her online selections—plus some matching shoes and a cocktail dress. She likes the shoes, the dress is daring and expensive, so Amy sends a video to three stylish friends, asking for their opinion. The responses come quickly: three thumbs down. She collects the items she wants, and checks out with her smartphone.

As she heads for the door, a life-size screen recognizes her and shows a special offer on an irresistible summer-weight top. Amy quickly checks her budget online, smiles, and uses her phone to scan the customized Quick Response code on the screen. The item will be shipped from another Danella store to her home tomorrow.


Can lessons be learned from the persona model pioneered by the Eisenberg brothers to understand and influence motivation in a purchasing situation? I think a similar approach will prove invaluable here.

I think written scenarios can work, although Max suggests otherwise:

I would actually argue that the assertion in the Forrester report that stipulates ‘Communicate these scenarios to the vendors in written form’ is wrong. I think it would be better if vendors were only told general areas in advance of an interactive session - far more effective if you put them on the spot and see how well they understand their own tools, and how to use them in context.


To wrap up…

Storytelling is the future.

More and more agencies and vendors are deciding not to respond to hugely time consuming, prescriptive RFP documents and so retailers, brands and any consultants brought in to help need to show an acute awareness of the marketplace so as not to rule out perfectly suited options. 

There’s a place for tiny detail, but leave this for the functional spec.

A more open, flexible approach is better for all concerned and will add tons of value. It's far more inclusive, prevents homogenisation of technology, and allows technology and service remit to serve the business needs as opposed to mimicking an incumbent setup that's being replaced.

The playing field should not be levelled, and the concept of comparing like for like should be banished. Rather than the technology per se it's more often the capabilities of a provider and after-sales service that are the deciding factors where selection is concerned. These should be allowed to be fully demonstrated and not stifled.

Detail should be arrived at, not started with – we have BDD (Behavioural Driven Development), let’s start utilising BDS (Behavioural Driven Scoping).

Avatar-blank-50x50

Published 18 February, 2013 by Mark Bolitho

Mark Bolitho is New Business Director Ecommerce at more2 and a contributor to Econsultancy. You can chat with Mark on Twitter or find him on LinkedIn or Google Plus.

3 more posts from this author

Comments (43)

Comment
No-profile-pic
Save or Cancel
Avatar-blank-50x50

Chris Jones

Superb post! I'd add a few more points to this.

Firstly, those 1000 item RFPs get responded to line by line. And the responses will inevitably say that solution A meets 981 of them, solution B meets 982 of them. You are no wiser. Most reasonable platforms do most things reasonably. Choosing in this way is like choosing coke or pepsi.

Secondly, such a process fails to answer the fundamental question: why do you want to replatform? This *should* be the focus of the document - the platform must deliver the things that motivated the change. It is these criteria that you will really evaluate on.

Thirdly such RFPs don't focus on the two or three crucial things that make your business unique. To pick up the example, "B2B" is a meaningless one-liner, but if you then specify that each customer must see unique customer-specific prices on the website based on a contract price, then you are focussing on a crucial difference where off-the-shelf won't cut it.

Lastly, and most importantly, most people don't want to buy a platform - they want to buy a solution. This means technology and implementation partner *together*. Always do an RFP for both technology and implementation partner combined, and focus on the implementation journey as much as the technology itself.

about 3 years ago

Avatar-blank-50x50

Mathias Burmeister

I used to work in Bid Management and you make a valid point - in most cases the RFPs we received were so over-detailed and unnecessarily complex that not only did they miss their point but they also wasted a lot of time. We (those responding to the RFPs) would have to decipher the documents, request clarifications, wait for amended documents to be sent out, make further clarifications and eventually ask for an extension to the deadline as we spent 60% of the time trying to find out what it is that the customers actually want out of the proposal - and most of the time they didn't even know it themselves when submitting their RFPs to us.

about 3 years ago

Dan Coleman

Dan Coleman, eCommerce Technology Expert at Exceptional Commerce Ltd

Interesting article Mark, and I do like the idea of using more scenario based stuff but in most cases for me this would need to compliment a decent RFP. But then I don't do the prescriptive 2000 rows in excel thing either.

To me it's like a CV - it's there to get you to the interview but beyond that it's about finding if we'll work together to deliver a better project than supplier B or C. Scenario based could be very beneficial here.

about 3 years ago

Avatar-blank-50x50

Philip Holmes, Managing Director at Castlemead Consulting Limited

I think this is a great article and one that highlights a problem I often see. Businesses tend to know when they need a lawyer or a solicitor to help them out with some legal issues. They know that they need to employ an accountant to help out with their annual accounts and returns and also know when looking for a new office or HQ that a firm of surveyors is often in order. The point I am trying to make here is that a significant number of business still think they can embark on a large procurement exercise without the assistance of a procurement professional. "...it can't be that hard!!", "...we can download an RFP template and just send it to three suppliers". Unfortunately it doesn't work that way and can lead to the problems that this article highlights which is RFP documents that are not fit for purpose and leave both the buy-side and sell-side with problems. So for me the message is simple. If in doubt about spending a significant amount of your company's hard earned money, it pays to employ someone who knows just how to do that. He (or she) will have the letters MCIPS or FCIPS after their name. He (or she) will not be doing this for the first time ...

about 3 years ago

Richard Conyard

Richard Conyard, CIO at Red Ant

Great article, the RFP is an outmoded method for clients to get best value and suppliers to deliver it. Working as it does from the principles of least trust is hardly the best way to build an on-going relationship.

about 3 years ago

David Williams

David Williams, Director of Online EMEA at Deckers LtdEnterprise

Surely it sits somewhere inbetween? from being on the client side here (everyone else here seems to be consultant or agency), one reason why RFPs tend to be restrictive in answers is because in my experience, if you don't give some structure and limitation to answers, it's sometimes seen as an opportunity to 'cut and paste' sales blurb into answers - similar to politicians not answering the questions directly that are placed.

I find it useful at least to break down the responses to 1. what's part of the solution 2. what needs customization 3. what's in the pipeline. Lots of 3s and most tenders will be a non-starter. The level of integrations needed cannot be underestimated either.

Equally, going down the thousands of yes/no answers route provides no help either as has been stated, and I'd equally question that if things are that rigid, the problems might be closer to home.

From a client side point of view, I think that the scenario idea is an excellent one, as long as it is allied to a realistic expectations of each business - no point talking about click and collect if you don't have the ability to look up inventory instore. it needs to be realistic.

Finally, as Chris mentions the key question is 'why do you want to replatform' and that should be the fundamental question that any client should ask itself - sometimes the questions are closer to home, but it should be aligned to a longer term strategy, dissatisfaction with the existing platform (we know who they all are) should not be a reason in itself.

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

@ Chris, thanks. Yes, your last point is key - I think it's really important to allow those pitching freedom to express themselves.

@ Matthias: yes, resource will dictate. Many take the view, rightly IMO, that time is better spent looking after clients.

@ Dan: I think as long as it ticks the 'Good' boxes then it will be fit for purpose. Your CV analogy is spot on, and that's one of my key points but from the other way around. An agency may rule itself out when faced with a 75-page document that is going to tie it up for a serious amount of time.

@ Philip: I take your point, but nobody understands the day-to-day ops of an organisation better than those within it. It's not a difficult task to write an account of 'a day in the life of' those within the company.

@ Richard: Max's point about putting people on the spot is interesting. There will be immediate testing of a relationship where a bargaining takes place regarding changing software to fit processes or the other way around.

Thanks all, good points.

about 3 years ago

Avatar-blank-50x50

Kit Hunwicks, Account Director at Proteus

I was once sent an RFP (admittedly, not for an ecommerce site) that had 2 pages of introduction to the organisation and brand, then simply said:

"Young, friendly funky charity needs a new website for £XXk. You up for it?"

It was great.

about 3 years ago

Avatar-blank-50x50

Matt Isaacs, Senior Ecommerce Manager at Perricone MD

Scenario work is nothing new in software development; the problem is that so many companies fail to understand or utilise SSADM in any form.

Even before engaging in scenario work, you should look at a simple PACT analysis: People, Activities, Context, Technology (technology is not often necessary at this point yet unless there is existing tech you can't replace).

From this point onwards you can build the scenarios outs.

The requirements document should still be a key part of any project. The problem is that it should not be written at the beginning and should be fluid (as any user-centric design methodology allows).

about 3 years ago

Pete Williams

Pete Williams, Managing Director at Gibe Digital

having worked on both sides of the fence the issue for the client is a bit like choosing an accountant or any other specialist where there isn't an in house expert, trust. If you don't really understand what you want, it's really hard to explain to an agency without going into detail your ideas, rather than giving an overall view which you hope an agency doesn't take the mick out of. I really liked the imagined shopping experience as a way for a client to express their desire for an overall solution. Budget is obviously an other issue but perhaps for another time?

about 3 years ago

Avatar-blank-50x50

Nick Grant

Excellent post. The distinction between ITT and RFP is critical. In approaching any consultancy for genuine proposals (in the plural) the client should be looking for fresh ideas, new and better solutions, more productive value for money. Consultants have experience of the many, clients of the few. Why focus everything on the lowest bidder, when publishing the budget and asking "What do I get for that?" generates unique problem solving answers. Too much of prevailing procurement practice wastes time, funding and effectiveness.

about 3 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

If I as buyer have worked hard to make my eCommerce site 'work'_ with UI tweaks and A/B analysis and etc - it will be hard to not require that the new platform looks pretty much like the existing one does now to the end user.

So hard to follow the advice above:
> Overly detailed descriptions of features.

But actually in many ways there is a parallel here to the world of software development: Waterfall planning versus Agile.

RFP is like the Waterfall approach (Jonny above used the SSADM jargon - which is jargon for the waterfall approach).

Everthing has to be specified and documented before the project starts. The users/buyers are making inputs into specs for something they can't see/touch yet; so the project is built to spec and now at last users get their hands on it and ...oh dear ... realise a whole bunch of things they wish they'd spec'ed differently..too late!

Middle men are rife: user/buyers pass info to spec writers/purchasing guys: whio pass RFPs that often get responded to by middle-men at the supplier's side!

Versus Agile software development - the users/buyers only spec up what they want next - in the next 1 or 3 week cycle. So every cycle that is delivered; they get to see it and use it and are thus better placed to spec up the next piece they need in a way that will be usable.
Middle-men are avoided: users talks directly and regularly to the developer/designer.

The latter approach requires close working and trust between user/buyer and supplier :<)

Nick's comment is scary:
> If you don't really understand what you want, it's really hard to explain to an agency without going into detail your ideas

Somehow the buyer has to increase their understanding... else no process for getting pricing will be effective!

about 3 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

> Sometimes the only way to describe a desired feature or process is by referencing the way things work currently.

Maybe that is the solution: the RFP can be 99% defined by pointing to the current site: eg

* The current site features look like this: www.company.com
* The things we want to improve are
- - A,B C

Come show us an existing client-site you have built that is close to the above: and be ready to show us workflow by workflow how it compares: and how it's better! And what you'll need to tweak

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

@ Deri: thanks for your comments, good points.

I think openness is a key point for me. The 'best' RFP I think I've seen gave a mini scenario for the key features - 'our admin needs to...', 'the customer needs to...' etc, and openly invited suggestions as to how this might be improved.

I'm not suggesting for one minute that detail should be omitted from the process, I just feel that piling it all up front doesn't help anyone.

Personally, I like agile but I'm not sure how many PM's do! Some of the agencies I used last year ran a mix of the 2 pretty well.

I think Nick's comment shows how hard it can be for a client to trust an agency to do the right thing sometimes, which really highlights the need to involve the right people with the right insight in the process on both sides initially.
This in itself is a good reason not to be prescriptive and to encourage individuality and creativity early on.

about 3 years ago

Avatar-blank-50x50

Matt Isaacs, Senior Ecommerce Manager at Perricone MD

I think Agile versus Waterfall is dependant on the project itself.

We recently made a platform migration and decided used a mix of both. The initial project, of course, was not suited to to an Agile methodology; this was one large release. This still involved the scenario work as above and the huge requirements list that nobody likes, but without the requirements document we would be in huge danger of missing an awful lot of important detail. This document should be part of the process WITH the agency though, not what you present TO the agency.

However, for the majority of new functionality, which includes a lot of design changes, we have taken an Agile approach, not just for the reasons that Deri mentioned above, but also being a very small team its a lot safer to test little pockets of functionality versus multiple functions that can all affect each other.

And then, as Deri said, through this testing process, you discover elements that effect functions in the next sprints.

I realise that this has maybe gone a bit off topic.

All of this can be easily solved though if agencies made these processes - like scenario work - more readily available to companies, BEFORE they get to the stage of going to tender. Which could double as a nice bit of content marketing to boot...

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Mark,

>> 'our admin needs to...', 'the customer needs to...' ]

That is the makings of what in agile development terms is called a ‘user story’, except that in a story the benefit is implicit. The received wisdom on agile stories is; if there is no benefit, why are we asking for it? They are difficult to write well as they are prescriptive, detailing benefit, stakeholder and required functionality.

We wrote a little description recently, on what stories are and their value in agile process

http://bit.ly/XTs8Qu

Your article is good and you make some interesting points. But I’m going to cut against the grain and say that you dismiss a very important & valuable part of the standard RFP process. I’m also going to stick my neck out and say that the ecommerce vendor selection process should include other very important process considerations that you have in part conflated and in part missed completely. Sorry!

The important part of a typical RFP you dismiss, that IMHO does add value, is the standard / core functionality comparison that you refer to. In your example you are comparing ecommerce functionality. In our software, Blaze, we have a bunch of 'core' ecommerce functionality and a buyer should be able to compare like for like between products, as far as possible. Core functionality will represent a high proportion of what they use, as ecommerce design patterns are well established, on the whole. Unfortunately, because Blaze has lots of functionality this does extend to hundreds of features that already exist. It would be remiss not to document that, compare it to what the client had, and what other vendors had as ‘core’. We are not talking about mickey mouse software here, hundreds of features and different software vendor’s products at different stages in the development cycle. The difference in development cost could be very expensive indeed if not a starting point for an ‘apples for apples’ comparison.

When I say ‘as far as possible’ I mean that if you are dealing with developers who can evolve the software they will be able to extend that existing functionality in any way and develop new functionality around it, to meet unique or evolving stakeholder requirements - typically representing 20 to 30% of an ecommerce development. I can understand your point if you are asking a marketing agency they won’t be able to do that themselves, which inflates the importance of the core functionality part of the RFP and the agency relationship with the originators of the software, or competent developers. For me this is where the greatest risk in this process lies, the purchaser understanding the difference between development and design and implementation and the inherent complexity of it.

The additional, important consideration I think you should add to this piece is how you approach what is not ‘core’ from a requirement development and implementation perspective, as well as any modifications to existing functionality. For that I’m going to say the elephant is the room (or missing from your RFP appraisal) is developer process. Far and away the best in my experience, for the type of development and use case you describe is ‘Agile’ (we Practice SCRUM and XP at www.theByte9.com). For everything that requires development (modification, new functionality, systems integration etc) the RFP should focus solely on how the developer would approach it from a process and implementation perspective.
The ‘scenarios’ that you describe are benefits led ‘user stories’, another important consideration would be how to measure ‘velocity’. Also ‘test driven methodology’ would also be very high up on my list, amongst other key Agile methodologies.

If people are interested we recently published an ‘advantages of agile methodology’ article that covers 10 key benefits to business. http://bit.ly/12novKc

One of the key problems with a prescriptive RFP, once you get past the important core functionality, is that the client is endeavoring to think of everything , to fix the price and so that they can later beat up the supplier on and not get fired for cocking it up. And as you say,

‘Because a retailer (and most consultants) most likely won't have perfect knowledge of every platform, vendor, or agency, it's incredibly difficult for them to say what's going to be best for them, and it is, therefore, nigh on impossible for them to know what to ask for’.

This creates unnecessary cost and superfluous development. Again the process is key to achieving the best results; deliver fast, test with correct stakeholders as early as possible and only then define what else is required by priority, approaching development in small iteration, or 'sprints'. If you can measure ‘velocity’ this become extremely predictable and optimises client spend down an evolutionary development path.

For me, once you have seen the advantages of cutting waste in software development, the transparency, ease of measurement and the robust, bug free systems that can be produced by an experienced Agile development team working with an open minded, progressive client there is just no alternative.

Regards

angus

about 3 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Angus

> open minded, progressive client

Most eComm directors would like to think of themselves that way!
Not all manage it: due to unconcious incompetence either with themselves: or with their organisational culture...

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Angus, thanks for taking the time to comment so fully.
I don't want to get dragged down a side alley here - this is not about development or development processes. My concern here is the beginning of the process, and how I feel it could be more open, inclusive and fit for purpose.
User stories aren't new, but I feel they're seriously underused and potentially very useful tools for scoping.
Exploring core functionality and system architecture is, of course, important.
I'd hope that by proposal stage it's clear what's included in a base or core solution and what's additional. If handled well, I don't see why a process incoroporating scenarios approach won't uncover this.

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

That should have read 'a process incoroporating scenarios won't uncover this.'

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Mark,

But that is exactly the point, it *is* about development process.

To my mind a good RFP should incorporate 2 key things;
1) the detail list of core functionality, for an 'apples for apples' comparison
&
2) a clear outline of the design and development process and infrastructure by which the most/best new or extended functionality will be achieved within the available budget.

An RFP that includes those things is not broken.

If you want 'open, inclusive and fit for purpose' then include definition of effective development process.

I am not saying scenarios are not viable, just that they are only one part of it (you missed the other important parts) and that user story format is an established & effective methodology, when combined with stakeholder identification & analysis (and system goals, which I didn't mention).

regards

angus

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Angus
Interestingly, I've never met a client that knew what core functionality was. They can rattle off the 'big' features: search, faceted nav, promotions engine, etc, but those running a mature site will have added lots of stuff to their original set up that may or may not have been incorporated into the core of their provider's system. There's no way they'll know if everything is included in a potential new system. I agree, yes, the challence is to ascertain this, and how much it will cost to add if it is not.
I had the idea for this post when faced with an issue of this exact nature last year. I managed to help an organisation understand exactly what they had/needed by giving an account of what they did and how they did it.
I then brought in agencies to demonstrate their systems around these stories, which worked like a dream and saved everyone lots of time trying to document every tiny feature line by line, and worry that they may have missed something.
It became clear in the demos where functionality needed to be added or tweaked, or a process changed. The final proposals spelled this out clearly, along with costs.
Quick, easy process, great end result.

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

>> there's no way they'll know if everything is included in a potential new system

That is exactly why some diligent documentation is required and should be part of the RFP, There will always be a core of functionality.

It sounds like you are proxying for a client here, so I'm going to say if you can't document your core functionality and 'stuff', allow me to translate that into coherent user stories and then compare that to another vendor's list of functionality then you should probably not be in control of complex software..!

which comes back to @deri's point!

The process you describe (even using scenarios) should cover all functionality, and be the basis of implementation and then acceptance tests. Typically we would would have a few hundred for an ecommerce / cms project, this is unavoidable if you have a large functional system.

Tools like selenium exist for automating the testing if you (as a client) can't be bothered with the testing either ;)

regards

angus

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Angus
The client in question had been using Actinic for the previous 10 years and added so many little undocumented tweaks that the thought of trying to list these was a very worrying one for them, causing them some serious anxiety. They'd looked at the feature lists of a few systems but had no idea what they'd need in addition as published feature lists tend to be bullet pointed, and pretty similar to boot, as you're aware. The scenario approach proved invaluable to them, and agencies that recieved my document said it was like a breath of fresh air.
The last RFP I had in gave an okay, if a little minimal account of 'must have' functionality. As a whole it was a decent document that allowed us gain a good understanding of their situation and preferences and produce a decent proposal.
Many RFP's do not do that and that's when it's time to delve in to the toolbox and find methods to help bring these out.
I've also used this on a process by process approach, and as you said have ended up with a 12-page document of 10-line scenarios for each element under various headings. Hundreds is fine, if there's an openness and flexibility there then that's great. It's the rigid and inflexible ones that aren't focused on outcomes that are disliked by most of the people I've discussed this with.
In answer to my own question: I don't think the RFP is dead, but certain formats should be killed off!
Thanks,
Mark.

about 3 years ago

Avatar-blank-50x50

Elisabeth Else, eCommerce Implementation Manager at ... but is it relevant?

Interesting article and responses, thank you. Just a couple of points from my own experience:

• Helping a client to develop a good RFP is a useful way of getting them to focus on what they really need / don’t need / must replace; in short to move on from a nebulous “we don’t like the platform we have now”, which is often coloured by a relationship that has broken down

• When responding to an RFP, it would help both parties if suppliers (a) declined the opportunity to bid for work their solution is not a good fit for and (b) provided lots of examples of where they have made similar solutions work for different clients, not all from the same site including screenshots with error messages (and yes, I have that!)

• Having professionally evaluated RFP responses, you usually end up with between 1 and 3 suppliers who it appears could actually do the job at a sensible price. The next step to me is an absolutely vital one that no-one has mentioned – take references. Structured interviews probe perceived weaknesses you have observed from one potential supplier across the whole shortlist. This whole process is incredibly useful and tells a lot about the supplier’s way of working as well as the solution itself.

about 3 years ago

James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi Mark,

Great post and it's good to encourage discussion between agencies and Client teams. I have written a few RFP documents myself so always open to sensible advice on how they can be improved.

My take is in line with @David Williams - an RFP is important as part of a wider process but shouldn't be the key driver of the decision.

For me an RFP is essential but not in isolation. You start by defining the business goals and vision for a project, then start engaging potential solution providers to find out whether or not they can satisfy the critical parts of the project e.g if multi-channel is critical to the business, then a solution provider with no MC experience represents a higher risk.

Scenarios can work for gauging people's thought process around problem solving, which is great for evaluating partnership capabilities.

However, there are some things that just need to be nailed down before you commit to working with an agency and the RFP should cover that. For example with ecommerce, I see so many Clients who are fed up that their platform doesn't hit the mark for key functionality/features e.g. site search. Within an RFP you can be prescriptive about the core functionality that must be provided. As David points out, agencies can then mark which elements are core/bespoke/roadmap & ballpark costs for required customisation.

Without that level of detail, you can't, in my experience, make a reliable decision on who is the best fit partner. Without the detail, you risk ending up signing with a partner who might then discover they can't do a large % of your core requirements without bespoke dev and the cost explodes.

So for me, RFPs are an important part of the screening process and without them you risk the classic "that's what we wanted", "well that's not what we understood" argument that blights ecommerce projects and leads to the recycling of contracts every 3+ years.

Thanks
james

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Mark,

We are agreeing here, but the point I keep making is that your 'scenarios' exist in agile terminology as stakeholder 'stories'.

I am also sure that you created 'scenarios' for each piece of functionality. After-all, if you did not how could you hope to have it implemented, or what would you test against? This may well have been a breath of fresh air, but it also needed to be a complete set (and presumably in the RFP).

My point is mostly that the Forrester report repackages received Agile wisdom, and if a client is 'daunted' by documenting their scenarios (or stories) or do not have someone do it for them then they cannot hope for a successful RFP, or web project (indeed, they should not be in charge of complex software implementation at all...)

The degree to which they engage with functional demonstration from vendors, and identify what exists within the system (core) and what needs to be built will vary, but as you correctly say it is normally a significant proportion – which is where the very high risk lies and almost all of the cost!

That risk is mitigated by the bits of the RFP that are importantly additionally required; the development process, from requirement gathering all the way through to load testing…. IMHO agile wins that hands down for fast delivery of used, loved, effective cheaper systems, with far less wastage.

If I were a buyer it would be right at the top of my (unbroken) RFP in bold.

After all this is a post about, 'Is the RFP an effective mechanism that best serves the involved parties?'....

Regards

angus

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Angus
Yes, not trying to claim invention of the wheel here - there's nothing new about the use of scenarios in development, CRO etc. I was speaking with the MD of an agency last week who told me they utilised Behavioural Driven Development processes, my final comment in the post was suggesting that BDD practices could be utilised to good effect at the initial requirements scoping and discovery phase.

@ James: thanks for your comment mate, I know this is a subject you're fond of.
I'd always argue against overly prescriptive documents at the outset of a process for reasons stated, although I completely agree that things do, ultimately, need to be nailed down before committing to build.
You and I both know there are people out there that are very good at responding to RFP's but not so good at delivering. Selection needs to be based more on qualitative factors - the more references the better IMO, and less on a 'yes/no' xls. I think live scenarios would also help there too.
I'm sure we'll be talking more over a cheeky half soon.

Thanks,
Mark.

about 3 years ago

James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi Mark,

Yes I think we agree in principle on the elements that make a sensible selection process.

For me the RFP is not broken, it's how people use it.

If all you want is a 100pp document to fire off to lots of agencies but don't want to properly engage in the process and commit resource to planning the project thoroughly, then you'll inevitably reap what you sow.

This has to be about partnership. If you're not willing to put the effort in, you're unlikely to find a partner who is.

And often the biggest issue is lack of desire to invest in the process, which in my experience leads to far more money being wasted after selection as you fight to sort out a poorly planned/developed platform that doesn't tick the business needs that you never defined in the first place!

It pains me that at least 1 of the RFP docs I've worked so hard to produce has been wasted by the other parts of the process that I advised not being followed-up or valued.

I really think it comes down to the vision, desire and attitude of the Client sponsor - if they don't prioritise it and just want a quick decision, then we're all doomed!

And yes I know a few people very polished at RFP responses but utterly soulless on delivery. I weep everytime I hear someone selecting them.

Thanks
james

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Interestingly James, one of the best tech businesses I know well won't respond to an RFP in any form.
They take the view that if anyone has gone out to RFP they'll choose one of the usual suspects at the top end. They proceed on the basis of 'talk to our customers'.
Interestingly, they build from scratch every time, completely bespoke, involving huge amounts of detail, and have the best of relationships with their clients.
They have proved to me that it is possible to work in this way with great results. Trust and reputation is key for them, and I think that's something that seems to pass under the radar for many who base decisions on the tangible 'features' of a system.

about 3 years ago

Avatar-blank-50x50

Matt Isaacs, Senior Ecommerce Manager at Perricone MD

They won't respond in any form?

What an incredibly short-sighted and, most likely, pretentious attitude.

So they don't even see this as an opportunity to ask the prospective client if they would like to come over for a discussion and sell their extra knowledge and insight on how the process would work better?

How do they know that the client simply does not know of any other form of working than an RFP?

If the agency (as the expert in this situation) can't take the time to discuss and educate, then that is definitely not an agency I would ever consider working with.

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Mark,

>> I'd always argue against overly prescriptive documents at the outset of a process for reasons stated, although I completely agree that things do, ultimately, need to be nailed down before committing to build.

I'm going to say, yes and no!

Yes, because you certainly need to document what you have, and as James says client sponsorship is a key element there to ensure diligent documentation of the 'core', that can be tested and accepted as part of what we call 'initial implementation'. Again, in ecommerce ther are some well established design patterns and 'standard' functionality that just needs to be there as a foundation.

and no, because web systems need to evolve according to emergent stakeholder requirements and you can never be prescriptive about what they might be. Everyone knows more about the project on day 2 than they did on day 1, so why not embrace that change as early as possible?
Hi Mark,

>> I'd always argue against overly prescriptive documents at the outset of a process for reasons stated, although I completely agree that things do, ultimately, need to be nailed down before committing to build.

I'm going to say, yes and no!

Yes, because you certainly need to document what you have, and as James says client sponsorship is a key element there to ensure diligent documentation of the 'core', that can be tested and accepted as part of what we call 'initial implementation'. Again, in ecommerce there are some well established design patterns and 'standard' functionality that just needs to be there as a ‘foundation’.

And no, because web systems need to evolve according to emergent stakeholder requirements and you can never be prescriptive about what they might be. Everyone knows more about the project on day 2 than they did on day 1, so why not embrace that change as early as possible?

Confusingly, that is not to say that you shouldn't document them, but that you should be prepared to change them, weekly (normally) as you know more, under progressive delivery and stakeholder testing.

The beautiful thing about SCRUM methodology is that you deliver in very small timescales (weekly sprints), as early as possible & then appraise with stakeholders and embrace any change that crops up, going back and challenging the requirements. This is made very measurable looking forward if you clock your 'velocity'.

It takes quite a mature buyer though to invest in the concept that this is not a finite thing and that best value lies in a project determined by on-going investment in consistent (not necessarily accurate) development estimates derived form this weird concept of 'planning poker' measured using 'velocity' over an on-going timeframe. I'm going to keep banging the drum though!

So back to the point, for me today's kick ass RFP is all about the development process that supports that evolutionary approach.

I can actually quantify that; within a fixed budget and timeframe (albeit on a mostly bespoke oil and gas pipeline tracking system, but bear with me...) we managed to change the scope of work by 35% during delivery. So 35% of what the client thought they wanted at 'prescriptive RFP' stage was replaced with things uncovered along the way, deemed higher priority as they used the system that we were delivering, on-going. That meant that there was not 35% of things left for 'stage 2', which makes a 70% difference to budget over 2 iterations.

*big* savings & better systems...

regards

The agile evangelist ;)

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

>> Interestingly James, one of the best tech businesses I know well won't respond to an RFP in any form.

that does also strike me as rather strange!

Surely engagement and discussion on their process is a better approach?

& clearly they've never done a government contract!

angus

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Jonny, they're far from pretentious - an incredibly diligent, professional outfit, and a little under the radar as a result.

Interestingly Angus, they do in fact work with a certain Government Ministry! Maybe that's one of the reasons...
They told me as a small business it ties them up, and they feel that at their level if someone has produced a 75-page document they struggle to conform as they are so bespoke - 'yes, we can build that' doesn't cut it against Websphere or hybris.
They work primarily on a referral basis, but they'll sometimes engage if they feel it's a good fit. If the prospect can be persuaded to take a less formal or rigid approach then all well and good but mostly that doesn't happen.

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Mark,

There is indeed a move to make the government IT buying process more agile, this is a good read http://bit.ly/YLl1dU if you have the time. VERY early days with large government projects and supplier selection though. Our experience is mostly old school tender driven, even as an incumbent supplier.

I'm really not sure why you keep implying 'formal or rigid process' is bad.

in order to be flexible in my experience you need to follow a very well defined (formal) process, accepting that under retrospective you need to adapt the process, and therefore be a little less than rigid.

But without adherence to process in systems engineering you are stuffed! Even what are considered to be less 'formal' methodologies need you to adhere tightly to a process, systems and tools.

The worst possible outcome is the removal of traditional constraints on a project by an inexperienced practitioner.

That is where a project heads south in double quick time...

regards

angus

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

sorry, meant to link to 'system error' report http://bit.ly/12WrLg9

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Angus, not implying that there doesn't need to be a defined goal or that process isn't good.
The guys in question are seasoned software developers that work on big, enterprise projects - our wonderful Government included.
I'm suggesting there's more than one way to get there: their way will be different to that of a Websphere based SI so they tend not to respond when those going out to RFP are looking for that kind of pre-existing structure. It's a risk, and they're aware of the old adage 'nobody got fired for buying IBM'.

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Mark,

Interested to hear what their process actually is, and how our development schedule (as we call it) differs.

Also surprised that you say everything is 'bespoke'. Even for something that has completely unique business requirements that require a browser based software solution, we use our framework that encompasses a host of generic 'web application' functionality, as a starting point (it underpins CMS and ecommerce too - stuff like users, permissions, versioning, roles, workflow, reporting etc)

If you have time be good to hear more.

regards

angus

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Hi Angus
Follow me back on Twitter and I'll DM you. They work in a very interesting way, and do use a bit of a hybrid approach which is difficult for me, a non-techie, to explain fully.
Cheers,
Mark.

about 3 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Mark / Angus

I'd love to meet you guys over a coffee to explore this further, great thread!

<taken to twitter>

about 3 years ago

Angus Phillipson

Angus Phillipson, Director at Byte9

Hi Deri,

and there was I thinking i was boring everyone with agile waffle!

angus

about 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Please excuse the pseudo self-promotion here, this is not the intent, but interestingly, we've just made a decision at more2 that because of the unique proposition we have we will only respond to ITT's if we can fully express our individuality.
Much of what we do will be beyond the scope of an ITT, unless it allows freedom to suggest ways to improve.
If people are restricted to only addressing certain questions or narrow areas of service then those with wider remits will be disadvantaged, or perhaps excluded from an RFP process altogether.
This is one of the main reasons why I favour completely open formats, and try to discourage the concept of comparing like for like.

about 3 years ago

Morten Arbejde

Morten Arbejde, Marketing at Personal

Thank you for sharing - nice to see you use forrester too, they rock :)

almost 3 years ago

Avatar-blank-50x50

Mark Bolitho, New Business Director - Ecommerce at more2Small Business

Reading around at the weekend, seems this chap agrees with me:

http://vuurr.com/why-the-rfp-process-is-broken/

The gist is...

Requesting Firm:

Has to predict needs for a project even if they’re not an expert in that field
Has to understand the responses to technical specifications and how the firm best fit their needs
Has to match up different response language to ensure comparing “apples to apples”
Has to go through a lengthy process designed to get a bid that is low priced as well as confident in the firm’s ability to perform up to specifications
Responding Firm:

Has to interpret a document of needs with minimal context – often without a chance to have a real conversation with the Requester – which may or may not actually outline the root problems to be solved
Has to provide a verbose response to prove their ability and reliability without actually building a working relationship
Has to bid low enough to be noticed and hope vendor can then manage the project to that budget or get change requests approved

almost 3 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.