An Informal Description of Software Procurement
Normally, when people want to buy software they go through a formal buying process whereby they try to describe what they want in an unambiguous way and send out a tender to a group of likely looking suppliers who may or may not be suitable. Of course, everyone claims they can deliver the earth. Those who make it onto the shortlist make appointments to give demonstrations. From which the customer tries to decide who to go with.
But there are problems. Typically, the customer is terrible at describing what they want; but it's not their fault! They use natural language (which is ambiguous), and so the suppliers are not told exactly what the customer wants to see. They come in and give their normal demonstration. The customer doesn't really get to see an example of their real world problem being solved. The suppliers show all the bells and whistles, but these tend to be in the category of 'nice to have' rather than essential. The users in the audience who are trying to help decide what system they should go with, get bored instead. Often the final decision is made on the basis of price (who is the cheapest); and that could have been determined without the demonstration.
The problem is the price quoted by the company most eager to do the work by under-cutting everyone else, is seldom (never) the price finally charged. Once they get the contract and get into the detailed requirements they find they are ill-defined. Gravy-train; a license to start printing money. The customer finds themselves in a 'cleft stick' because they've already handed over a lot of money, and faced with the dilemma of handing over more or getting nothing, they have little choice but to pay up.
Active Requirements manage this chaos. How? With a pattern language that transforms English into pictures; academically peer-verified and proven in industry. If what you are buying can in any way be described as a transactionally-oriented database driven application then this pattern language works. A model can be built quickly enough to inform the tender process allowing the pictures to be transformed into demonstration scenarios. The suppliers are then told what they are going to demonstrate according to the scenarios. This way all the demonstrations are comparable because all the suppliers are working from the same scenarios. They show actual workflow being accomplished. Users watch the demonstrations, and they feel involved instead of bored because they see a task being accomplished that they do everyday. So they are able to participate in helping decide which supplier to choose on the basis of functional fit rather than just price. When decisions are made on this basis, the risk of the supplier not delivering what is wanted for the price that is agreed comes right down.
Pictures tell us a lot. Not only do they allow the articulation of demonstration scenarios, the can also become part of the legal contract, and that helps resolve disputes once the parties start working together.
Procurement Management
Buying a software solution is complicated. You have identified there is a problem that would potentially benefit from a new application; you could build it yourself (perhaps), you could have it built, or you could go for an 'out of the box' solution (COTS or 3rd party product). So, which is it going to be? If you decide to go the COTS route, you will face certain challenges. Instead of trying to manage those challenges yourself, it is worth considering engaging our specialist services to ensure the obvious pitfalls are navigated, and the less obvious ones mitigated.
Primarily the challenge of COTS procurement is in first producing an accurate and unambiguous model of your requirements, and then in finding a 3rd party product that can best satisfy your requirements balanced with the right technology and the right commercial terms. All the processes we undertake are commercially proven; all the models we produce are soundly based in the Unified Modelling Language (UML) and feature use cases from the outset thanks to our unique requirements pattern language.
Phase I
- Articulating the business case: through interviews and information gathering to produce the first requirements representation in a high level UML model aimed at project sponsors.
- Refining the requirements: after securing sponsor support, refining the model to the point where it can be presented to users for verification.
- Securing internal stakeholder support: Presenting the requirements model to check the correct system is being specified. This stage provides builds confidence.
Phase II
- Managing the list of suppliers from a long list of those who sound promising to a short list who are invited to give demonstrations. There are normally many companies who could provide a solution to a generic-type of problem. The challenge is whittling those many down to a manageable few who have the best chance of providing an efficient solution with the right architectural fit and acceptable commercial terms.
- Defining the scenarios that the demonstrations must satisfy: Demonstrations by potential suppliers are pre-defined so they show what you want to see not the bells and whistles of a particular product. The 'nice to have' features are relegated to their proper place, while the core workflow your employees need to accomplish is brought to the fore. This stage guarantees all demonstrations are easily comparable.
- Producing a scoring system to judge demonstrations: after each demonstration a round table discussion results in all attendees participating in an evaluation of the demonstration they have witnessed.
- Making a decision: Once all the demonstrations have taken place, the results of the individual scores can be tabulated to produce a recommendation as to which supplier should be chosen. Evaluating price; out of the box functionality versus configuration costs. Balancing the business case for non-standard behaviour with the cost of customisation. Negotiating the modification of business workflow to accommodate a product implementation (where appropriate)
Phase III
- Contract negotiations including unambiguous functional contract terms based on use cases: After a winner is chosen, the functional model forms a valuable artefact of the contract that is used to manage delivery milestones, to judge successful implementation and as the basis of user acceptance testing.
- Mechanism for dispute resolution: In the event of contract dispute the procurement model is valuable in acting as the measure of functional requirement. It is the basis of dispute mechanism and the cornerstone of change management as the project progresses.
Active Requirements have proven experience in Procurement Management. You can engage us to undertake the complete lifecycle through to system delivery, or you can select to have us work with you on a phased basis. Typically, Phase I takes between 3 — 4 weeks. Phase II takes between 4 — 6 weeks. Phase III takes 3 — 4 weeks. These timescales are approximate. The cost of an assignment varies with the complexity of the task. Cost is based on the time involved and the value of the final implementation.