Having the necessary project reports in a new system is key after a software implementation project. This is especially true for construction project stakeholders after they’ve spent a lot of time and resources preparing a system for use, mapping out business processes, and conducting training. However, most of the time, it seems these reports are not available because reporting and analytics were not taken into consideration until the project was well underway or even nearly completed.
It sounds really easy to remedy right? Consider the reports you need and start with those when you design a system, instead of waiting until the end to determine what you want. For a lot of people, trying to take a blank sheet of paper and defining what you want to see or know is difficult. However, the impact of not considering the output (the end) is having a system that doesn’t capture the project data you really need.
To tackle this challenge, I suggest six steps which are easy to understand but can take a while to complete. My recommendation is to not get overwhelmed by trying to do everything at once and instead focus on where you will get the most bang for your buck — potentially an area where you have the most blind spots from a data perspective.
#1 Identify a Stakeholder Group
This first step will likely be the easiest and fastest step. Identify those in the organization that are willing to dedicate time and are passionate about data. It is important this group is diverse and represents multiple departments and disciplines of the organization so you don’t miss key business areas in your reporting and analytics needs.
The role of this group will be to help determine what existing reports need to be available in the new software and what gaps exist that are impacting the ability to make decisions. This group will help identify any existing blind spots in business processes that don’t generate the necessary information.
This group will also be key in prioritizing where you spend your efforts first, because focusing on one area at a time will be critical to delivery. It is also a good idea to have an executive-level sponsor. This person will help clear roadblocks and potentially drive any necessary business process changes in the organization to get the information you want.
#2 Inventory Existing Reports and Dashboards
Before you start having your stakeholder group dream up all the reports and dashboards they want, take an inventory of what already exists. Maybe you are migrating from one system to another and already have several useful reports. Use your stakeholder group to determine which are critical to your business and ensure those are included as required reports from your new system. It also might be beneficial to find out how much the existing reports are used. “One report might be perceived as being used more than it is and knowing if five people or 500 are using a report should weigh in your decision.
#3 Identify and Prioritize Gaps
Once you have something to start from, begin walking through those existing reports and dashboards to determine what they are missing and prioritize those gaps. For example, maybe an existing report shows all your change orders and the value of the change order — but doesn’t provide the reason for the change order. While discussing with the stakeholder group, you realize that information isn’t being collected in the old system and it wasn’t identified as an important field to collect in the new system. This is a great pause point to emphasize why it is so important to start talking about reporting before you get finished with the implementation of a new system — because at the end of a system implementation, you have already defined:
- Business Process
- Required Fields
- Workflow
- Change Management
- Training
Imagine if you are missing 15 to 20 critical, important pieces of information that could drastically change your business. You didn’t realize they weren’t included because the focus was on how the new system would work and less about the problems you want it to solve. This problem will start to compound because once a record is entered in the system (a change order) and you didn’t collect the reason because it wasn’t available, you are losing a huge amount of rich historical data that could drive future decisions. Trying to go back and clean up old data is extremely challenging and time consuming as well — not to mention highly inaccurate.
The decision was made to move to a different system for a reason, whether that was for new functionality, a better user interface, less manual data input, etc. It is important to maximize this opportunity to also evaluate what information you don’t currently have that you want and ensure it gets baked into the process.
#4 Identify Functionality Gaps in Software
If we carry on with our initial example of the missing change order reason field, the next step would be to determine if the new system has any limitations or maybe the field just needs to be configured and made available. Let’s assume for simplicity’s sake that the new system you are implementing has the field available, but needs to be configured. And with it, you also get some additional fields to populate like client, risks, etc. By identifying that you want this additional information and require it to be populated on all change orders, you can start to analyze your change order date and use it to drive improvements going forward. You will also potentially predict when and why you might have a change order.
#5 Build Reports and Dashboards
Now that you have ensured the system will be capturing this information, you can start to surface it through reporting and dashboards. This information provides a more complete picture of what happened, whereas previously, all you knew is that you had a change order, but knew nothing more about the impact it would have on the overall project and how to mitigate future change orders.
#6 Implement Business Process, Change Management and Training Plans
Once you have the information surfaced on reports and dashboards you can implement the business process changes to collect the additional fields. You can also tackle change management and training by showing what the output is used for and how it helps the upstream process. In this example, understanding the reason for having change orders helps drive more questions around the design/requirements or determining when too many change orders might be too much for the overall project to stay on track.
The End Goal
Starting with the end (the output) is hard and it requires a lot of time spent thinking about what you wish you had that you don’t currently. Everything you want doesn’t have to be tackled at once, but creating a prioritized list of 5-10 pieces of information that would add significant business value will start to change the way you design and think about your systems. It will also potentially help you reduce overhead by eliminating steps in your business processes that don’t drive decisions and revenue — or adding steps that will drive revenue.
Keeping a focus on the information needed to run and improve your organization will ensure that the system you implement has the information and historical data you need to drive business decisions.
For more information on today’s most advanced project management solutions,supporting a connected data environment, visit InEight.com.
