Transitioning from Projects to Products to meet Analytics Demand
Big Data and Analytics are the marketing and sales buzzwords of the day but many have been working in this space for years and would claim that nothing is new. This is both true and false at the same time mainly because there is lack of clarity in these terms. Yes, Analytics has been around since the advent of the computer. So what has changed? Data is no longer the limiting factor. Some have quoted that 90 percent of the world’s data has been produced in just the last two years. The limiting factor, now, is our old approach of having a “data first” philosophy. This has always been problematic but with the amount of data available to us today (and in the future) there is no way to keep up. We have all heard the following quote, “We are data rich but information poor.” Reality is that too much time is being spent gathering data and producing reports and not nearly enough time is spent actually gaining insights and driving improvement.
Traditionally, IT, Informatics and Analytics departments managed business intelligence (BI) demand through an intake process with rigorous prioritization and project management. This approach was coupled with enterprise data warehouse projects that would focus mainly on repositioning data from available source systems. Solutions were often delivered that targeted a single function or department (such as supply chain, finance, surgery, emergency medicine, etc.) and brought a series of descriptive dashboards and reports. This is what I would refer to as a “data first” approach. The results were usually somewhat successful but always short of expectations, especially in the time lapse between request and delivery. It also meant the department sponsoring the project would be responsible for sales, marketing and support. For this reason, tools were often underutilized or even worse not used at all.
Be proactive and interview broadly to uncover needs across business units as well as deeper within key service lines
Understanding Product Management
Most of us have bought software solutions for years, so we are familiar with products but few of us, that manage internal functions, are truly familiar with how these products are developed and sold. We also often ignore the fact that we are in a competitive situation that is no different than those who market and sell to our users. This is where product management comes into the picture. Product companies do not wait for someone to request a product. Instead they research markets proactively and then make strategic investments to meet anticipated demand. They know that if a customer calls asking for a solution and they don’t have product on the shelf to meet their needs, they are not going to make a sale. Isn’t this really true for internal solution providers as well?
I would suggest that just like those that we purchase software from, we need to think strategically about how we compete and position our internal capabilities. Most of our institutions cannot afford custom analytics and instead look for us to proactively build and buy what they need. If we receive a request which is backed by a critical need and we are not already working on it, we are likely behind schedule. This means doing proactive market assessments, making strategic investments and taking calculated risks. It also demands having a well-honed marketing, sales and support function within your team. But most importantly, we need to start thinking “solutions first” as opposed to getting lost in data. Defer the discussion of data as long as possible by being fascinated with the problem. Solutions are what users are really interested in and what sell to leadership.
The Obstacles with Transitioning to Product Management
Product management may not sound like a big change for internal service providers but it actually is. Product management adds significant processes to the “solution life cycle.” In fact, three new robust phases (market assessment, roadmap planning and concept development) are needed prior to development and maintenance, as well as another after (marketing and education). Most have done bits and pieces of these activities in the past but not nearly to the level needed. New skills are commonly required in the areas of consulting, strategy and relationship management. The goal is to deliver a portfolio of high-value products and services that are differentiated and meet broad needs. As opposed to one-off projects, products can be configured or tailored as opposed to having to start from scratch.
Another key differentiator in product management is the preoccupation with understanding value through the customer’s eyes. BI tool suppliers will tell you that they are not bound to requirements but that could not be further from the truth. Candidly, the number one reason analytics projects fail is because of a poor understanding of the business or clinical requirements and determining “What problem(s) are they really trying to solve?” This is also the primary reason so many struggle to define ROI. Good analytics requirements come in the form of well understood questions. If we know the critical questions we can then work to the specific metrics that are needed. With the thousands of metrics now available this is critical. In fact, best practice in analytics development is to defer the discussion of data as late in the process as possible (which is actually contrary to many traditional data warehousing philosophies).
As we shift our focus to deeply understand the problems our collective users face, we will inevitably accrue a giant backlog of needs that must be prioritized. Here, too, product management is well suited to help us succeed. The product lifecycle enables a portfolio-based approach, where the phases of the product lifecycle are purposefully stage-gated to advance the solutions with the highest, demonstrated business value. Stage gates not only accelerate development efforts on high-value solutions, but also enable incremental investment across a greater number of in-flight products—as early stage prototypes are tested and fall short of expectations, their earmarked investments can be shifted to better performing alternatives (i.e., allowing adoption of a “fail fast” industry leading practice).
My advice to anyone who is struggling to meet analytics demand would be to take a serious look at leveraging product management philosophy and processes. Be proactive and interview broadly to uncover needs across business units as well as deeper within key service lines. Start small by focusing on one product at a time but do not shy away from hard to solve problems. These will be the questions that if answered would provide unique value for your institution. The reality is that “big data” is too big for a “data first” approach. Product management on the other hand forces you to be steadfast and pursue “solutions first”.