Not all business intelligence / analytics efforts must be large, multi-phased initiatives. Small, focused, quickly completed projects can provide lasting value to any organization.
Small, focused analytical efforts can be of great benefit to an organization. Often, they are used to serve a specific need, such as build a pilot solution to prove value for a larger future effort, or provide an enhancement to an existing solution. Development teams can be challenged by what should be a short, quick, analytics project that turns into a time and cost nightmare. Unfortunately, one area that many organizations struggle with is the ability to take a small, reasonably sized analytics project and deliver it in the estimated period. There are some key criteria required to realize the rewards a small project can deliver.
Keys to Success in Small BI Projects
- Sizing The Effort Properly
Users are satisfied by a system if it provides the data they need for analytics and offers an interface that is efficient and easy to use. Some efforts are classified as small when there is a limited number of attributes to be considered – even though there are numerous methods for analyzing the data. On the other hand, an effort may have a couple of front-end deliverables, but there is a voluminous amount of data that must be migrated, integrated, validated, and deployed for usage.
Ensure that the organization is being honest with itself when saying this effort is small and should be delivered in 60, 90, or 120 days. Know the organization’s, culture, resources, and past project history. Ease of use and limited options for BI/analytics will help speed adoption and drive business requests for more focused solutions.
- Start the Clock Once the Effort Starts
It sounds simplistic to say that the project does not start until it starts. Yet, it is common for management to look at the date of approval of an effort as the start date. When presenting a proposal for funding/endorsement, clarify the project setup that must occur before the project will actually start. Frequently, that takes 2-3 weeks and sometimes more.
It is also crucial to include duration as a focal point – i.e. the project will last for 12 weeks. Then, once the project charter is approved and the requirements are defined, give a specific end-date in the project plan. This date should either be fewer than 12 weeks from the start or explain that there are additional requirements and the scope is now slightly enlarged. Ideally, the organization has a formal project status report that is delivered weekly. That will assist in keeping leadership aware of the defined time frame. In addition, it will expose potential roadblocks to success at the earliest possible time, enabling leaders to support the effort before it falls past the critical path for success.
- Tools and Infrastructure
Rapid development requires the right tools and technologies at the start of the project. Most corporations have a hard time defining hardware and tool sets to use in these types of efforts.
- Infrastructure – Having hardware platforms, servers, disk, network connectivity, and protocols in place prior to starting will go a long way to getting this project off and running. If the project team must define an infrastructure, purchase the various layers, wait to receive them, install, setup, and validate these solutions, then the timeline for a small solution has passed. If there is a solution set that can be deployed into the existing infrastructure in short order, or if there is an existing server to host the solution on, success in a small project is more probable.
- Tools – Having the various data warehousing and business intelligence tools for building and deploying a solution in-house is a great starting point. For example, do not plan to do an evaluation of ETL tools as a first component. Tool evaluation is a project itself and for most companies it is not a small project. Since there are many layers of technology possible in these options, simplify any new technology to as few different vendors as possible.
- Data Quality – All data warehouses/BI/analytics solutions expose data quality issues, whether it is in population of the data into the databases or what the user encounters using the front end. For smaller efforts, less time is needed to perfect the data. Too often, technical resources and business resources say their data in their DW must be perfect. This is a noble gesture, but it is usually not an option when delivering analytics in a reasonable time period. It also covers up the flaws in source systems and may not accurately reflect the business.
- Technical Leadership / Project Management
Project management of regular tasks on small projects should be done by the project manager and supported by lead designer, since they what is to be produced. They are the ones that know the needs and the design well enough to keep the team focused. The challenge these resources often encounter is preventing scope creep through additional ideas, thoughts, and creative uses as the project proceeds. The lead designer should not spend time validating scope change, since all evaluation of scope change negatively affects project progress and is the responsibility of the project manager. If it is necessary, scope can be changed, however, and then the time periods, resources, or cost must change as well.
Avoiding Perfection
Most data warehousing / BI development consultants would state that requirements definition would be the main factor in keeping this type of effort on track. However, defining a key portion of data, and then determining a few select ways of using that data analytically is really the secret. A wise person at the Mayo Clinic used to advise project managers that “Good Enough” needed to be balanced against having the optimal solution. Although most developers and project managers want to build the perfect solution for any business need, in almost every instance, it is simply not practical. This is even more important when trying to manage a small focused effort.
Continuing to pose questions to validate the business needs results in discovering valid requirements and the data associated with them. Adding data sources, derivatives, views, tools/techniques for using data, follows. This is no different than trying to come up with a plan to build a dream house, continuing to review the plan with people once it is done, more ideas, more changes. It is much easier to feel the impact of those changes in the house design example. Continual changes affect a person’s finances and delays them from getting what they ultimately want, a new house. This can offer a perspective of how a user feels when they see a project spiral out of sight on cost and time (even if it is their changing requirements that caused it).
Organizations that succeed at smaller analytics development maintain a focus on the data provided and on using only selected BI/analytical solutions. Doing so provides them with the ability to deliver on time and then continue to add reports/analytics to the existing data as the users work with it. As the users interact with the small solution, they will identify requirements for the most valuable next solution to provide, which can be enhanced later with additional data.
An organization can realize a long-term analytics solution through planning and carefully managing change control throughout the project. Strive for perfection and the first solution may never be delivered successfully.
Too Many Cooks in the Kitchen
Smaller efforts must have someone in charge that has proven success with delivering this type of effort. It is imperative to give them the freedom and support to manage the project based on their experience. Multiple people trying to oversee or direct the actions of someone with proven experience essentially override that experience, negating the value. Instead, the internal resources (including management) should watch and learn. This will help develop a staff of resources that, in turn, can lead similar projects and successfully deliver them.
Conclusion
Small, focused efforts can be the right solution to many business intelligence and analytics programs. Too often, companies look to an enterprise data warehouse when the right answer for them is a specific solution. Right-sizing the infrastructure, architecture, and development tool sets can only be defined the problem statement has been clarified. Then it is time to start the project clock ticking.
The project manager’s ability to keep the scope contained and to communicate within the team and through management, will enable the project to stay on track with expectations. By closely managing change, and keeping distractions out of the way, the staff will be able to focus on designing a database to capture the data needed. Using the available front-end tools, they can build some reports/analytics to get the adoption started. Like all great solutions, each step in this direction will enable more informed decisions with actionable data.
