Document Co-authoring Software, Build or Buy?

When creating complex contracts or time sensitive documents that may be part of a larger solution, the current way of creating documents is broken (too slow; full of errors; challenging to maintain). Is that truly the case for you? So, how do you solve this?

Do you build your own solution, or do you buy something Commercial off-the-shelf? There are positives and negatives to both approaches. But first things first; before you can make a Build-vs-Buy decision, you need to work out your requirements. A build vs. buy decision starts with well-defined requirements. You need to fully understand what your solution actually should do. Different expectations for various stakeholders and internal politics makes this a difficult, but important, task of part of any such project. Your aim might be to release a new product / solution to complement your portfolio of software solutions and you might know the core issues at hand. But, what will the requirements be in 6 months or 2 years down the line? Do you have the resources and know-how to maintain a document solution that meets your customers' requirements now and in the future? Or is the document and reporting part not an important part of your delivery?

Build or Buy decision

This is why forward-thinking companies spend a lot of time researching solutions. Specialist document assembly and document automation suppliers have the experience and expertise to help you understand the sorts of challenges other companies have solved and how they've done it. If you have not found any solution in the market that covers at least 60-70% of your requirements, you should consider building. However, there are still risks inherent when building your own document automation, document co-authoring, and document assembly solution.

Building

• Many developers believe they are the only ones that can deliver your exact requirements It's not just a document solution that needs to be built. There is development, maintenance and support, in addition to potential new features that will enrich your solution. Do not underestimate the testing required, with i.e. XaitPorter, it has been tested for more than a decade internally, but also externally with clients and partners globally.
• On the surface document automation, document co-authoring and document assembly may seem to be easy to achieve with i.e. SharePoint. As with any area of expertise, it's only when you dig deeper, that you understand the complexity of developing and managing an ongoing development for a document solution - i.e. should it support high res and vectored graphics, how about formatting, layout and numbering, change management etc.
• A good end user experience is essential, and is only half the battle. Templates need to be updated and maintained. Without the correct document solution for you, maintenance requirements can easily turn your project into a money pit.

If you have identified your project as a "one off "with well-known and defined requirements that are unlikely to change over time, then build it. However, it still needs to make sense economically and you have to have a highly qualified and resourceful development team that you can dedicate to the task. In many cases, it may prove that your requirements are similar to those of other businesses and software vendors. In these cases, buying is more likely to be the better option.

Buying

• Check various software vendors that provides a document automation, document collaboration and document assembly solution and identify the features and functionality that best match your requirements. Ensure that you leverage the experience other clients have gone thru. Use the document solution vendors to help you to define your business requirements - they may have ideas that could prove beneficial to your case.
• Ensure that the solution can handle complex document requirements. You may need to be able both to automate content, automate look and field, while providing flexibility to manage change or tailoring for your clients.
• Confirm that your potential solution works and integrates with your other applications and infrastructure. Perhaps your chosen partner could host for you? Requirements change over time. Ensure that your chosen vendor has a decent API, that supports your business case, both now and in the future.
• If time to market is important, buying will be much faster than building. Finally, when making a Build-vs-Buy decision, you need to understand the total cost of ownership. You need to calculate all costs for the life of the project, including internal development costs, opportunity costs, ongoing maintenance costs, and integration costs. But, you also need to consider if time to market is important, and whether your development could actually be used to other task that could bring revenue to your company - instead of building a solution.

Total Cost of Ownership

Finally, when making a Build-vs-Buy decision, you need to understand the total cost of ownership. You need to calculate all costs for the life of the project, including internal development costs, opportunity costs, ongoing maintenance costs, and integration costs. But, you also need to consider if time to market is important, and whether your development could actually be used to other task that could bring revenue to your company - instead of building a solution.

It is usually far cheaper and faster to buy than to build. After all, if a problem has been adequately solved in a commercial product, why solve it again? Why not focus on a new and more interesting problem? Chris Doig .Please see link to his blog here.