In which Jill urges BI teams to roll up their sleeves and put process into practice.
Most of Baseline’s clients already have a general sense of their desired outcomes before they retain us. They need to launch a new project or begin a design or development effort, and they want the benefit of experience to start the right way.
The savviest clients welcome the knowledge transfer that accompanies working hand-in-hand with a consulting firm. They often take a “learn it, watch it, practice it, entrench it” approach. This lets them embrace change in an incremental way, incorporating new processes into their BI, MDM, data integration, or data warehouse development initiatives gradually, after putting them into practice.
But believe it or not, I’ve seen diagrams like this one scare the pants off of people:
Most of Baseline’s clients already have a general sense of their desired outcomes before they retain us. They need to launch a new project or begin a design or development effort, and they want the benefit of experience to start the right way.
The savviest clients welcome the knowledge transfer that accompanies working hand-in-hand with a consulting firm. They often take a “learn it, watch it, practice it, entrench it” approach. This lets them embrace change in an incremental way, incorporating new processes into their BI, MDM, data integration, or data warehouse development initiatives gradually, after putting them into practice.
But believe it or not, I’ve seen diagrams like this one scare the pants off of people:
Figure 1. Sample Requirement Process
We built this framework—simplified here—to instill a process for what didn’t currently exist: business-driven BI projects. Recognizing that true business-IT alignment was lacking, we worked together with the client’s key BI business sponsors to bang out a more formal process in which both business and IT would be accountable for ensuring that requirements drove BI projects.
When IT grumbled we weren’t surprised. Change invites discomfort. But we were amazed by the rationalizations for clinging to old ways. IT staff had been accustomed to throwing work over to some contractors who’d become fixtures onsite, filling in generic project requisition forms and write the odd SQL query. Indeed most of IT’s BI work was reactive. Most tasks were delegated, and most took more time than they should have. The fact that each of the steps in the new process required inputs, outputs, ownership, and delivery made some people in IT downright angry.
Consider manufacturing as a metaphor for IT development. As twentieth-century manufacturers embraced Henry Ford’s assembly line concept, they were ensuring:
As ironic as it seems, in BI—as in manufacturing—rigor actually invites flexibility. When everyone follows a sustainable development process, ownership, decision rights, and completion milestones are baked-in. Early error detection mitigates the need for reinvention and rework, allowing IT and business constituents to be clear about their commitments, and deliver them more quickly. BI teams can spend more on creative improvements, like enlisting new users, developing on-line tool and data training, and using social media tools for closer team collaboration.
Most of my new clients tend to want to talk about new technologies to acquire and organizational changes to make. What they don’t understand is that by embracing best-practice approaches to development and getting the process piece out of the way, they’re making room to have more substantive conversations about people and tools.
When IT grumbled we weren’t surprised. Change invites discomfort. But we were amazed by the rationalizations for clinging to old ways. IT staff had been accustomed to throwing work over to some contractors who’d become fixtures onsite, filling in generic project requisition forms and write the odd SQL query. Indeed most of IT’s BI work was reactive. Most tasks were delegated, and most took more time than they should have. The fact that each of the steps in the new process required inputs, outputs, ownership, and delivery made some people in IT downright angry.
Consider manufacturing as a metaphor for IT development. As twentieth-century manufacturers embraced Henry Ford’s assembly line concept, they were ensuring:
- Predictable outcomes. By instituting repeatable processes, everyone knew what the end-state looked like.
- Easier detection of anomalies and defects. As processes make outcomes more predictable, outliers come into sharper focus.
- Enhanced productivity, since roles, work tasks, and handoff points are established and well-understood.
- The ability to track and measure productivity, quality, and desired outcomes, thereby driving further process refinements and product improvements.
- More accurate time and resource estimation, since initial scoping efforts can be informed by established process times.
As ironic as it seems, in BI—as in manufacturing—rigor actually invites flexibility. When everyone follows a sustainable development process, ownership, decision rights, and completion milestones are baked-in. Early error detection mitigates the need for reinvention and rework, allowing IT and business constituents to be clear about their commitments, and deliver them more quickly. BI teams can spend more on creative improvements, like enlisting new users, developing on-line tool and data training, and using social media tools for closer team collaboration.
Most of my new clients tend to want to talk about new technologies to acquire and organizational changes to make. What they don’t understand is that by embracing best-practice approaches to development and getting the process piece out of the way, they’re making room to have more substantive conversations about people and tools.
Great post! If I'm reading it correctly, another benefit of having a well-defined process -- and having that process include real and rigorous business engagement early and often -- is that there tends to be better alignment throughout the whole project. The business stakeholders learn more about what they're asking for (the technical ramifications) at the same time the technical stakeholders learn what the true business drivers are. That involvement from both areas makes for a solid foundation for the program -- aligning both groups of stakeholders on common ground that can be used throughout the project to drive decisions as issues and hiccups arise.
Posted by: Tim Wilson | July 07, 2009 at 08:34 AM
Hi Tim!!
Nice catch. Yes, the happy by-product of a formal process is that everyone understands "when to engage." That sounds simple enough but at many companies there's still a lot of confusion about the business' responsibilities versus IT's.
Heartily agree with your comments about alignment, too. To your point, over time this means that the business becomes more realistic about what their requests mean resource and cost-wise. Because hiccups ALWAYS arise!
Thanks, as usual, for the thoughtful post.
Posted by: Jill Dyche | July 07, 2009 at 12:06 PM
I like the comments around how process can help teams become more creative. In my experience I find this to be very true but note that is does take time for any process to become efficient. When this manifests itself, true creative gains can be made.
The time between getting a process up and running and when it becomes truly efficient can be a very tenuous time as the team tries to get its legs under itself. Naysayers will tend to blame bureaucracy and use that buzzword wherever possible to discourage the use of process as it often can resonate well with those who may be listening.
Getting though this requires solid leadership that has the ability to stick to the plan and work with all stakeholders to find improvements in the process. Seasoned leadership can see the potential gains on the other side and that is what drives them though any initial resistance and efficiency issues.
Posted by: Chris Sorensen | July 07, 2009 at 08:15 PM