6 Ways to ReCoup Costs By Helping Others to Not Reinvent The Wheel - Commercializing Your Project's Assets

Recently, I've been involved with a lot of regulatory and compliance related projects for our clients. These projects are extremely important because they ensure our clients are meeting the checks, balances and constraints that are set by governing bodies to protect consumers.

The problem our clients face is that many of these regulations are subject to interpretation, are constantly changing/evolving and thus there aren't any "off the shelf" solutions that exist to solve many of their problems. So custom solutions (business processes and technologies) are developed to suit each client's specific business need or gap. The funny thing is, all the publicly traded companies in a particular industry often share this same problem or have the same regulation to comply with, and so the same solution gets built 100 different ways. This is great for consulting companies and big accounting/advisory firms, but often a huge cost to clients.

Situations like this are great candidates for the sharing and/or commercialization of project assets. If a solution is architected well (open, flexible, data-driven, etc.) there probably are components or potentially entire solutions that could be reused by other companies trying to solve the same problem. This serves up a win-win since company A (who created the assets) can potentially recoup some costs put into the solution and company B (who still needs to build the solution) can gain some cost savings by getting a jump on the assets that need to be developed.

I'd like to open my blog to your ideas for drafting a set of guidelines on how to identify projects that are candidates for commercialization and then end up with a few approaches on how to bring these assets to the market place. Of course, since this is my blog, I’ll add my two cents as well.

Projects poised for commercialization often fit into one of the following buckets:

1) Projects that solve a problem shared by, but specific to, an industry. The example above of regulatory/compliance related processes is one example (i.e. SOX Compliance initiatives, HIPAA, SAS70, etc). Other examples: Banks all have to move money between accounts, investment firms all want to show aggregated portfolio performance, retailers all need to have a store lookup facility, you get the idea.

2) Projects that extend a packaged enterprise application (i.e. an ERP) to give it more capabilities that others may benefit from. Think how much customization gets done to ERPs over and over again at different organizations. If some thought is put up front in architecting these customizations as "plug-ins", there very well may be other companies interested in leveraging that additional functionality. The same consideration can be given to content managements solutions, enterprise portals, identity and access management systems, BPMs, ESBs, etc.

3) Projects that aren't necessarily giving you a competitive advantage. When it comes to corporate enterprise IT development, it's going to be much harder to convince Product Management stakeholders to resell/release anything that is customer-facing or giving the business an advantage over their competition. For example I don't think Amazon would be too keen on giving away their "Frequently Bought Together" module or Dell would be up for selling it's supply chain automation solution. At the end of the day, you don't want to give away the secret sauce!

I'm sure there are countless other ideas for how to identify resellable project assets, and I'd like to hear about your ideas/experiences in the comments below.

Ok, so let's say you've identified something, now what? In general I feel there are three major approaches to bring these solutions to the marketplace. I'd be interested in your thoughts on other ideas as well:

A) Commercializing the Solution (selling project assets to other firms with the same problem). If enough diligence was done on making the process or modules portable, there very well may be other buyers interested in buying the modules. This can be done independently, through software vendors (if applicable) or through consulting vendors that helped build the solution.

B) Cross-Enterprise Development (having multiple enterprises collaborate on a solution simultaneously). This is one option that I haven't seen very often, perhaps because it would be logistically challenging, but I think it could be well worth it in the end. If there is a common industry challenge, it might make sense to bring stakeholders from multiple organizations together to design and build one solution (or components of a solution) that can suit multiple company's needs. This allows the cost of the project to be split between the two (or three or 'x' firms) along with the possible introduction of other capabilities that one company may not have been able to think of on their own.

C) Open-Sourcing the Solution (getting the community involved in collaboratively enhancing the solution). Hey, be a good corporate citizen why don't you? If you think something would be valuable to your industry or corporate "community" start a sourceforge project and put it out there. If it has enough legs you very well may be get some additional community-based development on it that your company can then leverage.

As we enter another cycle of IT cost cutting and budget tightening, firms need to think more creatively about getting projects done while minimizing overhead costs. By reaching out to competitors that may be trying to solve the same problem, everyone wins.

Have other ideas on how to commercialize assets or identify project functionality that can be leveraged by the community? Let me know in the comments below.