Systems diagnosis and review

The review starts with the process. We sit with the people who run it and look at where each step begins, in which program it ends and how many times someone types the same data in by hand. We record every place where work waits, with its cause: a system setting, a missing connection, a missing function, or a way of working that no system will fix.

Then we look inside each system. We record its version, the person who maintains it and the cost of the licence, that is, the right to use the program. We establish where data on customers, orders and billing sits, which system is its source and where the same data sits in two places. We examine the integrations, the connections through which systems exchange data on their own, and list the exchanges that rely on a person with a spreadsheet instead of a connection.

We also check what the board rarely asks about. Administrator access, meaning full control over a system: who has it and whether that person still works for the company. Backups, a copy of the data in case of failure: whether one exists and whether anyone has ever restored data from it. The system version: whether the vendor still supports it. The supplier contract: what it says about changes and about the data once it ends. The source code of custom-built software, the text of the program without which nobody but its author can make changes: whether the company has it.

The review produces a description of the current state in three lists: what works and stays, what slows work down and why, and what can be put to use without a new system. On that basis we write a scope recommendation: one path and a list of work in order, even when that path is a change of settings or of the way people work. The implementation schedule is a separate scope: the step-by-step implementation plan.

1. We agree the scope, deadline and price. After a free conversation you receive the scope of the review: which processes, which systems, how much of your people's time we need. We sign an NDA, a non-disclosure agreement, and only then ask for access. Outcome: a fixed scope, deadline and price before the review starts.
2. We examine the process and the systems. We talk to the people who run the process, get read-only access to the systems and read the supplier contracts. Outcome: a list of systems and a map of data and connections.
3. We assess what can be put to use. For each cause of delay we establish whether it can be removed in the systems you already have. Outcome: a description of the current state and a list of matters to deal with straight away.
4. We hand over the recommendation. We discuss it with you and the board, and the documents stay with your company. If you order the implementation, the cost of the review is credited towards it. Outcome: a scope recommendation on which you can base the implementation decision.

1. Does the review contractor also sell implementation, and is “build nothing” a possible recommendation from them?
2. Which systems does the contractor need access to, is read-only access enough, and what does it do with the data once the review ends?
3. What exactly will we receive at the end, and can the board read it without an interpreter from the IT department?
4. How much of our people's time will the review take, and does the contractor want to talk to the people who run the process?
5. Is the price of the review fixed and known before the start, and what happens to it if we order the implementation?
6. Can another contractor use the description of the current state if we give the implementation to someone else?

This review is the analysis we start every project with: you know the scope and price after the first conversation, and after the review you have a description of the current state and a recommendation for the implementation decision.