Information Technology and Digital Consulting

01Purpose and scope

• This manual supports the course Information Technology and Digital Consulting. It describes how consultants in this field scope an engagement, assess existing technology and processes, design digital changes, and hand results to client teams who must run them after the advisors leave. It is written for working professionals and learners who will be asked to produce an assessment, a roadmap, a vendor evaluation, or a process redesign for a client.
• The scope covers both internal consulting teams inside larger organizations and external advisory work. It does not cover software engineering delivery, which has its own methods, and it does not replace legal advice, licensed professional judgment, or formal procurement authority. Rules on data protection, record keeping, and public procurement differ by jurisdiction and change over time, so confirm current requirements with the relevant regulator or the client legal team before acting on anything in this manual.
• Consulting work in this area ranges from a two week review of a single application to a multi year program that touches infrastructure, security, customer channels, and staffing. The same basic method applies at both ends, but the depth of evidence, the number of approvals, and the size of the handover change considerably.

02Core principles

• Start from the business outcome, not the technology. A client who says they need a new customer portal usually needs faster order handling, fewer billing disputes, or better visibility into stock. The consultant's first job is to state the outcome in terms the sponsor would recognize and agree to measure.
• Systems exist to support processes. Before recommending a platform, map how work moves through people and tools today, including the workarounds in spreadsheets and shared inboxes that never appear in an architecture diagram. Workarounds often reveal the real requirements.
• Evidence beats opinion. Every significant claim in a findings deck should trace to an interview note, a system export, a log, a contract, or a measured sample. Where evidence is missing, label the statement as an assumption and record who will confirm it.
• The client owns the decision. Consultants recommend, model options, and explain trade-offs, but the accountable executive chooses. Keep that line visible in the documents so that later disagreements do not turn into disputes about who promised what.
• Prefer reversible steps. Pilots, phased migrations, and time boxed experiments let the client learn before committing budget. When a change cannot be reversed, such as a data migration that retires a legacy record store, raise the bar for evidence and approval.

03Planning and preparation

• Begin by identifying the sponsor, the decision makers, and the people who will live with the result. In practice these are often different groups. A finance sponsor may approve the budget, while the operations supervisor who runs the workflow will decide whether the new system is usable. Write the list down with a short note on each person's interest and influence, and agree on who signs off each deliverable.
• Define the engagement boundaries in a statement of work. Name the systems in scope, the business units included, the period covered by the assessment, and the things explicitly excluded. Vague boundaries are the most common source of scope growth, and they make it hard to say later whether a finding was in or out of the original question.
• Build a data request early. Ask for the application inventory, contract and license summaries, recent incident and service desk records, network and identity diagrams, a sample of current process documents, and any recent audit or security assessment reports. Expect delays. Ask for what exists rather than what the client thinks you want, and note gaps as findings in their own right.
• Set up the working environment before interviews begin. Decide where evidence will be stored, how sensitive files will be access controlled, and which template will hold the assumption register and decision log. Agree with the client on a meeting cadence and a single channel for document exchange.
• Plan interviews by role rather than by org chart. Include frontline users, support staff, system owners, and at least one person who has recently left or changed a process. Their accounts tend to differ from management's description, and the gap is usually where the useful findings sit.
• Prepare for the trade-offs before you need them. Identify likely constraints such as budget ceilings, staff availability, change freezes during peak trading periods, and existing contracts with termination windows. Knowing these early keeps recommendations realistic.

04Recommended workflow

1. 1
   : Frame the question. Restate the client problem as a question that can be answered, such as whether the current order management system can support two new sales channels without manual reconciliation. Confirm the sponsor, the decision the work will inform, and the date by which that decision must be made. Write these into the statement of work and get written agreement.
2. 2
   : Establish the current state. Collect the data request, run interviews, and walk through several live transactions with the people who do them. Record how long each step takes, where handoffs occur, and which records are the system of truth. Produce a current state map that the people interviewed can correct before it goes further.
3. 3
   : Assess the existing technology and process. Score each application or service against the criteria agreed in planning, such as fit to process, integration effort, support cost, security posture, vendor viability, and data quality. Use a simple scale with written anchors so that two assessors reach similar scores. Note any findings that rely on a single source.
4. 4
   : Develop options. Typically three options work well: improve the current state with minimal change, adopt a targeted replacement, or pursue a broader platform change. For each option describe the scope, the rough cost range expressed with stated assumptions, the staffing needs, the migration risk, and the effect on the measures the sponsor cares about. Do not present an option you would not be willing to defend.
5. 5
   : Test the options with stakeholders. Walk the decision makers through the options before writing the final recommendation. Ask which assumptions they would challenge and which risks they think are underweighted. Revise the options based on what you hear, and record the changes in the decision log so the reasoning is traceable.
6. 6
   : Recommend and plan the roadmap. Write a recommendation that names the chosen option, the reasons, the conditions under which it should be revisited, and the first three phases of work with owners and dependencies. A roadmap that covers more than eighteen months should be treated as a direction rather than a commitment, and the document should say so.
7. 7
   : Validate and hand over. Where feasible, run a short pilot with a small group of users and measure the result against the baseline. Prepare a handover pack containing the final report, architecture diagrams, configuration decisions, open risks, runbooks, and a list of unresolved questions with named owners. Schedule a close out meeting where the client accepts the handover in writing, and confirm when the consultant's access to systems will be removed.

05Quality checks, risk controls and compliance

• Run a peer review on every deliverable before it reaches the client. The reviewer should not be the author and should check the logic from the evidence forward, not only the formatting. Look for numbers that cannot be reproduced, diagrams that do not match interview notes, and recommendations that do not follow from the findings.
• Keep an assumption register with an owner, a confidence level, and a date by which the assumption will be confirmed or dropped. Assumptions that are never closed have a way of becoming facts in the final report. Review the register at each steering meeting.
• Address information security from the start. Ask for access only to the data needed for the assessment, use client provided accounts with least privilege, and do not copy production records to personal devices or unapproved storage. Where the client follows a formal framework such as ISO/IEC 27001, align the assessment vocabulary with it so that the security team can use the findings directly.
• Treat personal data with care. Interviews, logs, and sample records often contain personal information. Minimize what you collect, pseudonymize where the work allows, and confirm the lawful basis and retention period with the client's privacy function. Data protection law varies by jurisdiction, and the controller and processor roles can change how obligations apply, so rely on the current guidance of the relevant authority and the client's counsel.
• Watch for vendor influence. Consultants often have commercial relationships with software vendors or implementers. Disclose any such relationship in writing, avoid recommending a product based only on partner incentives, and document the evaluation criteria before reviewing vendor responses. Ask for reference customers you can contact directly.
• Plan for lock-in and exit. For any recommended platform, record the data export formats, contract termination terms, and the effort to move away. A recommendation that the client cannot later reverse should be flagged as a high risk decision requiring executive approval.
• Where the work touches regulated areas such as financial reporting controls, health records, safety critical operations, or legal evidence, this guidance does not replace qualified professional judgment, approved internal procedures, or the authorization required from the responsible body. Involve the appropriate licensed or certified professionals and follow the client's governance process for these decisions.

06Collaboration and documentation

• Set up a simple responsibility matrix at the start of the engagement. For each deliverable, name the person who does the work, the person who reviews it, the person who approves it, and the people who must be informed. Revisit it when the team changes, because a matrix written for a discovery phase often does not fit delivery.
• Keep a decision log. Each entry should record the date the decision was made, the options considered, the chosen option, the person who made the decision, and the main reason. Decision logs are the fastest way to answer later questions about why a system was chosen or why a feature was dropped.
• Use working sessions with the client's own staff to build artifacts together. A process map drawn in the room with the people who run the process is more accurate than one drafted alone and sent for comment. It also builds ownership, which makes adoption easier later.
• Write for the reader who will act on the document. An executive summary should state the decision required, the recommendation, and the main risk in plain language. Technical appendices should be complete enough that an internal architect can rebuild the reasoning without the consultant present.
• Version every document and state what changed. Clients often circulate drafts widely, and multiple versions in circulation cause errors in later work. Keep one master location and archive superseded versions rather than deleting them.
• Plan the handover as a deliverable in its own right. The client team should be able to answer routine questions from the handover pack alone. Test this by asking a team member who did not work on the project to find the answer to three questions using only the documents.

07Measures and continuous improvement

• Agree on a small set of indicators before work starts, and set a baseline for each. Useful examples include the average time to complete a key transaction, the number of manual handoffs in a process, the count of severity one incidents per quarter, the percentage of data fields with an accountable owner, and the share of roadmap items delivered on the agreed date. Choose measures the client already collects where possible, since new data collection tends to fade after the consultant leaves.
• Track adoption, not just deployment. A system that is installed but bypassed through spreadsheets has not changed the process. Measure the share of transactions completed in the new system, the number of support tickets about workarounds, and user survey results collected at fixed points.
• Watch for metric distortion. When a team is judged on a single number, it will often optimize that number at the expense of the outcome. Pair each indicator with a counter indicator that would reveal gaming, such as pairing ticket closure time with reopen rates.
• Review performance at defined intervals and feed the results back into the roadmap. Continuous improvement in client settings usually means short review cycles with the owners of each process, a short list of changes with named owners, and a rule that changes are only closed when the indicator moves or the reason is recorded.
• Recognize the limits of measurement. Some benefits, such as better decisions or reduced strategic risk, are hard to quantify in the period of a single engagement. Say so in the report, and describe the leading indicators that suggest the benefit is developing.

08Common mistakes and how to prevent them

• Leading with a tool. Consultants who arrive with a preferred product tend to find evidence that supports it. Prevent this by writing the evaluation criteria before reviewing any option and by having a second assessor score the options independently.
• Skipping the baseline. Without a measured starting point, a project can claim success on any result. Collect at least a sample of current performance data before recommending change, even if the full baseline must wait.
• Unclear ownership after handover. Recommendations that do not name an owner tend to stall. Attach a named client owner to every action in the roadmap and confirm the owner accepts the responsibility in the close out meeting.
• Underestimating data quality. Migration and integration plans often assume clean, consistent records. Sample the data early, measure duplicates and missing values, and include a data remediation phase with its own cost and timeline when the sample shows problems.
• Overpromising benefits. Savings and productivity gains quoted without assumptions invite challenge and erode trust. State each estimate with its basis and a range, and show what would have to be true for the estimate to hold.
• Ignoring the people side of change. A new system changes roles, approvals, and skills. Include training, communication, and support arrangements in the plan, and ask frontline staff what would make the change harder for them.
• Scope drift without a change request. Small requests added informally accumulate into a different engagement. Route every addition through the agreed change process, with an effect on time, cost, and deliverables stated before work begins.

09Practical checklist

• Confirm the sponsor, decision makers, and the decision the work will inform, and record them in the statement of work.
• Write the scope boundaries, including systems, business units, period, and explicit exclusions.
• Issue the data request early and log every gap as a finding or an open question.
• Interview frontline users and system owners as well as managers, and correct the current state map with them.
• Score options against criteria written before any vendor or product review.
• Keep the assumption register and decision log current, with named owners and closing dates.
• Obtain peer review on every deliverable and check that recommendations follow from the evidence.
• Confirm privacy, security, and records requirements with the client and current authoritative guidance for the jurisdiction.
• Set baseline measures and paired counter measures before any change is implemented.
• Complete a handover pack, test it with a team member who did not work on the project, and obtain written acceptance.

★Learning sources

• Micro Degree: Information Technology and Digital Consulting
• Micro Degree: Leadership and Team Management
• Micro Degree: Business Intelligence Management
• Micro Degree: ESG Advisory Services