My first consulting job was fixing bugs in general ledger programs on a TRS-80 with sixteen kilobytes of memory and two floppy drives, and at the time you couldn’t buy anything more modern.
It came from a teacher named Fred at the end of my first computer class. I’d arrived late to registration that semester and the only courses left were a couple of computer classes with funny sounding names, long before computers were cool. I was hooked by the end of the first day.
Looking back at that job, I didn’t validate my assumptions, I didn’t write a statement of work, and I didn’t terminate the contract when I found myself in over my head. Every failure mode in this book is sitting in that one engagement.
Decades later I went into consulting properly, carrying twenty years of corporate experience and the confidence that I could solve problems for clients. What I didn’t have was any understanding of how to run a consulting business. The technical work came naturally. The business side nearly destroyed me.
What was the first consulting project?
Fixing bugs in general ledger programs for a fee, before I knew what a statement of work was.
It came from a teacher named Fred, at the end of my first computer class. I’d arrived late to registration that semester and the only courses left were a couple of computer classes with funny sounding names, long before computers were cool. I was hooked by the end of the first day.
The machine was a TRS-80. Sixteen kilobytes of memory, two five and a quarter inch floppy drives, and at the time you couldn’t buy anything more modern.
Looking back at it, I didn’t validate my assumptions, I didn’t write a statement of work, and I didn’t terminate the contract when I found myself in over my head. Every failure mode in the book is in that one job.
The book on this: Build a Profitable Consulting Practice is the business half of consulting that nobody teaches: pricing, contracts, scope, reading clients, and what to do when a project goes wrong.
What makes a consulting project fail?
Communication, in more than ninety percent of the cases.
Across forty years I’ve been part of or managed several hundred projects. Some ran an hour. Some ran weeks. Some needed teams of twenty people working for months.
The ones that went badly failed because I communicated poorly with the client. Not because the technical work was wrong, not because the estimate was off, and not because the client was difficult. Because something that needed saying didn’t get said clearly enough or early enough.
The ones that went well did so because communication held between the client, the implementation team, and me, starting during the sales conversation and continuing through the statement of work to the last meeting.
What’s different in Build a Profitable Consulting Practice?
It’s the revised edition of How to Manage a Consulting Project, and the scope has widened.
The original was about running the project. This one is about running the practice. That’s a larger problem. Pricing models and payment arrangements, red flags before you sign, reading a client, controlling change, what to do when it goes south, errors and omissions insurance, outsourcing, virtual assistants, and marketing yourself between engagements.
There’s a chapter on using AI for your projects. That didn’t exist in the first edition because the tools didn’t.
The subtitle is the business skills they don’t teach you, and that’s the honest description of the contents.
Who is Build a Profitable Consulting Practice for?
People who can already do the work.
It won’t teach you technical skills, because you have those. It teaches you how to turn them into a business that serves good clients, generates fair profits, and supports the life you want to have.
That’s the audience. Competent people about to make expensive mistakes that nobody warned them about.
What is the most important skill in consulting?
Record everything, and I say so in the text.
Documentation is what separates professional consultants from amateurs. I’ve seen more projects saved by good records and more careers destroyed by poor ones than by any other single factor. If a reader takes one thing out of this book, it should be to write everything down.
Most consultants hate documentation. They treat it as bureaucratic busywork stealing time from the real work. That’s backwards. The documentation is the real work and everything else is implementation.
I learned it on a project that should have been simple and turned into a legal nightmare. A small software company hired me to build a customer relationship management system, and what saved me wasn’t being right. It was having written down what had been agreed and when.
Should a consultant ever work for free?
Because free work is the fastest way to destroy a consulting practice.
It devalues your expertise, attracts the wrong clients, and consumes hours that could have produced revenue. The only exception I allow is a school internship, where the educational value justifies it.
The only exception I allow is a school internship, where the educational value justifies it.Share on X
Most consultants fall into it the same way. A prospective client promises future projects, or referrals, or a long-term relationship, in exchange for something now. Those promises almost never materialise and you end up doing real work for imaginary compensation.
I learned that one expensively too. That seems to be the only way anybody learns it.
How do you handle a client who doesn’t respect you?
By understanding that you trained them.
Respect is the foundation of every consulting relationship that works. Without it, projects become power struggles, communication degrades, and the outcome suffers regardless of technical competence.
Most consultants tolerate disrespect because they’re afraid of losing the client or creating conflict. That approach fails for a specific reason. You train clients by what you tolerate. Accept rudeness, unreasonable demands, or unprofessional treatment early and it becomes the standard for the whole engagement.
It’s to be established in the first interaction, before there’s anything at stake. That’s precisely when nobody feels able to raise it.
What else is in Build a Profitable Consulting Practice?
The unglamorous middle of running a practice.
Errors and omissions insurance, which most independent consultants don’t carry and can’t explain why. Controlling chaos as a distinct skill from controlling change. Reading a client. Advanced stakeholder management. What happens at the end of a project, which is a chapter because most people handle it badly.
Then the modern additions. Outsourcing, virtual assistants, using AI on projects, project management tooling, CRMs, and offering AI consulting as a service line.
And marketing yourself between projects, along with testimonials, referrals and recommendations, because the gap between engagements is where a practice is either built or quietly lost.
How did Purdue University end up using Build a Profitable Consulting Practice?
Professor Richard Makadok assigned it at the Krannert School of Management, and then kept assigning it.
His course put students into field-study projects with real clients. That’s where the gap the book exists to fill opens. A student can be technically capable and still walk into a client relationship with no idea how any of it works.
He wrote afterward that the book had helped his students avoid subtle pitfalls in those client relationships, and that he’d assigned it again the following year. The second assignment is the part that meant something to me. Anybody can try a textbook once.
Then he asked whether I’d take questions from the class. That started as a video call and turned into a standing arrangement, and I lectured to that class across four years, from 2016 through 2019.
Those sessions changed the revision. Students ask the questions practitioners have stopped asking because they have quietly decided the answer is obvious, and several chapters exist because a twenty-two-year-old wanted to know something I’d never written down.
Why learn from consulting failures instead of wins?
Because the failures are where the content is.
A book of successful projects teaches nothing transferable. Every one of the lessons in this book came from a specific engagement that cost me something, and I’d rather a reader pay for the book than pay the way I paid.
The projects that went right are in here too, and they’re less interesting. They went right because I finally did the boring things in the correct order.