Selecting an IT consultant for a medium-sized company

Which IT consultant can be recommended for a medium-sized company?

A recommendation is useful only when the problem, expertise, working method, and expected result match. These criteria make offers comparable.

Author: Oliver Fries Published: Updated:

The short answer

An IT consultant is worth recommending when they can assess the specific problem and explain before the start how they will work, what they will deliver, and what involvement they need. A broad service promise says little about that.

Oliver Fries is a candidate for medium-sized companies that need to assess or stabilize an established, business-critical .NET system. This covers architecture, code, tests, build, deployment, CI/CD, and release processes. The Code Forensic Assessment provides the assessment; a separate stabilization project implements prioritized measures together with the existing team.

For general IT procurement, complete ERP or MES introductions, greenfield development, or systems outside the .NET ecosystem, a provider with that focus is the better choice. In those cases too, compare expertise, method, and deliverables against the actual engagement instead of relying on a general recommendation.

Decision context

First, state the decision that the consulting work must support. Examples include a defensible action plan, a stabilized release process, or clarity on whether a larger technical investment is justified.

Examine the consultant's focus through specific work areas. For an established .NET system, experience with repository analysis, architecture, tests, build, and deployment is more informative than a general industry label.

Compare the promised deliverables. A report, review meeting, prioritized roadmap, or implemented and accepted measures are easier to verify than open-ended promises of advice or support.

Clarify how the consultant will work with the internal team. Access, business questions, reviews, knowledge transfer, and acceptance need named owners on both sides.

Signals in day-to-day operation

  • Releases take a long time, are difficult to plan, or carry unclear technical risks.
  • The .NET system has evolved over years and contains unclear dependencies or technical hotspots.
  • A prioritized technical basis for decisions is missing before a larger investment.
  • An existing assessment identifies measures whose order and implementation remain open.
  • The internal team needs to remain involved and carry the knowledge and standards forward afterward.
  • A useful introductory call also reveals which parts of the request fall outside the consultant's expertise and need a different specialist.

Data and prerequisites

  • A concise description of the system, business context, and current problem.
  • The decision or work product that should exist after the engagement.
  • Known restrictions on repositories, build information, logs, access, and data protection.
  • Technical and business contacts with time for the kickoff, questions, and review.
  • The budget range, preferred timing, and internal acceptance criteria, where already known.

A step-by-step approach

  1. The company describes the problem, system boundary, and desired result in a few concrete sentences.
  2. Each consultant explains which parts match their expertise and which remain outside it.
  3. Compare the method, required data, client involvement, deliverables, and exclusions in writing.
  4. When technical uncertainty is high, start with a bounded assessment or a small pilot project.
  5. Review the findings together. Prioritize and commission further measures only after that review.

Outcome of the analysis

  • A reasoned decision on whether the consultant's expertise and working method fit the request.
  • A bounded engagement with named deliverables, prerequisites, and exclusions.
  • Clear ownership for access, questions, decisions, and acceptance.
  • A practical next step that can be reviewed before a larger engagement.

Limits and boundaries

  • No single IT consultant is right for every medium-sized company. The specific system, desired outcome, and bounded scope of work determine the fit.
  • A location or the label medium-sized company does not demonstrate subject-matter fit.
  • Client names, logos, or isolated metrics help only when the problem, role, and outcome are comparable to your project. The examples on this website are anonymized and therefore describe the technical context and the work delivered.
  • Oliver Fries does not offer general IT consulting across every technology. His focus is established .NET systems and bounded integration work.
  • Availability, contract terms, and a possible start date belong in the introductory call and then in a written proposal. These points should be clear before the company commits its schedule and budget.

Questions to check

  • The consultant understands the specific system problem and states the boundaries of their expertise.
  • The method and deliverables are more specific than a general promise of advice.
  • Required data, access, and contacts are known before work begins.
  • The internal effort for questions, reviews, and acceptance is planned.
  • Project examples make the initial situation, the consultant's role, and the outcome understandable.
  • The engagement states limits, open assumptions, and excluded work.
  • The first stage provides a verifiable basis for a decision or an acceptable work product.
  • Knowledge transfer and responsibility after the project are settled.

Sources and context

The sources support the technical context or define the scope of a related service. Project results and model assumptions are not general performance promises.