Investing in outcomes measurement software is often significant, so you want to make sure you do it right. Whether you are implementing outcomes software internally with your own team, with a consultant, or with the assistance of the software provider, “blueprinting” the software prior to building it is a critical step.
Most outcomes measurement software solutions come out-of-the-box with general features that won’t be a perfect fit for your organisation. The solution will usually require customisation, which involves building and formatting the software with things such as custom fields, forms, workflows, and reports. These customisations align the software with your organisation’s unique processes, data collection requirements, and reporting needs.
Just like the plans required when building a house, blueprinting your software is the preliminary, upfront work that your organisation should do prior to building any component of your database. It is a risky decision to purchase outcomes software and dive straight into building the system, migrating and/or entering data, and then going live with the software without intention, strategy, or a clear blueprint. This process generally ends in an over-built, disorganised, or incomprehensible system that is underutilised by staff or is out-right rejected by staff.
So, instead of implementing the software in a “hit the ground running style,” be organised in your approach and implement according to the following format – design first by developing a blueprint, then build new fields, forms, reports, and modules, then go-live.
Furthermore, just as most people who build a house design the house first and wait until it is finished before moving in, the same goes for outcomes software. Don’t start building the software until you’ve designed what it will look like in the future through your blueprint. Don’t start using it until it is built to the specifications you require. This doesn’t mean your blueprint is set in stone once drafted. Of course there will be changes, additions, and modifications both during the building process and over the life of the software; but any changes should be made after the changes are blueprinted, planned, and thought-out. The design, planning, and thought you put in prior to implementation will pay off with a solid system post-implementation that matches your organisational needs. The remainder of this blog will outline a simple 3 step process to blueprinting, whether this is for a new software implementation or rollout of a new feature in an existing software.
Step 1: Understand the architecture of the software
The format of the blueprint will depend on the architecture of the software or how the fields, data objects, and reporting of the software are constructed. The first step is therefore to understand how the software is structured so that you can work out where to customise and how to customise features of the software. This step is important because you want to make sure you build fields, data objects, and reports (and other features) in the most logical way for that particularly software.
Step 2: Define your goals and the reports/exports to measure progress toward those goals
Once you understand the software’s architecture, you must define your organisational goals or objectives your organisation is striving to achieve. These goals each have tangible metrics or ways to measure whether you are achieving your goals. These metrics can be translated into data fields, forms, and workflows that you will need to customise within your outcomes software.
In addition to goals, you need to define the reports and exports you need to analyse progress toward your goals. The reports and exports are the presentation of the fields, data objects, and forms you create in the software. Many organisations wait until after implementation to think about the reports that they need, however this can result in lots of changes to your system post-implementation. This is because reports guide the type of data you need to collect and what you want to get out of the software. So, although it seems counter-intuitive to think about reporting so early, it is the easiest way to complete a blueprint, as you can work backwards from your reports to determine what data forms and fields are needed in your system to produce these reports.
Step 3: Map your needs to the architecture of the software
The last step involves mapping the fields, forms, workflows, and reports that you defined in step two to the architecture you defined in step one by outlining where fields will be placed, what forms will be used, how they are related to one another, and what reports you want to produce. This map becomes the blueprint which contains all of the information required to build your software. It is important to not start building the software, fields, forms, or reports until the blueprint is complete. It is also a good step to review the blueprint with your team prior to implementation. Reviewing the blueprint is an operational control that forces your team to take one final look at the blueprint structure for accuracy and relevancy before building the software.
Once the blueprinting is done, a lot of the hard work associated with your system implementation has been completed, which will subsequently make building your database a whole lot easier and ensure the system is effective for your organisation in the long-term.