Peace of mind
Offers are comparable, and acceptance is not a dispute over impressions.
Requirements written in the language of your processes, before you launch a tender or send a request for proposals. They make offers comparable and let you hold the vendor to account later.
Questions worth knowing the answer to.
If the answer to any of them is “we don’t know”, that is exactly where I can help. I put these questions to boards, secretaries, county heads and company presidents before decisions are taken and money starts to flow.
- Can we describe to the vendor what the system is to do, in a way that can be checked?
- Which scenarios from our daily work must work without exception?
- What will happen to our data, and how do we exit the contract when we want to change vendor?
- How fast, and with what volume of data, must the system run?
What you get out of it.
Better results
You get what you need, not what the vendor has in its template.
Fewer reefs and mistakes
Fewer fixes after go-live, because the requirements were written before the rollout, not after it.
The cost of a mistake at this stage. Poorly specified requirements mean annexes, fixes after go-live and disputes over acceptance. An advisor usually costs less than a single badly chosen technology, a single wrong vendor or a single trap in a contract.
Requirements are the currency of a conversation with a vendor.
Written in the language of your processes, before you launch a tender or send a request for proposals, they make offers comparable and let you hold the vendor to account later. This is my most important competence: I translate the organisation’s needs into business requirements, scenarios and acceptance criteria.
What you get.
- Interviews, process maps, a data model, integrations and test scenarios.
- Above all, an answer to the question of what counts as success for the rollout: why we’re doing this and what results we expect.
- When the board has an idea but no time to write it up: a concept or a prototype after a single conversation, in about 2 days.
How I work at this stage.
- Interviews and process mapsWith the people who work in the process and with the process owners. The result is a description of the current and the expected state.
- Requirements and scenariosA data model, integrations, views, notifications, rules and test scenarios, including requirements for ease of use, speed and data volume.
- Acceptance criteriaVerifiable criteria that tell you the system works as intended. The vendor receives them before making an offer, not after the rollout.
“He is able to translate the general direction of change into the questions that must be put to individual units, the requirements that must be agreed and the decisions that should be taken by management.”
My expertise at this stage.
I translate the problems reported by business users into a language the IT world understands, and the possibilities of technology into the language of board decisions.
Digital transformation and change management.
This is the key competence that ties all the stages together: over 20 years of work in many organisations, on the client’s side.
Frequently asked questions about this stage.
Why write down requirements before the procedure?
They make offers comparable and let you hold the vendor to account. Without them you compare promises, and acceptance rests on a general impression.
What if the board has no time to write them up?
About 15 minutes of conversation is enough. I come back in around two days with a concept or a prototype on which you can assess the direction before the project generates its first cost.
Let’s talk about this stage.
The first conversation takes 30 minutes and costs nothing. I reply within 2 working days.