Selecting or changing an IT provider
Support needs to change, but the next agreement is still a list of frustrations. Planning names what the business needs covered before a vendor writes the proposal.
Technology Advisory
Technology Planning & Vendor Advisory
A technology change is easier to direct before a vendor's proposal becomes the plan. Planning settles what the business actually needs, which approaches are realistic, and what a vendor should be asked to answer.
01
Situations
When planning helps
Planning fits a change that is still ahead of you, while the requirements or the approach are open.
A migration or a new business system
Email, files, or a line-of-business application need to move, or a new system is under consideration. The useful work is deciding what must carry over, what can wait, and which approaches are realistic, before a product demo sets the requirements.
An infrastructure project that is not designed yet
A network, server, or cloud change is coming, and the scope is still a conversation. Planning turns that conversation into constraints: what has to keep running, who will support the result, and what the project is not trying to solve.
Proposals that should answer your requirements
Vendors are about to be asked for designs, or proposals have started to arrive. Planning writes the requirements first, then reads each proposal against those requirements rather than against the vendor's preferred design.
02
Process
What the planning process can include
The scope is agreed before the work starts. A planning engagement can include:
- The business requirement. What has to change, for whom, and what a successful outcome looks like in the operation of the business.
- Technical and operational constraints. What must keep running, which systems are involved, and limits of time, staff, and existing contracts.
- A comparison of realistic approaches. Practical options set next to each other, including what each one asks of the business after the project.
- Requirements a vendor can answer. A written set of needs so proposals respond to the same question.
- A reading of proposals against those requirements. Where a proposal meets the need, where it adds scope, and what is still unanswered.
- Support and ownership. Who maintains the result, who responds when it fails, and what has to be handed off before the project is treated as finished.
03
Deliverable
What you receive
The deliverable is agreed with the scope. It is written so you can use it:
- Written requirements
- A comparison of approaches
- Questions for prospective vendors
- Practical recommendations
- A plan that can be handed to the people performing the work
A proposal that is already on the table is a different question. That is anIT proposal review. Uncertainty about the systems you already have belongs in atechnology assessment.
How to get started
Describe the change you are considering.
A short note is enough: what is being considered, what is still undecided, and any deadline that matters. I typically reply within two business days to discuss scope and next steps.
Discuss a plan