âDon't be silly; my developer knows exactly what I want.â - Often ... Build right is making sure you account for the
Reporting Solutions:
A Guide to Buy vs. Build when Design Matters
www.juiceanalytics.com
Table of Contents Evaluate between Buying and Building
2
Buy vs. Build
2
Building: Myths and Assumptions
3
Add in the Hidden Costs
4
Evaluate the Value
6
Quantify Your Decision Process
7
© Copyright 2016, Juice Inc
1
Evaluate Between Buying and Building You’ve been pushing for months (or perhaps years) to improve your reporting capability. You crossed the hurdle of reaching consensus, gaining approvals and nailing down a budget. Now it’s time to start thinking about how you make your plans come into being. We all know there is no shortage of great ideas, but the key to a great idea is execution. So, how are you planning on executing your reporting plans? This ebook is a guide to help you frame the Buy vs. Build decision and highlight common assumptions and myths associated with both sides. Its goal is to help you navigate this often confusing decision to ensure that the best possible long-term solution is implemented. This ebook will also help you set up your evaluation and score your options.
Buy vs. Build Once your project is approved, the next hurdle for a new reporting solution is whether to buy or build. In many ways it’s the fork in the road. This decision determines whether you leverage the stability and scale of a packaged, commercial solution offered by an outside product vendor (buy), or if you own the technology and embrace the flexibility and control of using your own development resources to create a custom solution (build). Here are some of the most common myths and assumptions about buying and building reporting solutions:
Buying: Myths and Assumptions 1. “We’re launching today; everything will be perfect!” - “Day One” is the first day that actual users are on the system—and when most issues arise. During this period, include additional support time for user questions, hand-holding and bug management. Keep in mind that it will be easier to hold a vendor accountable if you’re paying for maintenance/support. 2. “This solution is exactly what I’ve dreamed of.” - The solution won’t include everything that you wanted. The lower cost of a pre-built solution often comes from the sacrifices on your ideal requirements. 3. “It’ll fit perfectly into my existing processes.” - To make the out-of-the-box solution work best, you’ll have to modify your existing processes. For instance, you might have users begin to create reports for themselves instead of submitting a request. Redefining the process and training others on it will require a meeting or two. Increase this by a factor of four if you need to change a customer process. If it’s a ‘buy’ solution, your vendor may have experience, templates or guidance to make this process easier. 4. “My vendor won’t respond to my requests.” - It might seem as if you have less leverage with a vendor as opposed to an internal development team; however, given customer empowerment through social media and pressures for client retention, you have pretty good leverage over a proven vendor.
© Copyright 2016, Juice Inc
2
Building: Myths and Assumptions 1. “I’m only going to need my development resources once for this solution.” - Beware of the assumption that once your reporting solution is delivered, you’re done with your development team (i.e., spending money). Let project sponsors and stakeholders know in advance that there will always be ongoing fixes and changes. Budget for these ongoing costs and resources to do the additional work. 2. “This solution is exactly what I’ve dreamed of.” - Ha! Sound familiar? Yep, just like with a “Buy” solution, perfection is very elusive. The old adage “speed, cost, or quality: pick any two” still holds true. Even if you design the perfect system, you’ll have to make sacrifices along the way, either for performance, cost or usability. Accept that fact. Focus on the process of getting the best value for your budget given the constraints. 3. “Don’t be silly; my developer knows exactly what I want.” - Often, developers and business people talk past each other, assuming the other knows what they’re talking about. To minimize these issues, here are some ideas: ∙ Provide examples, wireframes, etc. e.g., saying, “I’d like a chart like this.” ∙ Offer a write-up or description to complement your example or sketch. ∙ Follow up examples with a conversation so that all questions get answered. 4. “It’ll be so great, all our users will be able to figure it out.” - There’s always an influx of new users. It’s not something you plan for, but it happens all the time. “Build” solutions aren’t known for their ease of use. So, plan in advance to address this with post-implementation user assistance. 5. “We know exactly how much effort/cost is involved.” - There are always change orders or features and functions that emerge for later phases. Define what constitutes a change order and understand how it works once you move from implementation to support phase. Armed with this new self-awareness, you’re now ready to set up your reporting solution evaluation criteria. It’s OK to have a bias (buyin’ or buildin’). It’s just important to be aware of the potential pitfalls and have plans to mitigate them.
© Copyright 2016, Juice Inc
3
Add in the Hidden Costs Here’s where Buy vs. Build gets interesting. Costs are important, but how do they compare to value? The key to getting Buy vs. Build right is making sure you account for the real costs and give value its proper place in your equation. The items below represent some of the missing or hidden costs as well as some ideas for incorporating value into your evaluation. Quality Assurance/Testing The project plan may list it as unit, regression or user acceptance testing. Ideally you have time for all of these tests if you can. Testing commonly gets underfunded or cut, but this is an especially frequent challenge with “build” projects. Good testing informs priorities, next versions, training opportunities, etc. User Adoption Intuitively, user adoption is highly important but rarely gets calculated into the costs, hence why it gets categorized as less than obvious. If you build it (or buy it) will they come? What are the risks if users choose to not use the new reporting solution. Be sure to factor in this risk when doing your evaluation. If buying, ask for references, industry examples and experienced team members. A good user adoption plan incorporates a communication and training plan — so users are aware of upcoming changes, have time to prepare, and can get on board with the new solution. Other ways to minimize this risk is to have experienced designers or User Experience (UX) closely involved with the project. Make sure they understand the user profile, not the person writing the check, but the actual users interacting with data and reports on an on-going basis. Design(er) If we’ve learned anything from Apple it’s that design matters. When building a solution, you are the designer. The following example is what happens when you let non-UI/UX designers do an interface:
© Copyright 2016, Juice Inc
4
When buying, take the time to interact with the design team to learn about their approach and where they want to take the product. Make sure the design team has a say on how the solution gets implemented or configured instead of just adding a logo or changing colors. Ask for their credentials and portfolio too. Ongoing Support Maintenance or support costs can sometimes work against the buy option, because the build option mistakenly assumes no ongoing or 2nd year costs. This is never the case, so be sure to account for it in the build option as well. Product Updates One of the perks from the annual software maintenance fee are the product updates. Bugs identified by others are fixed without you ever realizing it. Be sure that you’re getting at least one major update and three minor updates every year. You’re paying for it. Use our evaluation scorecard tool to run some numbers. The results more accurately represent the true costs and will help you make a decision. What you’ll see is that you incorporate the costs and risks with the less-than-obvious categories, making the ‘buy’ selection the better choice.
© Copyright 2016, Juice Inc
5
Evaluate the Value Now that you’ve reviewed the hidden costs and weighed them against your decision criteria, let’s talk about value. When working with vendors on a ‘buy’ project, you are not just purchasing their product, but also their expertise in executing these types of solutions, which is their core competency. They bring with them the knowledge and experience to quickly and effectively build, deploy, and launch your solution, accurately and within a short period of time. This is why solutions like Salesforce have become so popular. On the “Build” side of the argument, value presents itself
Buy
in what you own when the project is completed. Since you designed and built it, you’re now the proud owner of the intellectual property you’ve created (presuming you’ve not violated any copyright or patent laws.) And with this ownership, you have both the control and responsibility of what happens to it in the future: you can drive it in whatever direction you choose to. Your fate is in your own hands.
Build
© Copyright 2016, Juice Inc
6
Quantify Your Decision Process Ok, now that you’ve thought a bit about the Buy vs. Build myths and assumptions, hidden costs, and the value proposition of both, it’s time to get down to get quantitative. Download our Buying Over Building Reporting Evaluation worksheet to help validate your thoughts on Buy vs. Build, including topics such as how much (or how little) design matters for a successful implementation. This will provide specific talking points you can use to value design in your selection. The big difference between this evaluation template and most others is that it factors in risk (potential cost) if the reporting solution goes unused or is not valued by users. Notice that the less design you apply, the greater the risks are. Finally, download and read these case studies from Healthstream and the University of Notre Dame. The use cases offer relevant examples of how two organizations navigated the Buy vs. Build decision. Working through the Buy vs. Build decision process for a reporting system can seem a little intimidating, but hopefully this short e-book has given you some tips, tricks, and tools to make that process a little less daunting. Good luck with your decision and here’s to reports people love to use!
© Copyright 2016, Juice Inc
7
