If you’re planning a new application, or in the middle of building one, you should be actively considering your reporting needs and development strategy. If your application is already deployed, you should be evaluating your user’s satisfaction with its reporting capabilities and making plans to raise the bar.
Most applications need some level of reporting functionality, and getting it right reduces operational costs, increase productivity, improve user satisfaction or even provide product differentiation.
So, regardless of the stage or situation, you know that you’ve got important decisions to make that will involve weighing the pros and cons of building or buying your reporting solution.
In this White Paper we’ll look at the major factors affecting your decision including: questions, considerations, options and the advantages to each approach. Download the full Build vs. Buy PDF to follow along with the scoring worksheet. Choose whether ‘Build’ or ‘Buy’ wins in each of the 7 Key Considerations, rank their weight in your decision, and use the final score as a recommended course of action.
Keep in mind, there is no right or wrong answer—what is right for one company may not work for the other. And in the end, it will probably depend on how you prioritize these 7 Key Considerations.
Let’s take a look at the major factors and considerations you will face while making your decision.
Integration compatibility can be a deal-breaker when deciding on your report solution. Some solutions are just unfit for your application—like the saying “square pegs don’t fit in round holes”.
Among third-party software apps, ease of integration varies widely. However, many packaged software solutions make it possible to perform a proof of concept (POC) before investing in a solution.
If you choose to build your solution, compatibility is not likely to be an issue. However you’ll still need to consider how your solution will connect to it’s potentially disparate data sources.
Some organizations use the MoSCoW method to prioritize feature requirements.
Must Have- Critical for success or otherwise failure.
Should Have- Important but not necessary or critical.
Could Have- Desirable but not necessary. Or if time and resources permit.
Won’t Have- Least critical or for a later time.
It’s important to understand your end-users’ needs and how they are driving your prioritization—know what is non-negotiable and what is noise.
When considering packaged solutions it’s also important to look beyond what the software claims it can do, to what it does best. For example, report solutions that are strong in BI analytics often have little to no document generation capability. You may find that two separate packages is an ideal way to offer a best-in-class total solution.
.PNG)
The most elegant solution is only as good as its ability to meet performance requirements.
Not only must you establish your current performance needs, but you must look into the future to determine how your needs may change over time, and how you will address them.
Within any solution, there are countless potential points of failure and performance bottlenecks.
You wouldn’t show up to a Formula One race driving a school bus. You need to be certain your equipment is up to the task.
.PNG)
Will you have a developer designing or a designer developing your reports? If the prior is true you’ll need some beautiful pre-built templates. If the latter is true, you’ll need a very intuitive interface. Of course, having both would be best for everyone.
Any well-designed report is able to communicate the right information quickly and clearly. But customer facing documents have the added responsibility of reinforcing a company’s brand, style and professionalism. You’ll definitely need some amount of design flexibility but in the case of branded documents you’ll likely need very fine free-form design control.
You can learn more about creating better reports, in our White Paper: Design Tips for Beautiful Reports.
.PNG)
The success of your reporting solution depends on your user’s ability to learn the tools and get the results they want.
Reporting solutions tend to be complex. At least at some level, working with data can be confusing or tedious even for experienced analysts. Most rely on a collection of tools to help reduce errors and increase their productivity, and each of those tools is likely to approach things a little differently and have unique user interfaces.
Documentation, training and support can make a huge difference in the success of your reporting solution. Unfortunately, they are often an afterthought, or under-developed components of the complete solution. Developing materials and providing ongoing support can easily consume as much, or more, resources than writing the original code.
You will want to carefully weigh the need and effort as you’re making your build/buy decision.
.PNG)
The success of your reporting solution depends on your user’s ability to learn the tools and get the results they want.
Reporting solutions tend to be complex. At least at some level, working with data can be confusing or tedious even for experienced analysts. Most rely on a collection of tools to help reduce errors and increase their productivity, and each of those tools is likely to approach things a little differently and have unique user interfaces.
Documentation, training and support can make a huge difference in the success of your reporting solution. Unfortunately, they are often an afterthought, or under-developed components of the complete solution. Developing materials and providing ongoing support can easily consume as much, or more, resources than writing the original code.
You will want to carefully weigh the need and effort as you’re making your build/buy decision.
.PNG)
ROI is the bottom-line look at your ‘Build’ vs. ‘Buy’ decision. The beauty of an ROI analysis is that you’ll have a black-and-white number to look at and share with other stakeholders. The downside is that the number will only be as good as your assumptions and thoroughness. This document should help identify the primary costs and payback opportunities. But you should definitely do some digging to uncover the less obvious factors that may be unique to your organization.
One of the biggest variables is estimating development costs. There are volumes written on how to do this, yet few would claim that it can be done with certainty. Most would agree that various sizing, scoping, prototyping or POC exercises will improve the accuracy of the estimates but those can add significant cost themselves.
It’s important to have a realistic view of the margin of error in your build estimates and your level of confidence in a potential vendor’s ability to deliver as promised.
.PNG)
.PNG)
There’s one last important step in your decision-making process: adding weight to your decision criteria. It’s likely that as you’ve considered each of the points in this worksheet, ‘Build’ wins in some areas while ‘Buy’ wins in others. But not all criteria are of equal importance, and not all people will place the same amount of weight on each point. So, take a minute to consider not only the winner in each area, but also the amount of importance you would assign to each point. Then a simple tally should lead you to the right conclusion! To get the full Build vs. Buy worksheet, download the free PDF.
Virtually every one of our customers has faced the ‘Build’ vs. ‘Buy’ decision when it came to adding report and document generation capabilities to their applications. Those that choose Windward recognize that our approach to the question is to offer the best of both options by providing a robust mature packaged solution that’s designed to be embedded or called from within their existing application. This approach drastically reduces speed to market, shortens the ROI timeline, frees up internal resources, eliminates documentation and support concerns, and delivers a rich and scalable feature set—everybody wins!
Windward Studios makes document generation software that allows companies to connect document templates to multiple data sources for high-volume output in a variety of formats. Our design tools offer unmatched flexibility, ease of use and control, and our output engines can be embedded in .NET, Java or RESTful applications.
