Every day we speak with organizations looking to expand, modify or begin enterprise reporting projects. More often than not, marketing professionals are reaching out for more than just assistance in providing a reporting solution though. What they’re really looking for is advice on how to ensure the success of their reporting project.
We took the opportunity to ask some of the people we’ve been working with about why the implementation of their reporting projects hasn’t gone smoothly for them in the past. They shared some extremely interesting insights on things they wish they had known before getting started with implementing organization-wide reporting.
An IT professional that headed a sub-team tasked with building an in-house reporting solution recounted how they had completely underestimated the need for ongoing access to developers. They failed to foresee that they would need access to these resources not only for the duration of the project, but well after it was rolled out to business stakeholders.
While during the initiation phase of the project, this team had built ongoing post-project maintenance and quality control into their plans, they didn’t recognize, or their counterparts had neglected to investigate or communicate, the potential impact of the changing external environment. For example, not only do new types of data become available as digital channels evolve, but data collection methods undertake continual adjustment. New third-party data collection tools materialize daily, and APIs are subject to frequent change. All of this meant that those developers who had initially worked on making API connections found themselves with a new maintenance project each time the provider updated the version, made new data available or changed the data measurement method, resulting in a readjustment of the reporting model. In addition, the digital team continued to request new connections well after the handover.
In order to avoid these types of project deficiencies and optimize resource allocation, we recommend that business stakeholders, as well as individual team members who have expertise in data collection, work alongside IT during the initiation and planning stages of the project. It may even be prudent to engage support contacts from those third-party providers whose platforms you will be working with.
Those who have the ability to design and implement a technical solution don’t necessarily understand business goals, and vice versa. Make sure that you are supporting an efficient balance between perspectives from the get go, and also that requirements are crystal clear.
While you might think that the most efficient way forward is to let your technical team design the solution and then bring in your business stakeholders to adapt it to their needs, this can result in inefficiencies, and in the worst case scenario, a completely inadequate solution.
Before designing a technical specification, business questions like “what data does each stakeholder need to make good decisions?”, or “what is the best way to represent this information so the correct stakeholder can easily interpret and act on it?” should be asked. And this can only occur where business stakeholders work alongside technical teams.
In addition, all stakeholders involved in project initiation and planning need to agree upon and understand the objectives of the project. Where no common purpose is achieved, at least a portion of stakeholders will be dissatisfied with results.
After identifying company objectives, stakeholders, requirements and budgets, mapping out project scope, making a decision on the correct solution, and developing, designing and implementing your reporting model, you might think the hard work is behind you. You’d be surprised though…
Not only is conceptualizing and executing a rollout plan a significantly taxing process, but it’s crucial to the success of the project as it can determine the level of adoption achieved. We’ve often seen it overlooked, however, to detrimental effect. Ensure that you give this process and the communication around it the weight it merits.
Furthermore, encouraging adoption doesn’t end the moment you’ve shared login credentials or access. True adoption only occurs where your colleagues, stakeholders and other data consumers accept that the reporting you’ve provided fits their needs and adopt it into their routines. Therefore, this stage can take significantly longer than expected as you find modifications, adjustments, compromises and/or the creation of incentive programs are required. You might find yourself with never-ending contradictory feedback and it’s up to you to find the sweet spot (mind the pun!) between implementing individual stakeholder requests and delivering something usable and intuitive that meets the requirements of the larger organization. At this stage, don’t overlook the value of effective communication around the objectives of the project, the compromises required, and the value it will bring where adopted.
In discussing adoption above, we referenced the need for data consumers to adopt reporting into their routines. This goes further, however, as the success of your enterprise reporting implementation is determined not only on this, but on your stakeholders using reporting to help them optimize outcomes and fulfill their own objectives. To ensure this, ongoing engagement with your reporting is critical. This should be taken into account at the moment of solution design and also impact all consequential implementation and communication initiatives.
It’s incredibly frustrating to see any project flop as key stakeholders exit or are reassigned to new projects, but it’s also extremely common, especially in the quitting economy we are all operating in.
It’s inevitable that team structures change over time, and the adverse impact this can have on projects can be enormous due to loss of knowledge and changing expectations.
It’s therefore vital that the exponential speed of team changes is considered at every stage of the project implementation. Follow these tips for project success despite continual turnover:
Please note that not only are projects in design or implementation stage at risk due to the turnover factor, but it can disrupt even the most ingrained company practices where there are no provisions for their continuation into the future. This can be extremely positive where current practices are inefficient, but where they are bringing the desired result, a change can not only result in wasted resources, but also in ineffectual new systems.
One of the crucial first questions when designing Enterprise Reporting is: Who will lead this initiative? Will it be top down, or bottom up?
The choice made at this early stage often determines the success of the final implementation, and this runs both ways.
We’ve often seen poor adoption across the larger organization where a top-down approach has been implemented. This occurs in the scenario where those defining and enforcing their vision for enterprise reporting are out of touch with those working at operational or tactical level, or where they have little understanding of how to communicate actionable insights to these individuals.
On the contrary, bottom-up projects often fail to incite action at a larger scale and push the needle on greater company objectives. Where microcosms form, decentralized models are incompatible and cannot be compared, and this approach can lead to siloed reporting. So while individual groups may have substantial buy in, this likely won’t be pervasive.
In order to achieve buy in across larger audiences, we recommend a goal-driven approach. By “putting strategic goals at the center of a top-down organization workflow” you will be able to enforce a system of accountability, where objectives are clearly defined, to provoke action. This type of centralized reporting structure will ensure everyone is working towards common goals, while respecting the skills and responsibilities of each individual team member.
In addition, however, we also encourage you not to stifle decentralized reporting projects. Where these pop up, address stakeholders for extremely valuable feedback into why they were developed. If they complement existing structures but allow certain teams/individuals to operate more efficiently at a tactical level and better achieve the larger goals outlined in your goal-driven reporting, you may wish to consider integrating them into the larger structure, or at least acting on lessons learnt. Where they are replacing your organizational structure, however, take time to understand why and resolve this. Small scale disenfranchisement can have an exponential impact on the larger initiative.
Most importantly, however, no matter how you implement your reporting, make sure that it’s aligned with company culture. Where it runs contradictory to this you cannot hope for success.
All those evolving factors we were discussing earlier: team structure, technology, market conditions, organizational objectives, etc., mean that the dream of static requirements is a futile one.
It’s beyond disheartening when you’ve worked extremely hard to develop a project that meets the needs of a stakeholder, according to their own spec, only to have it rejected on delivery.
In order to avoid this nightmare scenario, ensure you effectively manage expectations from the beginning.
Make sure that you get everything in writing before beginning the project so that you can refer to it at a later stage, and use it to either reject gigantic shifts, or at least justify new timelines. Managing the expectations of those stakeholders and keeping them updated as the project progresses is crucial to maintaining buy in.
It might seem silly, but you also need to manage your own expectations. Make sure that you spend time before getting started brainstorming, mapping out and considering possible evolutions that will impact your project development. Not only will this help you to keep motivated, on track and productive throughout the duration of project development, but anticipating changes can also help you change-proof your project, or even better, build it in a manner that enables flexibility over time.
We hope this post has been useful in helping you as you approach enterprise reporting. We’d also love to hear what you wish you knew before you started your own enterprise reporting project!
Not Another Dashboard.