Designing reusable solutions: Here's what to keep in mind

One of the holy grails of the consulting business is the reusable solution. You know... build once and sell many, especially if you can build the first version on the customer's dime. Here are the factors to consider when designing reusable solutions.

Many consulting practices have been built by developing a specific solution for one client or building a few solutions for clients in a specific industry, which then become the basis for a product or service with wide appeal across that industry. This usually occurs by chance. For example, a consultant gets hired by one pharmaceutical company and then another; soon she's developed industry expertise, and she incrementally creates a unique product or service that fits the entire vertical. Sometimes it occurs on purpose. For example, a high-tech company realizes that its innovative new product isn't very useful without a sophisticated service offering to help the client plan and install it, and so a solution is developed and then taken to market.

Combining elements for a pre-built IT solution

Pre-built IT solutions can be broad and horizontal, or narrowly vertical, or focused on a specific technology rather than a vertical industry.

When we talk about a pre-built IT solution, what do we mean? Typically, we're discussing a combination of elements (usually hardware, software, and services) that deliver a capability to a client in a consistent and disciplined manner. For example, a "packaged" tax write-up solution for an accounting firm could include the servers, desktops, printers, and scanners required to host the solution; the tax write-up software and its associated maintenance and upgrade services; and the assessment, planning, and implementation services required to get it all up and running. It also often includes the user training and operational support required to keep the solution running. A complete solution in this scenario would include the following:

  • Solution architecture
  • Sample proposal and scope of work
  • Sample project plan
  • Resource roles and responsibilities plan
  • Materials list
  • Hardware and software maintenance contracts
  • Support process
  • Training and knowledge transfer plan
  • Documentation

Clearly, the development of a solution is not a trivial task, and consultants who have deep familiarity with the particular industry or technology they're targeting are much more likely to have the experience required to navigate all of these components.

Pros and cons of reusable solutions

The creation of reusable (and re-saleable) solutions has some advantages, as well as some pitfalls, for IT consultants. The advantages may be fairly obvious, but the pitfalls may not be as evident. Here's a look at both.


Consultants can learn-by-doing while working on billable projects for clients, and then can take the fruits of that labor and use them as the basis for a solution that benefits the entire vertical market. The better you do at the basics of scoping, planning, and documenting your activities on every project, the more likely you are to have the basic elements required for a solution, such as pre-written project plans, proposals, and resource and materials lists.

You can also utilize good knowledge management techniques for building solutions, such as capturing the experiences, tips, tricks, and traps that accompany our engagements so they can be incorporated into the solutions we create. It's especially important to carefully observe and record the customer's support needs and experience. Savvy customers are conscious of the need for strong after-sale support, and smart solution providers create an ongoing revenue stream by attaching continuous services to their solution sales.

Pitfalls You need to be conscious of the potential for conflict of interest. The solution you create (for pay) for a specific client should belong to that client subject to the terms of your agreement; also, the inside information you glean as trusted counselors to the client are private and privileged. Any product or service you create must honor the confidentiality of the client's inner workings and cannot be a direct copy of the solution you created for the client (unless the client agrees).

The biggest pitfall is in our own perception. I've observed many IT consultants make the same error when developing solutions: They think they can take the uncertainty and variability out of the consulting relationship. They try so hard to build the perfect solutions (with all the components pre-built and ready-to-wear) that they convince themselves customers will accept a one-size-fits-all solution. While developing pre-built components that can be reused and resold (sort of like a library of C+ functions) can be a great boon to your consulting business, you must never forget that advising clients is a custom business. Each client, culture, industry, and scenario is different, and you tread in dangerous waters if you try to fit the client to the solution rather than the other way around.

Watch out for these traps

By all means, use your deep technical or vertical knowledge to create a solution that brings all the elements together for a clean, crisp engagement that doesn't have to be invented from scratch every time. Just be sure not to fall into these traps: prescribing before diagnosis or changing your mission from serving the client to selling your packaged solution.

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!


Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

Tony Hopkinson
Tony Hopkinson

more like pot of gold at the end of the rainbow. Reusable software is an unreachable myth. Keep this in mind for reusable solutions. The larger / more`abstract the component, the less likely it will fit. Methods, processes, integrations all fine not code above a list box, and that can be iffy. Unless of course you can persuade you client that this (to them) pile of mismatched 'crap' is OK. The reuse mentality is my opinion one of the largest quality failure points in our industry. If you get one buy a lottery ticket, it's your lucky day, other than look at what your client needs, not what it would be really handy if they did need.

Sterling chip Camden
Sterling chip Camden

To my mind, licensing (express or implied) is the most sensitive issue here (but perhaps that's because I work for software companies). It's very important to get that spelled out in your contract so you know what you can and cannot reuse.

Sterling chip Camden
Sterling chip Camden

If that were true, then most of my customers would be out of business -- they typically provide packaged solutions to vertical markets. Yes, some of them do custom mods for their customers -- but the core package remains common. The trick is to correctly analyze what should be reused and what shouldn't.

Tony Hopkinson
Tony Hopkinson

being real ? There are technical justifications for re-use, there are business ones. When it's technically unsound but has a good business argument (for the provider !!!) Which wins? Which poor muppet gets to make it fit? Oh did I answer the question, for you silly me. In my experience the real trick is to convince the customer they should reuse 'your' stuff, so you can make a bigger profit.

Sterling chip Camden
Sterling chip Camden

... it's not the theory, it's the execution that matters. If the problem domain isn't fully understood, either approach will fail. If it is (and you aren't hamstrung by politics or other extraneous factors), then you're likely to make the right decision and get it to work.

Tony Hopkinson
Tony Hopkinson

That's a hard one. Overall cost wise it's much of muchness in my experience. Generally people who go down the lets buy it in route, look at what they are getting for 'nothing'. Those who go down the we don't need that route, first do need it, second believe they understand the problem better, and third have plenty of spare time on their hands. We might need to define exactly waht we are talking about reuse here. If I go buy your stuff, I aren't reusing anything until I buy it again, to use for something similar. That's all about how much of what you need is already there, how easy is it to get the rest, and the criticality of what's missing. It's highly impacted by what (if anything) you have in place, how much it is costing you, what it won't do that you need, and how long it will last. There are situation where either approach will the best or acceptable. It's the assumption that one is better the other based on some previous experience that will leave you flat on your face. reuse = money saved is not always true, nor is write your own...

Sterling chip Camden
Sterling chip Camden

... it is completely unfeasible to develop a purely custom solution most of the time. Some of these applications have been developed over the course of 20 years or more. To write them from scratch would take far longer than the vendor even realizes. I know, because I've seen it attempted. I'm not talking about simple office automation here, or basic accounting (although I'd probably recommend incorporating some packaged software for both of those cases, too). Mature vertical applications incorporate more domain knowledge than any one person even knows. What I've seen happen time and time again is someone will say, "we don't need to buy that package, we'll just write it ourselves." Three years and a million dollars later, they still don't have all the functionality they need, when they could have spent a few thousand in licenses and been up and running in a few weeks.

Editor's Picks