When everything is urgent, starting becomes difficult
Imagine headquarters requesting a collaboration platform, a factory reporting slow access, support needing old correspondence and IT handling account handovers. Each has a reason, but staffing and change windows are limited. This is a hypothetical example, not a customer case. Choosing by volume of complaints or purchasing convenience may leave important blockers untouched.
Translate product names into problems first. Who is trying to do what, how often is it difficult, and who compensates when it fails? If a request names a purchase but cannot describe the work it should improve, clarify the need before estimating implementation.
Describe impact consistently across sites
For each request, record the affected activity, users, time sensitivity and current workaround. A small site may perform a delivery that every other location depends on. Conversely, a widespread inconvenience is not automatically more urgent than a blocked critical process.
Simple high, medium and low ratings can support discussion if the reasons are visible. Mark uncertainty and arrange a short investigation instead of inventing precise scores. Active serious incidents should follow the incident process rather than wait for a routine improvement meeting.
Identify dependencies before buying
A platform move may depend on clear account and data ownership. A recovery exercise may need a confirmed backup scope and access route. If the list contains only final project names, these prerequisites may have no owner until the purchased tool is ready for acceptance.
Ask what must be known, who must participate and which shared services will change. List common prerequisites separately and distinguish genuine blockers from habitual sequencing. Not every improvement needs a large infrastructure program first; a bounded adjustment may remove the immediate obstacle.
Assign business and technical responsibility
IT can assess methods and limits, but should not decide every department's acceptable business impact. Identify the requester, technical owner and acceptance owner. Establish who resolves conflicts between sites before execution. An unowned request is not ready simply because it appears in a plan.
Allow for busy periods, shifts, time zones and outside parties. Separate ready work, investigations, waiting items and deferred requests, with a review date for waiting items. Priorities should change with evidence rather than become permanent promises after one meeting.
Choose the smallest outcome you can verify
Reduce a broad objective to a testable result: one account group handed over, an important dataset recovered in a rehearsal, or a cross-team handover completed without its original contact. Define the evidence before estimating effort. A purchase order or activated account is not the outcome by itself.
After the pilot, record whether the problem improved, which dependencies remain and any new workload. If the result contradicts the original assumption, adjust before expanding. Different sites need not have identical needs or readiness.
Keep the decision open to new evidence
At the next planning meeting, take three to five representative problems and add impact, dependencies, owners, acceptance and a review date. Start one well-defined improvement while investigating the most significant unknowns. There is no need to settle every technology investment for the year in one session.
ACMI can help assess the scope of IT operations, data protection and improvements across locations. Bring the problem and the basis for prioritizing it so service choices follow the work the business needs to accomplish, rather than a product catalogue.
