THE STARTING POINT
A credible timetable explains what must happen and what evidence clears each stage.
Build the timeline around evidence and decisions
A management consultancy project takes as long as the agreed diagnosis, decisions, implementation and verification require. There is no single reliable duration for every UAE business. A focused process pilot can be scheduled very differently from a change involving several locations, unreliable records and new management responsibilities. Ask for a staged timetable with dependencies and review points rather than a confident completion date unsupported by a delivery plan.
The most useful estimate separates working time from waiting time. Analysis might require several days of effort, while collecting the right records or obtaining an owner’s decision takes longer. A proposal that includes only the consultant's tasks can look quick while leaving out the dependencies that determine the actual finish date.
Start with the decision or operating change you need. Then identify what must be true before each stage can begin. This gives you a schedule that can be tested and updated, rather than a date everyone repeats until it becomes impossible.
Separate diagnosis from implementation
Diagnosis establishes what is happening and which constraint deserves attention. It can include interviews, observation, data checks and comparison of representative cases. Its output should be a supported view of the problem and a decision about the next step. If the brief already assumes a solution, allow enough time to test that assumption before committing the implementation budget.
Implementation turns the chosen direction into a working process, tool or management routine. It may involve configuration, training, a pilot, revision and handover. Those activities need participation from the people who will use the change. Finishing the analysis does not mean the business can instantly operate differently.
Make the boundary visible in the proposal. An adviser offering a two-week diagnostic and an adviser offering a complete operational rollout are estimating different products. Compare their deliverables and acceptance criteria before comparing durations. A short project may be entirely appropriate, provided the work left for your team is understood and realistically scheduled.
Map the dependencies that can delay the work
Identify the records, people, systems and decisions required for each stage. A reporting project may depend on agreeing metric definitions before building a dashboard. A process redesign may need observation of a complete customer cycle. A staffing model may require managers to distinguish productive time from total paid hours before the capacity calculation means anything.
Write dependencies as actions with owners and dates. “Data required” is weaker than “Finance manager provides the agreed monthly invoice export by Tuesday, with cancelled invoices identified.” The latter can be checked and escalated. It also tells the consultant what information will actually be available for the planned analysis.
For a UAE team, account for its real working arrangements, customer peaks and staff availability. Do not assume every person or location follows the same operating schedule. When teams work across emirates, site travel and access windows should be part of the plan if physical observation is necessary. Remote meetings cannot substitute for every type of evidence.
Use an illustrative six-week pilot schedule
Consider a hypothetical Dubai business improving the handover from sales to operations. A six-week schedule could be a planning example if the team, records and decision-maker are available. It is not a market benchmark or a promise that every similar business can finish in six weeks.
The first week could establish the baseline and inspect a sample of completed and problematic jobs. The second could map the current handover and agree a minimum information standard. In the third, the team could test the proposed record against old cases and prepare a live pilot. Weeks four and five could run the pilot with one service line and review exceptions. The sixth could evaluate adoption, revise the process and agree the next rollout decision.
Notice what this plan includes: time to observe real use. If the business handles only a few relevant transactions each week, the pilot may need longer to produce meaningful evidence. Compressing the calendar does not make the sample more representative.
Define the finish line before announcing the date
A project can be “complete” in several different senses. The document may be finished, the process may be ready to test, the pilot may be accepted or the full business may be using it. State which event the quoted end date represents. Otherwise the owner may expect a changed operation when the adviser has only promised a recommendation.
Use acceptance criteria that someone can demonstrate. For a management reporting project, the relevant manager should be able to reconcile the figures and use the report in a decision meeting. For a new scheduling process, the team should be able to handle representative exceptions without relying on the consultant to interpret every instruction.
Include a handover stage with a named owner. Explain where the working files, definitions and decision records will live. A project that ends with nobody responsible for maintaining the new process has reached an administrative finish, but not a durable operating result.
Decide what can genuinely run in parallel
Some work can happen at the same time. While finance checks the starting figures, operations may map the current process. Training materials may be drafted while a pilot is being prepared. Parallel work can shorten elapsed time when the activities are sufficiently independent and the people involved have capacity.
Other work should remain sequential. Building a dashboard before agreeing the decisions it supports can create avoidable rework. Training the whole team before testing a process can spread an error quickly. Do not compress the schedule by removing a learning step simply because the chart looks cleaner without it.
Our business process improvement guide explains how observation, redesign and testing connect. Use that sequence to challenge the timetable. Ask which activities can safely overlap, which depend on validated findings and what the team will do if the pilot reveals a different problem from the one initially expected.
Protect time inside the business
The consultant's availability is only one part of the schedule. Your sponsor must make decisions, managers must review proposals and staff must test the change alongside normal work. If those commitments are not reserved, the project competes with urgent customer issues and usually loses.
Estimate internal effort by role. An operations manager may need time for observation, a design review and a pilot meeting, while a finance colleague may need time to reconcile one dataset. These are different commitments. Asking everyone to “make time when needed” hides the workload and makes delays seem like a surprise.
Where capacity is tight, reduce the initial scope. One location, service line or customer segment can provide a practical pilot. Our change management plan includes ways to organise adoption and feedback. A smaller change that gets used can provide a stronger foundation than a wide rollout that the team has no time to absorb.
Review the schedule using evidence
At each review, distinguish completed activity from cleared dependencies and accepted outputs. “Interviews completed” does not mean the diagnosis is agreed. “Dashboard built” does not mean its numbers reconcile. Tracking these differences helps the sponsor see where progress is real and where a later stage remains exposed.
If a milestone slips, record the cause and the impact on the critical sequence. A delayed interview may be absorbed if other analysis can proceed. A delayed system access decision may stop the pilot entirely. Update the forecast completion date rather than leaving the original date unchanged and hoping the remaining work will fit.
Maintain a short decision log. Record what was decided, by whom, on what evidence and whether it changes scope or timing. This prevents the team repeatedly reopening settled questions. It also makes a revised timetable understandable to people who were not in every working meeting.
Ask for a timetable that survives contact with reality
Before approving a schedule, check that it contains a baseline, decision points, implementation work, representative testing and handover. Ask what assumptions support the duration and which delay would have the largest effect. A credible adviser should be able to explain the logic, not just point to a proposed completion month.
Build contingency around known uncertainty rather than adding an unexplained cushion to every task. If data quality is unknown, make the first review decide whether cleaning is required. If adoption is the risk, reserve a period for observing use. Contingency becomes useful when it has a purpose and a trigger.
Activ-8's management consultancy services start from the business decision and the delivery conditions around it. A good project timeline makes those conditions visible, gives the team a realistic sequence and tells the owner what evidence to expect at each stage.
