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 could not buy anything more modern.
It came from a teacher named Fred at the end of my first computer class. I had 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 did not validate my assumptions, I did not write a statement of work, and I did not 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 did not 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 had 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 could not buy anything more modern.
Looking back at it, I did not validate my assumptions, I did not write a statement of work, and I did not 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 have 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 did not 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 is different in Build a Profitable Consulting Practice?
It is 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, which is 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 is a chapter on using AI for your projects, which did not exist in the first edition because the tools did not.
The subtitle is the business skills they do not teach you, and that is the honest description of the contents.
Who is Build a Profitable Consulting Practice for?
People who can already do the work.
It will not 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 is the audience. Competent people about to make expensive mistakes that nobody warned them about.
What is the single most important chapter in the book?
Record everything, and I say so in the text.
Documentation is what separates professional consultants from amateurs. I have 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 is 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 was not being right. It was having written down what had been agreed and when.
Why does the book say never 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.
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, which is the only way anybody seems to learn it.
How do you handle a client who does not 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 are 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 has to be established in the first interaction, before there is anything at stake, which is 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 do not carry and cannot 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 the book?
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, which is 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 had 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 would 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 had never written down.
Why does the book lead with 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 would rather a reader pay for the book than pay the way I paid.
The projects that went right are in here too, and they are less interesting. They went right because I finally did the boring things in the correct order.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.