How IT consulting in Atlanta changes how a business operates versus just producing documentation

A business owner once showed me a binder. Inside it was a 47-page technology assessment from an IT consulting engagement they’d done eighteen months earlier. The assessment was thorough — it covered their network infrastructure, their software stack, their security posture, and their vendor contracts. It had recommendations organized by priority. It had a timeline. The owner was not fully aware of why they did not do much of it in the business, or why it didn’t work in the business.

Many Atlanta business owners have had this experience with IT consulting. A detailed deliverable is handed over, left on a shelf, and the business goes on as usual. The consulting firm is paid, the relationship ends, the binder is a symbol of a problem that never got solved.

That is actually different from consulting that just uses that as a way to change how the business operates.

Where the difference shows up

The shift from documentation to operational change isn’t just about follow-through. It’s about whether the consulting relationship is structured around implementation accountability or around advice delivery.

Once a consultant has created his report and given it to the other person, he’s finished. It is up to the client as to what should occur after that. However, if a consulting relationship is set up based on outcomes, the questions no longer are “here are your recommendations” but “here is the change, and here is the sequence, and here are the people responsible for the change.

This difference is of more importance than the quality of analysis itself for many businesses. A diagnosis that is flawed and results in no change is less useful than a diagnosis that is less than perfect but leads to 10 changes in the world.

The planning conversation that most businesses skip

Most IT consulting engagements begin with discovery — a review of the current environment, conversations with leadership, and sometimes interviews with key staff. It’s what happens once the findings are put together that changes.

In a documentation-first model, findings get organized into a report. In an operationally-focused model, findings get organized around decisions that need to be made. The difference is that decisions have owners, timelines, and dependencies in a way that findings typically don’t.

This planning discussion (where findings become decisions) often goes unaddressed or is limited. It needs another conversation than the one of the technical review itself. Which person/office is authorized to approve a budget for a given change? What other measures will be in the competition for the resources that are being provided internally? Does the person who would implement this change have time to do so,o or is he/she working on some other project for the next two months?

Providers of IT consulting to Atlanta businesses often describe this phase as the hardest part of the engagement because it requires the consulting firm to do something uncomfortable: hold the mirror up to organizational constraints that have nothing to do with technology.

What operational change actually looks like

Good business consulting is evident when the business owner begins to see a difference in decision-making, rather than technology.

• The decision on who to buy from begins to be made on a documented basis so that priority and persistence of the salesperson is not a factor. It might sound trivial, but it has an impact on the quality of the contract over time,e as the criteria are in writing and people can go back to it.
• Predictable, not reactive spending on IT. IT spending that’s “reactive,” meaning that it is assigned after something breaks because of a compliance deadline or other events, is always more costly than planned IT spending. A technology roadmap generated by consulting also provides operations managers with a roadmap to follow when creating annual budgets, changing the dynamics with finance leaders.
• The business creates its own vocabulary in the process of making decisions about technology. Discussions about technology get quicker and more effective when non-technical staffers grasp the concepts and why uptime is a key driver of revenue, or what exactly a data retention policy actually controls. This sort of common terminology is not a report; it’s a result of sustained communication between the consulting relationship and the business operators.

The integration problem

When documentation doesn’t lead to change, it’s often in software integration. An assessment of the technology may reveal that three systems are in use, which could be consolidated into a single system, or that two systems are not automatically exchanging data and are leading to manual re-entry somewhere downstream.

The finding is very easy to create. The implementation will need to have an owner, liaise with suppliers, verify that the integration works in a test environment, educate users whose workflow will be changing,g and iron out the wrinkles when two software systems are first linked.

All this doesn’t happen because of a report. This occurs because someone with the proper technical expertise remains involved with the project implementation and considers the project to be complete when the integration process is functioning effectively, and the manual re-entry does not occur, not when the recommendation is transmitted.

What to look for in a consulting relationship

Every business isn’t necessarily going to require the same level of involvement. If the aim is operational change, not documentation, however, there are some things that should be there at the outset of the relationship.

• It is important to discuss clearly with the client who will take on each of these recommendations. In the absence of this discussion, the default is typically “nobody,” and recommendations build up with no action taken.
• A review process should be in place to review recommendations over time. The technology landscape evolves, business goals change,e and what was considered non-essential six months ago may now be more important. There’s a tendency for recommendations made from previous engagements not to be reprioritized without a cadence for them to be reviewed.
• The consulting firm should be able to let you know when it’s not working out. Any implementation that is not proceeding as intended, or in an implementation where a recommendation from the original assessment proved to be incorrect because of new information, should come up in the relationship – don’t paper it over.

A failure mode, not an inevitable outcome, is the binder on the shelf. The difference is typically one of the goals of the consulting relationship – change vs documentation.