Software Development

How much do IT consultants need to know about their clients' business?

Understanding a client's business processes can contribute greatly to the quality of the solutions IT consultants provide. But how much domain knowledge is enough? And how much do you need to know about the end user layer? Find out what Chip Camden thinks.

In the Programming and Development blog, Justin James asks, "Should programmers know more than just programming?" The majority of respondents chose this possible answer to his poll question, "Yes, they should know more about the business and technical side of things." In the discussion, a few members countered that you need specialization in order to get the most out of each individual.

My take is that, the more you know about every aspect of the business, the more effective you are -- regardless of whether you're a developer, an accountant, a secretary, or a CEO. Yes, you need to specialize and obtain a deep understanding of your craft; but if nobody knows what everyone else is doing, the business will come apart at the seams. And developers in particular need to understand all of the related processes within the business that they're attempting to automate.

That's fine for full-time employees who can make time in their busy schedules to learn more about the company, but what about consultants? We might work for several companies in a month, and clients come and go. Furthermore, clients may not be willing to pay our exorbitant hourly fees to teach us about their businesses for very long. Still, understanding a client's business processes can contribute greatly to the quality of the solutions you provide.

How much domain knowledge is enough?

Well, it depends. If users will directly consume what you're working on, you need to know how they will use it. The more you can learn about that domain, the better your design will be. But I misspoke: Your creation will always be consumed by users -- it's only a question of identifying who the user is. In use-case parlance, identify your stakeholders.

For many consultants, the users will be the client's IT department and/or office workers. Most of my clients are software developers, and the type of work I do for them is usually not specific to the applications they're creating (e.g., how do you create this general kind of user interface? or how do you get A to talk to B? or can you use a utility class that does X?). So, for me, the user is a programmer/designer. The application in which they'll use my contribution can also be seen as a user. And occasionally, the specific use cases of the application require that I understand part of the end-user layer as well.

How broadly do you need to understand each layer?

Again, it depends. Separation of concerns is a good practice in programming but also in business processes. How well your client can do that will be inversely related to how involved you'll need to get in order to understand everything you need to know. In other words, even though the business is better off when everyone knows something about what everyone else is doing, it's far worse when everyone needs to know what everyone else is doing. When that's the case, one shaky domino can knock everything down. You'll have to understand all of those interactions, effectively becoming yet another edge in the huge web of dependencies.

But you don't necessarily have to accept the situation; you're within your rights to suggest ways in which concerns can be separated and interfaces simplified and documented within both code and business operations. The latter requires a pretty thorough understanding of the situation, so how can you quickly gain that knowledge?

One technique I like to use is to envision how I think the business works, assuming the processes are well-designed and then ask confirmatory questions. "I presume that you do X, which leads to Y. Is that right?" The client's answer is usually, "Well... not quite." Then I know that we're onto something.

But their explanation is often so complicated that my eyes roll up in my head. When you get an answer that you don't understand, it's generally not a good idea to gloss over it in the expectation that you'll figure it out later; those are almost always the key points that need addressing. As the saying goes, if you can't explain it to Grandma, it's not a good model. So, if your clients can't explain it to you, don't feel stupid -- either their model really sucks, or they're smoke screening.

You don't necessarily have to redesign their whole business, though; your goal is to sufficiently isolate the processes that you need to understand in order to provide your services. If you can get to the point where, for example, you produce a specific document in a rigorously standardized grammar, and you ship it off to some other service, you don't want to need to know what that service will do with the information. Nor should you need to know how the department that owns that service operates, presuming the business concerns are likewise separated.


Your mileage may vary; mine has from client to client. How well your client fosters communication and separates concerns within their business can dramatically affect how quickly you can contribute meaningfully. What are your experiences?

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!


Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...


The simple truth is that you need to know your own business. If your business requires you to have an in depth knowledge of your clients' businesses then that's what you need. If your business requires you to have an in depth knowledge of your clients' systems mix then that's what you need. If your business requires an in depth knowledge of a particular package or programming language ... that's what is needed. In today's world we all need to identify a brand (i.e. niche) that we are going to build a business around. That niche/brand will impose requirements. And those requirements will change. Not so much because the native requirements (i.e. those imposed by the task) change but because the market requirements (imposed by clients) change. My former niche (accounting systems) used to require a knowledge of accounting rules, good/bad practices and an ability to quickly reasearch and understand the client's business and systems. The more versions and the more businesses the better. And you had to have seen enough different systems to know what to look for to identify (potential) connections. Effectively, the client looked to you to apply accounting skills and other peoples' solutions to their problem. In short, to bring an outsider's viewpoint to their problems. Today (at least in my market) the client is looking for detailed knowledge of their particular package in their industry. Being able to suggest solutions they haven't thought of isn't on their radar. The key is to understand your market and your place in it -- and to keep a weather eye peeled on how it is changing. Glen Ford

Justin James
Justin James

At one job, our company had extremely intimate, long term relationships with the clients. Our "competition" was their internal IT department, as well as other vendors. In that scenario, we needed to be very familiar with the client's business, it was a competitive advantage. On the other hand, my employer now is doing a CRM migration. We've brought in a consultant to help. he knows next to nothing about our business, other than the rules related to CRM that he needed to implement. Once he's done with the migration, our only relationship with him will most likely to ask for advice once in a blue moon, and to send holiday cards. I think that a large part of the discussion is the length of the contract and the nature of the work. Open ended or long term contracts require and benefit from a lot more domain knowledge than the, well-defined and/or short-term "come in for 2 months and write these two modules please" style contracts. Which is, I suspect, why this kind of knowledge is much more important to full time employees, too. J.Ja

Sterling chip Camden
Sterling chip Camden

I'm sure we've all worked with clients whose applications are an interwoven monolith, and changing one thing breaks everything else. Those businesses often have organizations that mirror the complexity of their applications. Lace in some politics, and you've got a real mess that can take years to understand thoroughly, never mind fix. But I have been blessed with a few clients who do this well. How about you?

Editor's Picks