Why a traditional tendering process is no longer fit for purpose

Which large company or service provider is not familiar with RFPs? The term is an abbreviation for "Request for Proposal" and refers to a document in the software selection process containing binding information on contract specifications and other negotiation items that are defined before the actual contract (software development contract, license agreement, etc.) is drawn up. Nowadays, such an approach is no longer appropriate due to increasing complexity and dynamics. We explain why this is the case and how this can be countered.

Ina traditional tendering process, the RFP is usually preceded by a so-called RFI (Request for Information), in which non-binding price and service lists of possible service providers are obtained. This information can - at least in theory - be used to make an initial pre-selection (for the subsequent RFP). So much for the theory: however, it is essential to bear in mind that modern software development, and e-commerce in particular, is sometimes subject to enormous complexity and dynamism and that such a rigid corset is not appropriate for either an evaluation or subsequent implementation. However, the dilemma of the new Berlin airport proves that this does not only apply to software.

In the past, the so-called waterfall model was predominantly used, in which requirement and functional specifications were created as part of a comprehensive concept phase, in which the exact requirements and solution approaches were defined in advance. These documents then formed the basis for any contracts, offers and the final implementation. As soon as changes became necessary during implementation - which was/is the case in the majority of cases and is also completely normal - so-called change requests had to be triggered, which were seen as a supplement to the previous documents and had to be taken into account accordingly. In other words, people used to stick to this approach for many years, knowing full well that the end result would probably be very different from what was planned and prepared in advance.

Web projects in particular are becoming increasingly complex and are subject to ever greater dynamics. In addition, we are often talking about project durations in the range of 3 to 7 months, sometimes even significantly longer. As a result, a web project can no longer be planned in detail and in advance, even to the best of our knowledge and belief. Significant changes will sometimes occur during the project, to which it is necessary to react as flexibly as possible. As a result, more and more companies have discovered an agile project approach.

In the meantime, web projects are predominantly realized in an agile manner, whereby two approaches have become established here: Scrum and Kanban. Essentially, these approaches no longer involve planning a project down to the last detail in advance, but rather discussing, recording and prioritizing the key requirements with all relevant stakeholders (project participants) on the basis of so-called epics. The aim is then to implement an initial executable product as quickly as possible (a so-called minimal viable product), which is then successively expanded and extended as the project progresses. The decisive advantage of agile project management lies in reaching the goal faster and being able to recognize and counteract any undesirable developments at an early stage.

Experience in recent years, both on the customer and service provider side, has shown that e-commerce projects in particular can nowadays only be realized in an agile manner with corresponding prospects of success. Incidentally, this now applies not only to e-commerce or IT projects. It is therefore not surprising that, according to current information from the car manufacturer Volkswagenwants to train 150 Scrum professionals and 500 employees in the Scrum methodology over the next three years. This decision is certainly no coincidence ..

Agile management methods are (more) successful and continue to gain ground

The results of a study conducted by Koblenz University of Applied Sciences in collaboration with the GPM Deutsche Gesellschaft für Projektmanagement e. V. and the IPMA - International Project Management Association show that agile project management methods are very successful and are being used more and more frequently. V. and the IPMA - International Project Management Association, which was conducted in spring 2014. 612 people from over 30 countries took part in the study, with more than 60% of participants coming from Germany.

"An improvement in the results and efficiency as well as the improvements in comparison to the effort involved in introducing agile methods were largely answered positively by the participants. In their self-assessment of the success rate of the development processes carried out, the users of agile methods surveyed also rated themselves better than the users of traditional project management. The success rate of development processes carried out using agile methods was a median of 80 to 89% higher than the success rate in traditional project management."

The agile evaluation process

So what does all this have to do with the tendering and evaluation of an e-commerce project? A lot, if you consider that the implementation - as we have heard - will ideally be carried out using agile management methods, but that the tendering and evaluation process uses "classic" assessment standards and procedures, which inevitably can and will quickly lead to incompatibilities. So what could be more obvious than "agilizing" the evaluation process and introducing more flexibility and, in particular, communication? The latter in particular is of crucial importance, and practice shows it time and time again: a direct dialog between client and service provider, even if it is only brief and to the point, is usually much more valuable than pages and pages of documents and descriptions. We call the result of the further development of the evaluation process - drum roll - an agile evaluation process.

The four phases of agile software evaluation

Similar to other agile management approaches, agile software evaluation also consists of several successive phases, which are as follows:

• Discovery phase
• Translation phase (user stories/epics)
• Selection and presentation phase
  a) Submission of evaluation questions (max. 8 providers)
  b) On-site presentation (max. 4 providers)
• Implementation phase for test project (2 providers)

We explain below what this involves in detail.

1. Discovery phase

At the beginning, it is crucial to obtain as accurate and comprehensive a picture as possible of the company, the existing processes, tools and problems as well as the project participants. This phase also serves to shed light on the intended objectives and associated opportunities as well as any risks and to discuss them with all relevant parties.

To this end, a powerful evaluation team including a project officer (PO) should be formed on the client side at the beginning. It is important that all relevant areas are covered by one employee, who can also devote the necessary time to this and receives the necessary backing from superiors. Depending on the scope of the project and the specific circumstances, this effort can range from several days to several weeks. Ideally, the assigned project manager should spend the majority of their time on the e-commerce project and be involved in all processes from the first internal discussions onwards.

Typically, the following departments and divisions (if available and relevant) should be involved in the process right from the start:

• Project management
• Marketing
• IT
• Sales
• Design (if available/relevant)
• UX (if available/relevant)
• Customer service/support
• Operations
• other areas if necessary

On the one hand, this has the great advantage that the departments and employees are consulted at an early stage and involved in decisions that will certainly affect them later, and on the other hand, the necessary information and the corresponding feedback can be collected across departments and directly "at the base". Experience has also shown that two key factors can jeopardize projects:

• Silo thinking of individual departments that only pay attention to themselves and their requirements/specialties. Through an open and agile evaluation process, the parties involved must talk to each other and coordinate at an early stage.
• By consciously or unconsciously bypassing specialist departments, they feel excluded and it would not be the first time that projects are subsequently "boycotted" or at least not supported accordingly.

Questions, questions, questions

The most important thing during the discovery phase is to ask questions. The old adage that there are no stupid questions, only stupid answers applies here. In principle, every stone should be turned over here and as much as possible should be questioned. You need to be genuinely interested in your company and e-commerce. If you ask a lot of questions, you yourself will become more and more curious:

• You then listen more than you speak yourself
• You get very valuable and unfiltered information
• You get a view of the bigger picture
• Ideally, you can get a first impression of the "big picture".

You should first focus on the basic philosophy and objectives of the project and not on any features or solutions in advance. Furthermore, no architectural decisions should be made in advance, as this could influence any solution approaches. Always remember: "The more you dictate, the less agile the project is."

People regularly tend to look for and apply a solution too quickly. So if you submit a project request to a service provider and ask for a demo, your request will be granted in many cases - even if this approach is absolutely not expedient. Although the service provider has received documents from you, they know little or nothing about you and your requirements. The relevant information cannot usually be obtained from a questionnaire alone, but only in dialog with you. A professional service provider will therefore start by asking you questions, regardless of the type and scope of your request.

We have already explained how you can find the right service provider in a detailed blog post. At this point, we would again like to point out the first impression and the provider's initial reactions and questions. If decisions are made prematurely - regardless of the choice of technology or service provider - this can have massive negative consequences:

• You waste resources unnecessarily.
• Actual problems are dragged along and stick with a company for years
• Actionism instead of improved productivity
• Requirements documents are created with lots of wishes (which are often not effective)
• You will inevitably have (new) problems - in the worst case, lots of them

Discovery questions

You should first have the following questions answered by the members of your evaluation team and then discuss and prioritize the results in a workshop with everyone involved:

• What are your motivations for a (new) e-commerce platform? Customers, competitors, first movers?
• Which current market trends influence your business the most?
• How is your business changing?
• How is the Internet changing your business?
• As a customer, what would you want from your company?
• Which channels do you currently use to sell your products or services (Internet, catalog, direct sales, partners, etc.)?
• How do your online activities and experiences differ from offline?
• Who are your current customers? Which customers are the most profitable?
• What is their most exciting product or product line at the moment? What are they most profitable?
• Who are your main competitors (online and offline)?
• Why do customers buy from you and not from your competitors and vice versa?
• How do you differentiate yourself from the competition?
• What is already working well in your existing store and what is not? (if available)
• Which stores do you see as role models (in your environment and in general)?
• Do you have an international corporate strategy (several languages and several currencies)?
• How are you staffed and where do you see your online business (in the future)?
• When you look at your current requirements, do you consider them to be complex or standard?
• Where does your product data currently come from? Is it prepared in a customer-friendly way and can it be used accordingly?
• Which online marketing measures do you currently use (SEO, SEM, display, affiliate, e-mail, etc.)?
• What needs to happen for you to rate the project as successful on completion? What criteria are decisive for you here?

How do you find the key topics and greatest potential?

To get started, the company-wide objectives and targets should be taken as a starting point and matched with the following questions. These questions should then also be answered and discussed by the entire project team as part of a workshop:

• What is the current situation and how are any problems being solved today?
• What should the online store look like in the future?
• Who are the primary users / user groups?
• What does the planned online store mean for the users (internal and external)?
• What does the planned online store mean for the company?
• What has been done wrong in the past and how can this be prevented from happening again in the future? What are the biggest non-functional problems that need to be solved?
• What does project management look like in practice? Who has what role and authority?
• How much is the project worth to the respective area in terms of the added value it brings?

The discovery phase therefore serves to record the requirements and special features of as many stakeholders as possible and to create a "shortlist" of potential service providers. Here it is advisable - also from a cost/benefit perspective - to limit the scope to a maximum of 8 service providers. Please also refer to our blog post with tips on selecting a suitable web service provider.

2. Translation phase (user stories/epics)

While the discovery phase - as the name suggests - serves to intensively scrutinize the status quo, the environment and the special features as well as the goals and to compare them with the individual stakeholders, the translation phase serves to cluster the information obtained, prioritize it, match it again with the general corporate goals and then formulate high-level user stories/epics for the most important areas/requirements at the end. In practice, it has been shown that detailed specifications and overly granular user stories/epics are not necessary for this either, or tend to have a counterproductive effect, as they suppress the advantages and charm of the agile approach and may force service providers into a corset unnecessarily and at an early stage or exclude possible solutions in advance.

In our experience, it is also sufficient from a cost/benefit perspective to formulate the requirements in so-called epics, as massive changes can often arise in the further process and dialog - as is also the case with agile project management:

User story vs. epic

"A user story ("user narrative") is a software requirement formulated in everyday language. It is deliberately kept short and usually comprises no more than two sentences, in the following form: "As <role>, I want <goal/desire> to <benefit>". The user story should not exceed an implementation time of 8 hours. It may need to be split up.

Example: As a customer, I would like to be able to create an account so that I can see my purchases from the past year in order to plan my budget for next year.

In the context of requirements management, an epic is the description of a requirement for new software at a high level of abstraction. The requirement is described in everyday language (analogous to user stories). Epics are used to develop a product backlog in the context of Scrum. They enable the author to initially develop an aggregated, roughly granular view of new product requirements without having to go into the details of a requirement." (Source: Wikipedia) Epics are feature-level tasks that comprise many user stories.

Example: In the example above, an epic would possibly include the entire account management feature and the function for displaying previous purchases.

The following parameters should serve as a first rough orientation for possible epics and are only a basis for discussion for your evaluation team:

• Home page
• Category overview page
• Product detail page
• Search and navigation
• Content/content management
• Search engine optimization (SEO)
• B2B log-in
• Shopping cart
• Check-out
• Customer account
• Marketing tools
• Interfaces to third-party systems
• etc.

To record the corresponding epics, the following table can be used, for example, which is filled out by each area/stakeholder and discussed and finalized again with all stakeholders at the end:

3. Selection and presentation phase

In the selection phase, you should include a maximum of 8 providers from a cost/user perspective and ask them to answer the following agenda items 4 and 5 as comprehensively as possible. The green parts will be taken over by the client.

The following points should also be addressed and answered by the service provider

• Present your company on a maximum of 20 slides with a history and any special features (awards, etc.).
• What does your employee structure look like? Do you have the skills and resources required for this project? Do you have experience with comparable projects (project scope and complexity)?
• What references can you provide and is there a possibility of direct contact?
• What would a possible project team look like? How much experience does this team have with agile software development? How long has the team been working together?
• You have already received corresponding user stories/epics from us. Please estimate the story points for this. How would you rate the complexity of the project based on the story points?
• How do you assess the expected velocity of the planned team in story points per sprint?

If a service provider has experience with agile software development, questions 4 to 6 in particular should be relatively easy to answer. After sending out the tender documents, the service provider should typically return a number of queries - either in the form of a standardized questionnaire or "freestyle". The response as well as the type and scope of the feedback should already be taken into account as an initial indicator for further selection:

• How quickly is initial feedback provided?
• What form does the feedback take (standard e-mail, specific e-mail, telephone call)?
• What basic questions are asked? How many questions are asked and how targeted are the questions?
• Does the service provider actively make suggestions at this stage and does the initial feedback result in concrete change approaches or new ideas on your part?
• Who or which employees/positions are involved in the discussions during any telephone calls on the service provider side?
• Does the service provider offer to discuss the project and any questions in advance at a personal meeting?

In the latter case in particular, you should take the time to meet with the relevant colleagues in your own interest.

The service provider should then be in a position to provide an initial project estimate in the form of a cost corridor - naturally with corresponding uncertainties due to the lack of specifications. You should also make sure that the provider makes any assumptions or provides explanations for the estimate in order to be able to better verify the whole thing.

Based on the preliminary discussions and the documents provided, you should be able to select four providers for a presentation at your premises. However, it is advisable to use the quality and scope of the documents sent as well as the questions and the "feel" in advance as the primary decision criterion, rather than the expenses mentioned.

The four favorites then present their documents and preliminary considerations to you on site. Now comes the part where you have to be "very strong" and which is probably making your face blush as you read this. But it will pay off in the end!

Drop your pants!

You're probably thinking that this had to happen because the article was written by a service provider. I can't and won't disagree with that, but the approach demonstrably leads to better end results. And here's the thing: tell the four presenting companies the budget on the service provider side. I'll also explain why! We have already addressed the issue of transparency several times beforehand and you probably want the greatest possible transparency from a potential service provider - and rightly so. Conversely, it is only fair and absolutely expedient for you to "drop your pants" and tell the service provider what project or service budget has been budgeted on your side. Then everyone involved knows what is going on and can adjust accordingly. In other words, the service providers can leave out any technical "bells and whistles" and opt for a more pragmatic approach or, conversely, aim for the premium solution with Rocket Science. It is important that the basic quality is guaranteed regardless of the scope and level of comfort of the implementation. The most effective way to achieve this is to ensure the greatest possible transparency on both sides.

If you want to build a house, you usually also have a budget framework in mind within which your dream home is to be realized, and this enables an architect to plan the right size and the appropriate "features". A budget of millions will "inevitably" (and hopefully!) lead to a different end result than a budget of EUR 500,000. In both cases, you will ideally get the most for your money, but at a different level and with differences in the details.

In addition to transparency, trust is another basic prerequisite for successful cooperation (partnership). Of course, it is not easy or even feasible to blindly trust an unknown service provider. On the other hand, a lack of trust can also be equated with mistrust - which in turn is a very unfavorable basis for cooperation. Incidentally, this applies to both sides, as the service provider must also trust that any misjudgements or similar will not be exploited by the client and that they will be remunerated accordingly in the end. In my opinion, an earlier commercial said very aptly: "Trust is the beginning of everything!"

IMPORTANT: Transparency, trust and fairness reduce the administrative overhead, which in turn means that the majority of the budget is actually used for implementation and not for supposedly "filler work"; this significantly increases the efficiency of the project and improves the end result! So how do you create a better basis for trust? Our approach: start a test phase of cooperation!

4. Implementation phase

Beforehand, every service provider will tell you how well and successfully a collaboration will run and which projects and references have been successfully implemented in the past. This is perfectly fine so far. However, it must be said once again that every project and every customer is different and that a large number of components are important in order to be successful in the end and to satisfy everyone involved:

• The basic chemistry between those involved must be right.
• The "mindset" (working methods and basic ideas) must match.
• The type of communication and collaboration must work.
• A comparable eye level must be guaranteed.
• Honesty, fairness and transparency in the relevant areas must be possible.
• Constructive criticism must be accepted by both sides.
• You have to learn how the other person "ticks" (dos and don'ts)

→ A trusting, fair and pleasant working relationship must be possible!

You won't find all this out through fancy presentations and a bit of "small talk". The real truth will only emerge during the work. In this respect, we recommend that the two winners from the presentation phase work together on a trial basis over a period of time. The period should not be too short, but also not too long, in order to be able to proceed as efficiently as possible, as such a parallel test phase with two service providers naturally also means increased effort both in terms of time and costs.

The test project

IMPORTANT: In order to really create a reasonable basis for assessment, it is important from our experience that this test project is remunerated "normally" and that free development work is not demanded from the service provider as the scarcest and therefore most valuable asset. This is the only way to ensure that the service provider actually deploys or can deploy the relevant employees with the necessary skills (and not a "demo team" with the best people), and only in this way can a truly reliable basis for comparison be created and a practice-oriented evaluation made. The winner of the test project is then awarded the contract for the entire project and any subsequent further developments. The loser is paid for the hours worked in accordance with the previously agreed remuneration.

The test project should contain one or more work packages or epics from the backlog and therefore already deal with the actual project in order to produce as little waste as possible. At the beginning, both participants receive a backlog with corresponding tasks at the same time, which is presented to them again in detail by the customer before the start of the project. It must also be ensured that sufficient time and resources are made available for any queries. After the briefing and clarification of open questions, the go-ahead is given for the parallel implementation. For example, a classic or frequently used sprint length of 2 weeks could be selected as the scope here. At the end of the test period, the implementation is then presented individually to the entire evaluation team.

Whether and to what extent an agreement is reached here, e.g. for a partial crediting of expenses or another "goodie" for the subsequent winner, is left to the two negotiating partners. It should only be ensured that the loser is adequately compensated for the efforts made. Once again, honesty and fairness should come into play here.

General conditions

A service approach based on time & material is chosen for the test project. The scope (number of employees, hours, hourly rate) and payment modalities can or should be defined in advance. Furthermore, you should ensure what happens to the implementations created in both cases, i.e. who receives ownership of them and what the situation is with any further use. However, one central point should be clarified and fixed in advance: the test project must be realized with the team actually planned!

Evaluation

Various parameters and skills can be used to assess the two results. Below are the most obvious criteria from our point of view:

• Quality of the implementation
• Scope of the implementation (basic factors and, if applicable, enthusiasm factors)
• "Company fit", i.e. how good the chemistry is between the two companies and the people involved
• Efficiency and costs

Here is a small calculation example for the outlined procedure:

Let's assume that the project at hand has been assigned an initial cost estimate or budget of EUR 400,000 and let's further assume that a team of four developers is working on this project. If we now schedule a test project over a sprint of 2 weeks, the calculation for the test project would look as follows under the assumptions mentioned:

Assumptions

• Hourly rate: EUR 100
• Team size: 4 developers, 1 product owner
• Developer working time: 80%
• PO working time: 50 % (a project manager is also provided on the customer side)
• Weekly working time: 40 hours
• for reasons of simplification, we do not have a Scrum master
• Expenses on the part of the client have been omitted here, as corresponding expenses are incurred in every reasonable tender and the costs for this can also be significantly higher with a classic approach.

Costs for the test project: (((4 developers x 8 hours × 10 days) x 0.8) x EUR 100.-) + (((1 PO x 8 hours x 10 days) x 0.5) x EUR 100.- = EUR 25,600.- + EUR 4,000.- = EUR 25,600.-

Since the winning team's solution already represents the first part of the project, "only" the expenses for the second team, i.e. the calculated EUR 25,600, must be recognized as external or additional costs for the test project. If you now consider the following facts, this investment can prove to be extremely sensible:

• A manageable, one-off investment (in our example amounting to just 6.4% of the external project costs) gives you maximum vendor security (company fit)
• No additional time is lost as the implementation is already part of the project.
• You receive reliable figures and data on the efficiency of the service provider as well as real results for assessing quality
• You may receive important impulses and ideas for further development
• The project team can adjust to each other in advance, familiarize themselves and get to know each other better.
• By working together, the first step can be taken towards building the trust that is absolutely necessary.
• In the worst-case scenario, you still have a plan B up your sleeve with the second-placed service provider.
• Due to the competitive situation, both providers are forced (as in the subsequent project) to deliver the best possible service.

If you also take into account that a not insignificant proportion of IT projects fail or get into difficulties due to the wrong choice of technology and/or service provider, resulting in enormous additional costs, the approach presented seems even more plausible and economical. You just have to consider what it would mean if, in our example, it only became apparent halfway through the project that the wrong decision(s) had been made. In this case, EUR 200,000 might already have been invested and, in the worst case, it would be "back to square one". This would not only have resulted in enormous costs, but also a massive loss of time, which in the worst case would also have a negative impact on the further development of the company/sales. Furthermore, it would certainly also be necessary to "repair" one or two scratches internally!

→ At the end of the day, this means cost savings and risk minimization at the same time! The latter also applies to both partners, which in turn contributes to the "transparency, honesty and fairness" account. Once again an investment in a genuine and promising partnership!

Conclusion

There is a good reason why agile working methods have been conquering the economy for some years now - and not just in the IT sector. The approaches of agile methods are aimed at a faster time-to-market, better and more suitable, more flexible solutions and a higher business value instead of pre-defined and fixed desired scenarios that are controlled by high administrative effort and various penalties. Agile software development is also best suited to an agile evaluation process, which is generally much cheaper and more practice-oriented and, if applied consistently, also offers better/more suitable results and greater security for the client.

In this respect, this procedure can only be recommended to every company for the evaluation of possible software solutions and service partners. If you have any questions about the procedure presented or need support in carrying out this process, we will of course be happy to help you at any time!