The Hudson’s Bay Co (HBC) is in the process of deploying a common business intelligence (BI) reporting system across its major retail businesses: The Bay department stores, Zellers discount stores and Home Outfitters. In this article on ITbusiness.ca, they openly share their implementation difficulties for this large integrated project, which involves over 5,500 end-users. Change “business intelligence” to “Web analytics” and change “3 retail stores” to “3 Web sites” and the learnings are very transferable to Web analytics.
HBC has suffered from:
- Internal resistance and difficulty in training and communication. A turnover in senior leadership didn’t help. Some senior managers refuse to use the dashboards created to summarize the data. HBC says that a pilot approach may be looked at next time.
- Definition of business models at a very detailed level is occuring just now, during implementation. Clarification of terms, such as what is a “sale”, “discount” or “markdown”.
- Confusion about what data was to be stored and accessible in the new warehouse.
- Client resistance to “losing” detail in new reports compared to old reports.
HBC’s new data warehouse is coming from Teradata. Alison Torres of Teradata is right on when she says, “You don’t go out and buy a data warehouse, you build one,” she said. “It’s a process, not a product.” [Yes! Absolutely! How can we make this insight clear and real for business and IT?]
And about end-users of the data, Alison says, “They don’t see limitations – they see the data and they want it,” she said. “You can ask them, ‘Do you really need this detail now?’ And they’ll say, ‘Not right now, but we might later.’ ”
And this is because “IT departments tend to base data warehousing and BI strategy on one of two models. Either they build whatever users ask them for, or they assume users don’t know what they need until they see more data. In either case, the same problems creep in”, she said.
And therein lies the problem. The most effective way in my opinion is a third model. IT and business develop requirements together. For a project of this size, integration and complexity, tradeoffs are unavoidable. Doesn’t it make sense to build a system such that handling unanticipated future new requirements is a capability of the system?
It’s a no-win situation to demand that the business figure out what they want and hand the requirements over the wall to IT. This worked in days gone by for non-integrated projects involving one business function and one department. For integrated projects involving multiple technologies and requiring business-savvy tradeoffs, IT and business must sit down together.
Senior leaders used to insist on a handover of defined requirements from business to IT. Now, they need to hold their IT and business people accountable to work together. IT and business should jointly sign off on the requirements, not sequentially. Working together means conversation around the same table or in joint webconference sessions. Working together means all present understanding business goals and why they are important to the business. Working together means trading off reporting metrics, reporting processes, budget, feasibility and technical requirements, such the the whole process and system delivers truly actionable decision-making support for achieving business goals.
How can this be done in a focused time-efficient manner? For an analytics project, BI or Web, the “users” are the analysts, front line and senior managers who will use the reports to make decisions and take action. Therefore:
- Create user personas (what are personas?) of the analysts and senior managers.
- Construct decision making scenarios and storyboard how users will wield the various reports and drill-downs as decision-support tools.
- Get IT living these scenarios. The need for flexibility may cause IT to define a completely different database infrastructure to enable reporting flexibility. The business doesn’t have to be concerned about the how IT does this, just the quality or decision-making reporting, and whether the cost is justifiable against the benefits.
- Create a pilot project or a prototype. Test using defined task scenarios. Confirm that this project will actually work and deliver the target value, before deploying the full scale version. More and more Websites regularly use prototyping as part of their design. Use this same process also for in-house analytics projects. If there are problems with dashboard reports and nobody’s going to use them, isn’t it better to find out when you have 5 built rather than when 200 are built?
- Think about how the business might evolve. Think about how the system might have to evolve to support the business. Decide together whether to make allowances for these possibilities, or not.
[Analogy sidebar: If you’re building a house, and may put an extension off the back wall in the future, it would be prudent not to put plumbing or a load bearing post in the middle of the back wall.]
This method of project definition and project build takes more IT resources at the front end but will save on scope creep, last minute fixes and a long list of post-launch enhancements, or even worse, outright user rebellion and shelving of the project. That’s why you need senior leader support. In the push to deliver a project to completion, project discovery, usability, testing and redirections are the first areas to fall.
Focus on process and business results. Go slow to go fast.
What do you think?