Product selection done quickly

Your customer has a specific challenge and wants to have it solved by means of software. They ask you as a software/solution architect to advise them on this topic and they want to be able to choose a solution based on your advise by the end of next week (we’re not talking about something as large as a government tender). How can you approach this challenge? When using a formalized approach, although usually thorough, you will probably not make it by next week and thus you are forced to make some shortcuts.

It boils down to establishing a set of prioritized requirements and evaluating them against potential solutions. In this blog post I’ll provide a general outline of a ‘quick and dirty’ (not so formal) product selection process which can be done relatively quickly. I’ll start with identification and classification of stakeholders. Next I’ll suggest several topics to talk to the stakeholders about in order to determine and prioritize requirements. Ending with several suggestions on how to obtain possible candidates for the solution and compare them.

Disclaimer

There is probably overlap with existing approaches to accomplish the same. Please inform me so I can cross check this, learn and add references. I’ve used CMMI-DEV as an inspiration among others. The below approach is not a company standard. It is an approach I’ve personally tried and have good experiences with.

---

Stakeholders

Determine stakeholders

In order to obtain requirements from the customer, you need to know your customer. In a small company this is relatively easy since you know who the people are who make the decisions and spend the money. In larger companies, this could not be so straightforward.

Usually there are several stakeholders in larger companies for IT related solutions. Think for example of the following people;

• the people who have to implement the solution
• the people who will have to test it
• the people who will have to integrate with it
• the people who will have to use it (your (usually business) customer)
• the people who will have to monitor it 
• the people who will have to do maintenance on it
• the people who will have to pay for it (for implementing, operational costs, licenses)
• the people who are concerned with the quality of the solution (think topics like security, performance, maintainability, reliability (from ISO-5505))

It helps to have representatives for these groups and preferably people who are allowed to make decisions. THink for example of a product owner. Don’t involve too many people since it might take a long time until there is a shared list of requirements everyone can agree to. 

Consider stakeholder motivation and influence

It is always good to look at the different stakeholders and how much influence and interest they have. You don’t want to include many requirements suggested by someone who has little influence and is not allowed to make decisions about the product to be implemented. If you encounter someone like that, it helps to find someone backing those requirements who is higher up in the chain (and to promote the requirements from suggestions to actual requirements). You also don’t want to ignore someone important who can decide to scrap the entire project if it is not to his/her liking. Usually the most important people are the ones who have to approve on spendings and have a (delegated) responsibility for making the solution work.

It is important to realize different parties can have different motivations/goals to suggest certain requirements. For example, a supplier might try to introduce requirements which will increase the chances his/her products are chosen.

Requirements

Determine sources for requirements

Requirements can come from various sources. You can talk to your customer about these in order to determine if and in what way they are relevant. Below are some examples;

• Customers vision
  We want to grow to a SaaS business so only SaaS solutions are acceptable
  We are a large organisation and we want our products to be supplied by another large organisation who understands our processes, who will not go bankrupt quickly, who can be counted on for continuity
• Customers financial situation
  CAPEX vs OPEX. An on-premises solution might require a large upfront investment should you not already have the infrastructure and platform in place, while a cloud solution likely has higher operational cost.
• Life cycle of the solution
  Should it be a throwaway solution or should it continue to be valuable for the company for many years to come? In the second case, you hope your customer allows you enough time to perform a thorough selection process. You can look at the supplier and product in more detail. For example, references / reputation, financial situation, company size, market share. Which products does the supplier consider strategic? For example Oracle, Microsoft have several solutions for the same problem not usually only a specific solution is strategic and others are considered legacy. Strategic solutions tend to stick around longer.
• Implementation time
  Do you need to have it up and running tomorrow or does your customer allow an implementation time.
• Customers history / current hardware & software landscape / existing licenses
  We have everything Microsoft so we want Microsoft because it goes nicely with the other Microsoft things we have and know how to work with the Microsoft stack / have good experiences with it.
  We own a large datacenter and want to use the resources we pay for so we will not go for external cloud solutions.
• National and international legislation
  Think GDPR but also the US CLOUD Act if you use cloud services of companies based in the US (for example Google, AWS, Microsoft, Oracle)
• Government constraints / regulations
  For government agencies. Think VIR, BIO in the Netherlands (security related guidelines)
• Customer, implementation partner or preferred supplier strategic partnerships and contracts
  My strategic implementation partner specializes in Oracle and we have negotiated a deal that we can hire x consultants at a rate of x per hour if we use them. Oracle products are thus prefered.
• Product experience available at the customer, partner and in the market and the expectation on how this will develop in the future
  You don’t want to start and create a new COBOL application. Also you might not want to jump on the hype train of the latest and greatest new programming language because it has an uncertain future and a relatively small community. Not many people have experience with it yet and it still has to proof itself in large scale implementations.
• Constraints due to certifications
  Think for example ISO-27001 for security (processes). A certifications can be a requirement to do business with certain parties.
• Do you need support? If you do, who will provide it? The implementation partner, the software vendor, the ‘community’, people at the customer? Will you go for an open source solution or a commercial solution? Do you need a contract / an SLA (Service Level Agreement) to provide certain guarantees?
• Reuse and adapt existing components in your software landscape, buy something pre-build (COTS) or create your own custom software.
  Usually it is financially beneficial to first look for a solution which fits requirements based on re-using existing assets, next look at buying pre built solutions and if that is not viable, for example for a startup who provides a new and innovating product, to develop it yourself. It can help to make a business case for several more concrete scenario’s and compare them.
• Architectural constraints
  Enterprise Architecture, a reference architecture or… hopefully provide you with principles / guidelines to direct the above. Maybe even already is a template for a product selection process you can use.

Formulate requirements

Based on these considerations / sources you can formulate requirements. Of course, if you want to effectively use requirements, they should be formulated in a SMART way. If you have ‘fluffy’ requirements, it will be difficult to objectively compare solutions against these requirements.

It helps to not have too many requirements. Somewhere between 20 and 50 should suffice. If there are a lot, it will be difficult to quickly check a product against. Also, do the requirements contribute to making a difference between different candidates or can you consider them as generally covered by every product? For example; ‘should communicate using HTTPS’ will probably not allow differentiation between different products. It is probably better to refer to a more general set of guidelines as requirements such as ‘can conform to the NCSC guidelines regarding transport layer security’ (this is a Dutch government standard). Maybe even reference a specific document.

Document the requirement origin

When documenting requirements, it helps to specify the source. For example some requirements can be talked about/scrapped or rephrased and some, such as for example those based on legislation, usually can’t. If you can trace back requirements to its origin, it also helps build confidence in that the process of determining the requirements has been done thoroughly. For constraints put in place by for example an enterprise architecture, it helps to refer to specific principles.

Prioritize requirements

Once you have requirements, you should determine the priority of the requirements (let the customer determine the priority). MOSCOW is an easy one but might be too fine grained. Three categories might suffice and make it easier. Important is to at least identify several criteria which are knock-out. If a solution does not conform to that, you don’t have to look further at that product. For example, when you’re worried about the CLOUD Act / GDPR, you should choose a solution which is hosted in the EU and does not use services from US suppliers. 

In the end it is the customer who decides where he/she wants to put his money and who he/she puts his /her confidence in. Legislation might provide for example hard constraints for certain choices to make, but the customer can decide to take the risk of being fined and not following those constraints. Security can also be considered a calculated risk of chance of occurrence times possible damages which are weighted against the cost of implementing security related measures to prevent the issue.

Choose a solution

Identify candidates

You search for possible solutions in which you take the most important requirements / constraints already into account (Google is your friend!). You can use the knock-out criteria for that. 

Sometimes it helps to ask other people for inspiration and suggestions. Even though you are smart, you do not know everything! When you want a solution from a specific supplier, you should check out the products the supplier provides to tackle the challenge. These can be multiple when talking to large suppliers. I would look at which product is strategic for the supplier in such a case (if not published ask them which product they would suggest) and check out the technical state of the product. Some companies don’t want to be the first to find out a certain feature does not work as expected and be delayed because they have to file, monitor, escalate, etc a bug fix request.

Make your choice

Now you should have a short-list of a couple of products. Now you can create an XLS sheet with (SMART) requirements vs products and hand the sheet over to someone else to fill-in. You can add nice colors for a quick overview; Conforms (green), does not completely conform but comes close (yellow), does not conform (red). You can even score the solutions based on their assigned priority if you want to. The requirements are SMART, what can go wrong? (asking the wrong person to fill in the XLS is what…).  Next return it to the person in charge of making the decision so they can decide. Remember, the customer decides. the architect is usually just the advisor.