The $80,000 Migration That Nearly Broke Us
I've managed projects across half a dozen industries over the past decade, but nothing prepared me for the first time I ran a consulting engagement for a mid-size logistics company. The project seemed straightforward on paper. Migrate their legacy inventory system to a modern cloud platform. Six-month timeline. Three-person team from our side. Clear deliverables.
By month four, we were behind schedule, over budget, and the client's CTO had stopped returning my emails. Not because we were incompetent. Because I managed it like a normal project, and IT consulting is not a normal project.
The scope had shifted seventeen times. Not because the client was unreasonable, but because every time our developers opened up another layer of their legacy code, they found something nobody had documented. Hardcoded business rules from 2009. A custom cron job that silently synced inventory with a supplier's FTP server every night. Three database tables that were identical except for one column that turned out to be critical for their tax reporting.
We had estimated the migration based on what we could see from the outside. The reality underneath was a different animal entirely. And that right there is the first thing that makes IT consulting different from almost any other service business.
Technical Scope Uncertainty Is the Default, Not the Exception
In most service businesses, you can scope the work with reasonable accuracy before you start. A marketing agency knows roughly how long a brand identity project takes. An architecture firm can estimate a residential renovation within a reasonable margin. The deliverables are visible and relatively predictable.
IT consulting doesn't work that way. You're almost always walking into someone else's technical environment, and you never fully understand it until you're deep inside it. The client usually doesn't fully understand it either. Their internal team built it over years, one patch at a time, and the person who made half the architectural decisions left the company in 2021.
This means your project plan is partly a guess. I don't say that to be cynical. I say it because accepting this reality changes how you need to manage.
What I've learned to do is build what I call "discovery buffers" into every engagement. Instead of estimating the whole project upfront, I break it into a paid discovery phase (usually two to four weeks) and then the implementation. The discovery phase has its own deliverables: a technical audit, a risk assessment, and a revised project plan based on what we actually found. Not what the client told us during the sales call. Not what their documentation says. What we found when we opened the hood.
This costs me deals sometimes. Some prospects want a fixed bid upfront and don't want to pay for discovery. I've learned to let those deals go. The ones who insist on a fixed price for an undefined scope are the ones who become nightmare clients. Every time.
The Client Knowledge Gap Problem
Here's something that doesn't happen when you're building websites or running marketing campaigns: in IT consulting, your client often cannot evaluate your work. They hired you precisely because they don't have the expertise in-house.
This creates a strange dynamic. A marketing client can look at a brand design and say "I like this" or "I don't." A construction client can walk through the building. But when you tell an operations director that you've implemented a microservices architecture with event-driven communication, they're taking your word for it. They can't independently verify whether you made good decisions.
This sounds like it would make things easier. It doesn't. It makes them harder.
Because the client can't evaluate the technical work, they evaluate what they can see: timelines, responsiveness, communication, and whether the thing works when they click on it. Brilliant architecture that's delivered late looks worse to most clients than mediocre architecture delivered on time. I've watched excellent technical teams lose clients because they spent three extra weeks doing things "the right way" without explaining why it mattered.
The fix is translation. Constant, proactive translation of technical decisions into business language. Instead of "we're refactoring the data access layer," say "we're restructuring how the system retrieves data so it handles 10x your current volume without slowing down." Instead of "we found technical debt in the authentication module," say "the login system was built with some shortcuts that create security risks, and we need to address them before launch."
I now spend about 20% of my management time just translating. It feels like overhead, but it's the single most impactful thing I do for client satisfaction.
The Handoff Problem Nobody Talks About
Every consulting engagement ends the same way: you build something and then hand it to the client's team to maintain. This is fundamentally different from a product company, where you build and maintain. In consulting, your exit is part of the deliverable.
And most consulting firms botch the handoff completely.
I did, repeatedly, for the first few years. We'd build a beautiful system, deploy it, write some documentation, do a quick training session, and then move on to the next client. Within six months, the client's team would call us in a panic because something broke and nobody knew how it worked.
The logistics company I mentioned earlier? After we finally finished the migration (two months late, $15,000 over budget), we did exactly this. Wrote a 60-page technical document. Did two half-day training sessions. Shook hands and left.
Four months later, their junior developer accidentally dropped a database index during a routine maintenance task. Their system slowed to a crawl. They called us in a panic at 10 PM. We spent eight hours fixing it remotely. We didn't bill them for it because we felt responsible. That was an expensive lesson.
What I do now is build a structured handoff phase into every project. Not just documentation and training. An actual transition period where their team operates the system while our team is still available. Usually three to four weeks. During that time, their developers handle everything, but they can call us within two hours if they hit something they can't solve.
I also changed how we document. Instead of comprehensive technical docs (which nobody reads), we create what I call "runbooks." Short, scenario-based guides. "If the nightly sync fails, check these three things." "If a user reports slow search, run this query to check index health." Practical, specific, and tied to problems they'll actually encounter.
Managing Concurrent Technical Projects
Most IT consulting firms run multiple engagements simultaneously. That's how the business model works. But this creates a staffing challenge that's uniquely difficult in consulting.
Your senior architect might be 60% allocated to one client and 40% to another. But both clients think they have a full-time person. And when both projects hit a critical issue on the same Tuesday afternoon, someone gets prioritized and someone waits. The one who waits notices.
I've tried a few approaches to this. Dedicated teams per client work best but only if you have enough people and enough large engagements to justify it. Shared resources are more realistic for small firms, but they require ruthless transparency about allocation.
What I've settled on is what I call "core plus flex" staffing. Each engagement has a core person (or persons) who are 80% or more dedicated to that client. Then we have flex people who rotate across projects for specialized tasks. The core person is the face of the engagement. They attend every meeting, they know the client's business, they own the relationship. The flex people come in for specific technical tasks, do their work, and move on.
The key is that the client always has one person who is "theirs." Someone who picks up the phone, who knows the history, who doesn't need to be brought up to speed every time there's a conversation. Even if the actual coding is done by different people at different times, the relationship is anchored to that core person.
Documentation Requirements Are Different
I mentioned runbooks earlier, but the documentation challenge in IT consulting goes beyond that. Unlike internal projects, where documentation is a nice-to-have, consulting projects have documentation as a contractual obligation. You're building something for someone else. If you leave and they can't understand it, you failed.
The problem is that most developers hate writing documentation. And the documentation they do write tends to be either too technical (architecture diagrams that only another senior engineer would understand) or too superficial (README files that say "run npm install and then npm start").
I've found that the best documentation for consulting engagements falls into three categories:
Decision records. Why did you choose this technology? Why this architecture pattern? Why this database design? These are the questions the client's team will ask six months from now when they need to make changes. If they don't know why you made a decision, they'll either be afraid to change anything or they'll change things they shouldn't.
Operational runbooks. I already mentioned these. Step-by-step guides for the scenarios they'll encounter. Deployment procedures, monitoring and alerting, common troubleshooting, backup and recovery. These should be written for the skill level of the person who will actually use them, which is usually not as experienced as your team.
System context maps. Not detailed architecture diagrams. High-level maps that show how things connect. "This service talks to that service through this queue. This database is read by these three applications. This API is called by the mobile app and the web dashboard." When something goes wrong, the first question is always "what touches what?" A good context map answers that in 30 seconds.
What Would Have Saved That First Engagement
Looking back at the logistics company migration, almost everything that went wrong was predictable. Not the specific technical surprises, but the categories of risk.
A paid discovery phase would have uncovered the legacy code complexity before we committed to a fixed timeline. Better client communication would have kept the CTO engaged instead of frustrated. A structured handoff would have prevented the database index incident. Honest scope management would have turned those seventeen changes into documented change orders instead of silent scope creep.
IT consulting is not harder than other service businesses. It's different. The technical uncertainty is higher, the client knowledge gap is wider, and the handoff is more complex. But all of those challenges have solutions. They just require you to stop managing consulting engagements like regular projects and start managing them for what they actually are: temporary partnerships where you're building something you won't own.
That shift in mindset changed my practice more than any tool or methodology ever did.
