Partner selection is one of North Patrol’s core services. We help our customers in making partner and technology selections when they are creating or renewing their digital services. We can proudly say that we have extensive knowledge of different partners and technologies in the Nordic and North European area. We don’t sell any products, technologies or implementation projects, nor do we make any partnership deals with the implementers, so our customers can truly rely on our independence and that we always try to find the best possible solutions for them.
North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
28 June 2015
1. Clarifying the requirements
Some sort of a specification is always needed so that it is clear for everyone what the customer is buying and what the partners should implement. The goal of this phase is not to make exhaustive requirement lists, but to draw a picture of the project that is as unambiguous as possible. Everyone should share the same vision of why the customer is asking for the proposals: what are the business reasons and expectations for the project, what goals should be achieved and how, what technical prerequisites the customer has etc.
Scope definition is also extremely important in this phase. Especially when building more complex systems, it is good practice to draw a clear picture of the first phase of the project, paying less critical features a little less attention and moving them to the later project phases. If there are elements in the project that don’t seem to fit well in the entity, this is a good place to scope them out, at least from the first release.
There is no standard process that needs to be followed at this stage. All depends on what kind of a project the customer is buying, how much background work has already been done and how complex the system being built is.
If the customer is still in the starting blocks with the project, a few workshops are usually in place to get the goals, visions, functional requirements, priorities, future plans etc. documented. If the customer already has a concept plan, wireframes or requirement lists we can help them fill the gaps to achieve requirements that are as unambiguous and clear as possible.
The form and detail level of the requirements is always decided case by case. However, the key expectations and requirements must be documented to get better quality proposals. Well documented requirements also make the offers more comparable and the final partner selection easier.
2. Creating short lists
Finding a good combination of technology platform and implementation partner is usually one of the key success factors of the project. Some technologies support the requirements better than other ones, and the partners tend to focus on certain technologies and certain types of projects. Also, it is often good practice to rely on technologies that have more than just one or two potential partners in the area. That way, there is a better chance to avoid vendor lock-in and better possibilities to change the partner in case the cooperation turns out not working well.
We see a lot of proposals and we follow the outcomes of those projects, so we have an exceptionally good view of the digital market. We also actively follow the market in general. We explore the implementers’ public references, communicate with the technology providers and encourage all our contacts, including customers and implementers, to tell us their experiences. And fortunately we hear them a lot, too. That makes creating short lists one of our key strengths.
By using our short lists, the requests for proposal (RFPs) are sent only to the relevant partners. Of course, this is not a 100-percent guarantee of getting a good project team, but the work needed for evaluating potential technical platforms can be substantially reduced. Most importantly, the offers are received only from partners who are known to have enough of the right kind of resources and expertise for the implementation on the selected platforms and who are also a good match to the customer’s way of working.
3. Requesting for proposals
Buying digital services is not rocket science, but it has its own characteristics that may not always be obvious if digital service purchasing is not one of the customer’s core functionalities.
The RFP should give relevant background information on the customer’s current situation, describe how the RFP process goes and, most importantly, what are the services, roles and responsibilities that are expected from the partners: refining the requirements, UI design, technical implementation, testing, documenting etc.
The requirements must always be included in the RFP as either part of the RFP itself or as a separate attachment. A few additional attachments may also be needed to make partner evaluation easier, such as a pricing sheet and solution proposal sheet. A separate proposal sheet is especially handy for requesting more detailed information, for example, on how the partner would implement some specific, potentially difficult part of the system. It can also be used for preliminary inquiries about how the partner would implement some further development idea that was scoped out of the first release, but will have an important role in future releases.
We often suggest that the first draft of the agreement is also attached to the RFP. It will be finalized between the customer and the partner in later project phases, but the earlier the partners get the draft, the shorter and easier the negotiation phase usually is.
There is usually very little creativity involved in planning the RFP or agreement. No one gets extra credit for trying to figure out everything by themselves. Instead, using our expertise in this phase is usually very cost-efficient and can save a lot of valuable time. With our help, the RFP phase is usually very short, usually just a few days.
4. Analyzing the quotations
When the proposals are received, it is time to rank them and decide which ones to select for further negotiations. This phase is where diligent preparation bears fruit. If the requirements and priorities are clearly documented and the RFP clearly states what is expected from the partners both in the proposal and project phases, ranking the proposals can be quite a straightforward process.
The evaluation criteria we mostly use are:
- Meeting the requirements
- Four year’s cumulative costs
- Project plan & project team
- Support and maintenance
- Hosting
We think that the most important evaluation criterion is how well the proposed solution matches the requirements of the RFP. This should also have the highest percentage weight in comparison. The price usually has second priority. No matter how cheap the implementation is, if the final outcome does not fulfill the requirements, it’s not what the customer wants.
Regarding the project model suitability, support and maintenance and hosting, the most important issue is how well they fit into the customer’s way of working. For example, agile methods are really great when the customer doesn’t yet have a clear picture what they are aiming at and/or they have a project owner that really can dedicate him/herself to the project. But if this is not the case, it should be stated clearly in the RFP. Of course, the project owner’s dedication is needed anyhow, but a project model that emphasizes the initial planning phase can be valued more if that is what meets the customer’s needs best.
It is also very important that the proposed project team is a good fit for the project. This can be somewhat difficult to see from the proposals, but the project team’s CVs reveal a lot. Especially the partner’s proposed project manager and lead technical architect should have previous experience in similar tasks in projects with similar complexity. Usually the more the better.
In each evaluation, we typically use 10–20 criteria ranked on a predefined scale. Each category has its own predefined percentage weight factor agreed with the customer. After entering the grades in Excel and applying the weight factors we get a clear presentation of the rankings. Based on these results, it should be fairly easy to select the top candidates.
The comparison is done as rationally and fact-based as possible. Historical burdens or merits have no effect and all the partners are treated equally, with just this particular customer and project in mind. In the end, the winning proposal is usually the one that has the best balance between all criteria: it describes the highest degree of meeting the requirements, is clearly customer-specific, gives realistic estimates of the amount of work, budget and schedule, and proposes a project model that fits the customer’s way of working well. This is why smaller players with no previous common history with the customer can beat the bigger players in case they deliver a good, realistic and feasible proposal.
(Don’t forget to check the other tips regarding the comparison in my earlier post Discover the true differences between tenders.)
5. Final selection
Based on the rankings described above, we give our recommendation of the top 2–3 candidates. We usually create a memo of the comparison that lists the methods used in comparison and all the strengths and weaknesses per candidate, thus bringing every relevant piece of information to the table. The final decision, however, is always made by the customer. Sometimes our customers have also made a comparison of their own, in which case the customer’s final decision can be based on both comparisons.
If possible, we always encourage our customers to meet the potential partners and their project teams face to face before the final decision. It is extremely important to know who you will be working with intensively for the next months. A meeting is also a good opportunity to check whether or not the potential partners have understood the needs correctly and which ones really want to win the contest. Good communicating and interaction skills can also be a vital success factor for the project, which can never be judged purely based on printed material.
North Patrol can help the customer in this phase, too. We can prepare the preliminary tasks for the potential partners before the meeting, facilitate the meetings and ask the partners tricky questions when they present their project teams and plans. In partner meetings we often emphasize team competence, project plan and working methods a bit more than technical details. We try to get a pragmatic and concrete picture of how the cooperation with the customer would work in real life. That usually helps the customer in deciding which of the teams would be the best to work with.
After the final selection is done and the contracts have been signed, our partner selection project typically ends. From here on, the selected partner is in charge of building the service as specified and agreed. This, however, does not mean we disappear from the planet. We can still support the customer in several different ways during the project if needed: we can participate in the planning meetings, make sure the selected partner’s more detailed plans match the requirements, participate in steering group meetings, validation testing and other day-to-day tasks during the project.
Don’t hesitate to contact us for help with your project. The investment will pay itself back many times at later stages of the project.
