By Mary Anne Hopper, Senior Consultant
Remember way back when your Business Intelligence organization was a small group of one or two people? And then business found value in what you were producing so your group grew? And then you created clear roles and responsibilities for the team? And you started creating project backlogs? And your group continued to deliver great results for the business? And your team grew more? And then things seemed to slow down in your ability to deliver and it was hard to figure out why?
Could it have been that each time you delivered new functionality, someone had to stop what they were doing to support it? The impact of this can mean missed delivery dates and ticked off end users.
Each time the business needs something they have the ability to talk directly to the person who built the functionality for troubleshooting everything from data loads to data anomalies to report issues. So, every time functionality is introduced into the environment, somebody is in charge of supporting it in addition to their ongoing project delivery responsibilities.
I call this the “and” syndrome. Nobody can support “insert system/data/report functionality” and “insert system/data/report functionality” and “insert system/data/report functionality” and “insert system/data/report functionality” [I’ll stop here because you get the idea] without impacting the ability to deliver new functionality.
Here are some tricks and standards I’ve seen in different organizations along with their results.
| Across the board reduction in project allocation (eg 10% of developer’s time is dedicated to support issues) | This can wreak havoc with project planning as the project team never knows when that “10%” will occur |
| The development takes turn with support on-call duties | This causes a lack of continuity with development efforts, especially when developers are moving in and out of support issues |
| The person with the least development impact supports the issue | This results in prioritization discussion each time there is an issue that needs to be addressed |
| The person who developed it will support it | This creates the “ands” scenario and does not accommodate staff or role changes as the organization grows |
Does any of this sound familiar to your organization? If so, it’s time to step back and review your project plans. One of the biggest mistakes BI teams make is not acknowledging the fact that BI projects will likely have multiple releases. Each new release will likely be a new project with its own plan. Moreover IT management should acknowledge that BI needs support resources—including problem resolution experts, training, and documentation specialists—who will support new releases and enhancements to BI applications and the data they use. Factoring in these issues will allow your group to get back to delivery, and stop supporting all the “ands.”

Recent Comments