Chapter 7
Playbook Deployment
Abstract
This chapter focuses on getting the work done—real execution. Deployment is about deploying the Playbook methods, practices, and approaches to accomplish multiple goals. The first goal is always the improvement of enterprise or shared data. The second, which is tightly linked to the first, is the development and expansion of capabilities related to improving and governing data. The third goal is the overall course of progress that can be made across the scope of enterprise data. As we avoid the methods and build capabilities, more and more of the critical enterprise data is governed and improved in measurable ways.
Keywords
Data capabilities; Data cycle; Data governance; Deployment; Execution; Organizational models
What Do We Mean by Deployment?
This chapter focuses on getting the work done—real execution. Deployment is about deploying the Playbook methods, practices, and approaches needed to accomplish multiple goals. The first goal is always the improvement of enterprise or shared data. The second, which is tightly linked to the first, is the development and expansion of capabilities related to improving and governing data. The third goal is the overall course of progress that can be made across the scope of enterprise data. As we avoid the methods and build capabilities, more and more of the critical enterprise data is governed and improved in measurable ways.
We use different models of deployment based on what we have learned in assessment and what we understand to work best in our organization. Let’s think about organizational fit and approach first. Some companies are very project and program focused. That is, they accomplish things through defined initiatives that generally follow a waterfall or agile methodology. If your organization is driven in an initiative manner or by initiative investments, mapping deployment models to that initiative is a simple thing. If, on the other hand, your organization is focused on more progressive, long-term efforts to improve and change systems, behaviors, and processes, a different deployment method is indicated.
The two primary models we use for deployment of the Playbook focus on initiative and functional, organizational models. Most of today’s practitioners, consultants, and data governance-related positions focus almost exclusively on initiative-based work. They often use a fairly heavy organizational model to address the creation of a program or functional office and the resources applied against these initiatives. What you get in that approach is a combination of governance-program resources, organization models, and approaches layered with initiative-based sets of activities and outcomes. Our approach emphasizes as lean and simple an organizational structure as possible, since business benefits needed to justify organizational investments flow only after the work is done. Getting to the point of doing the work and proving the value in the outcomes is our primary goal. The additional benefit of taking an execution-oriented approach is that the initial experiences and outcomes help to refine the nature of the governance organization and the approach that will work best in that organization.
In our approach, we focus on using a combination of functional, cycle-based deployment activities and sprint, or initiative-based, activity sequences. These two deployment models, Cycle and Sprint, can occur in parallel, allowing for the gradual progression of cycle-based activities while initiatives sprint toward outcomes that establish value.
One of the key insights gathered from the most successful organizations we work with is the need to treat the overall data and analytics governance discipline as a function of the enterprise. Consultants and companies often treat these in terms of a program and seek to stand up a long-running program to address data and analytic needs. We’ve learned that data and analytic governance and improvement is a permanent function that business areas need to improve their performance and reduce their data and analytics operating costs.
Sponsoring these functional activities as a permanent part of a business area or cross-business shared service establishes a more realistic expectation of this work’s permanent nature and the ongoing value we expect to flow from it. The rejoinder from successful, permanent governance functions is often “as long as we have data we will provide governance.” This type of permanent commitment and thinking is a much more aligned approach to handling critical business assets, as well as program and project methods, alone. The permanent, functional approach and commitment also supports initiative streams, which are often focused in multiple directions and use different underlying themes to produce the required results. For example, one of the first things we do in initiative planning, where we use sprints or other agile methods, is to identify whether the initiative in question is defensive or offensive in nature.
Playbooks are often discussed using defense and offense analogies. We have been very clear and specific about the “three lines of defense” model for defensive Playbook initiatives and deployment. We are also very clear about what constitutes an offensive set of Playbook activities and what the business focus needs to be to produce offensive results. In the offensive world, we are thinking about scoring additional revenue, cost reductions, market share improvements, and other forms of measurable growth in the overall performance of the enterprise. In the defensive space, we are focused more on three lines of defense, which identify, reduce, or remediate risks to the safety and soundness of the business. These distinctions between all offensive and defensive actions are critical to make at the initiative level. However, they can also be supported equally well at the functional level. This explains the need to have some functional focus while still supporting different kinds of initiatives over time.
When we talk about offensive and defensive deployment approaches, we are addressing both the corrective activities to use and the appropriate way to scope individual initiatives, prioritizing them from a governance perspective. Our assessment results have helped us keep, map, and prioritize areas that are suffering from weak or absent controls for defensive initiatives and identify areas poised to benefit the most from offensive Playbook sequences. The mix of defensive and offensive initiatives required over any period of time informs us about the related resource requirements and functional governance support needed to make these areas successful. The overall balance of initiatives work informs the governance structure and resource provisioning process. This information allows the governing structure and operating model to adapt to the data and analytics requirements the organization has for governance and improvement.
The graphic above visually depicts the lines of defense and offense we described earlier. The “three lines of defense” maps directly to industry standard approaches, leveraging business, risk management, and audit professionals in the definition tracking and resolution of enterprise risk. This model is well-established and heavily relied upon, particularly in financial services and other heavily regulated industries.
In addition to the three lines of defense, we’ve identified all offensive lines that are focused on providing enterprise performance improvements related to revenue, profitability, market share, and other key performance indicators. Initiatives are focused on either defensive or offensive goals, and multiple initiatives can be operating simultaneously against both sets of goals. The positions identified in the graphic illustrate the fact that each position can be played by separate people. In some cases, the same person or role may be focused on multiple positions. When we have a single role such as internal auditor or risk officer asked to play in multiple positions, we are probably seeing multiple initiatives.
The center of the field holds the core governance-operating model. At the heart of this model is the notion that we are building a set of data and analytic leadership capabilities into the firm. These
capabilities are intended to balance application- and process-oriented capabilities that are already strongly in place in most firms. Data disciplines and capabilities are still comparatively new process management and application technologies.
From its earliest inception, information technology provided both process and data automation through its execution in the mainframe and distributed computing environments. Applications and application suites met almost all data and reporting needs, until data warehousing and operational data stores emerged less than 30 years ago. These information technology constructs, combined with analytics-specific data structures and applications, formed the basis for a data discipline and emerging data-capability requirements. Some data and analytic capabilities are still relatively immature, and we are all working to better define, develop, and deploy them for enterprise benefit.
The core of the graphic focuses on the functional or permanent governance capabilities, resources, and operating model required to achieve data and analytic leadership. It is in the core that we find the governing committees and standing groups that many people focus on so heavily from the beginning. Our approach suggests that some understanding of an initial set of governing principles and organizational models is necessary, but the initiatives that deliver value must be engaged quickly in order to inform what the overall governing structure will need to look like over time.
The three key goals and objectives of the core governance function start with a controlling approach in Govern and Control. This leads to an Improve and Leverage set of functions, which ultimately result in the ability to Standardize and Integrate enterprise data and analytics. These three functional focus areas are embedded in the Playbook methodology and framework to ensure that, as we progress through deploying Playbook methods and activities, we are building these capabilities throughout the organization. The permanent governance function and organization must support this capability buildout, maturing ahead of the initiative work used to develop enterprise capabilities.
We are now ready to visualize the different progressions that can be accomplished throughout the enterprise for both core governance functions and initiative-based deployments. Since this visualization requires a three-dimensional construct, we use a cube visual model help explain these concepts.
The three dimensions of the cube help us understand the volume of work and progress that is needed across the company. We use the face of the cube to describe the capability areas from left to right and levels ascending from the bottom to the top. These levels are achieved over time and indicate a level of maturity for each of the capability areas listed at the base of the cube. The depth dimension reflects the fact that lines of business, geographies, and other organizational constructs have to be addressed over time. This underscores the notion of volume: the range of people and organizational units that are ultimately touched by and engaged in data Playbook work. This 3-D cube also allows us to visualize different ways of progressing across capabilities and through levels within any one part of the organization.
The intersection of a capability level and a capability area is where we find detailed activities that must be performed. So at Level I for the capability area Govern Programs and Services, the Playbook will provide a number of skilled activities that must be performed to complete that level. Deployment is about sequencing the activities based on our assessment of capability areas and levels that provide for the necessary business benefits or risk reduction. The plan is also about developing a sequence of organizational units or business areas, across which we do this work. Deployment requires thinking across all three dimensions, in order to specify meaningful sequences of activities and engage the appropriate people to produce the required results.
Deconstructing or exploding the cube makes it possible to visualize different sequencing scenarios quickly. It becomes easier to imagine different business areas or organizational units progressing at different paces based on their risks or business benefit requirements. It also breaks down the typically monolithic view that maturity models impose on our work. While an aggregate or enterprise view of maturity is useful, it is so highly abstracted that it obfuscates the real progress being made in key areas of the organization. Average or overall levels often mask critical gaps and insufficiencies in our progress. These abstracted views are also difficult if not impossible to reconcile with our data and analytics dashboard, which identifies specific areas suffering from gaps in governance, controls and quality. We therefore need to use this exploded view to gain a realistic understanding of our progress and to visualize the best sequence options for planning future work.
The exploded view also allows corporate governance leaders and distributed stewardship leaders to engage in business area planning independently and then combine their plans to produce an aggregate view and resource requirement. Engaging the lead stewards for each area in this type of planning enforces a commitment that can be communicated to their sponsorship, while providing central governance with a coherent view of how each unit intends to progress. Marking that progress against the projection is easy and provides compelling proof of progress. Finally, our ability to measure outcomes in each area and align them with the progression the area is making supports the overall data and analytics governance function for the enterprise.
This approach to planning and reporting on overall enterprise progress is critical to maintaining executive sponsorship and communicating our overall progress. We break this prospective down further to get to a level of detailed activities we will sequence in order to achieve these maturity levels across the organization. The construct for activity-level sequencing is a simpler, 2-D view showing capability areas and levels that then deconstruct into specific activity sets by capability level and area. We call this a capability progression view as shown below.
We use the cube deployment model to depict our progress in executing Playbook activities across capability areas and levels. The cube also helps us depict the progression of these activities across lines of business or business areas. The cube also introduces the ability to track and display both governance progression and capability improvement at a granular level of detail.
There are some standard units of measure that can be applied when doing these cube models and assessing our progress against each of these capability levels. The first unit of measure, activity level detail, is described in the sequence graphic. But activities alone do not convey a false sense of scope. It is often helpful to explain that we scope our initiative level work using a standard quantity of critical data. Typically, we can handle between 30 and 50 critical data elements in a short, rapid data sprint that moves us from Level I through Level II. To get some perspective on how many data elements you may be facing in any single business area, let’s look at some examples from real-world work. The first is from an end-to-end finance data analysis for a Fortune 50 financial institution. In this case, the institution engaged in a level 1 data sprint aimed at cataloging and analyzing its financial critical data. The outcome resulted in two key assets. The first was a simple chain of custody diagram that indicated the flow of critical data through finance.
Key systems and controls were highlighted in the chain of custody diagram such that it looked a bit like a dataflow diagram but operated at a higher level with some details about control points and control types. The second asset was a working glossary of terms that were derived from financial statements, disclosures, and management reports. These terms were mapped back to the physical data the chain of custody illustrated. The result was a group of about 350 data elements or terms that were clearly defined at the logical level and mapped to over 3500 physical instances in the chain of custody. This gave us the scope of 350 critical data elements we needed to move through Level II governance and toward Level III, in order to map to the required testing and quality controls. This approach of combining top-down, logical business terms with bottom-up, physical data and system flows proved valuable and rapid enough that within four additional, short-term data sprints we had reached Level II for all 350 critical data elements.
Later in this chapter, we will detail different sequences and give estimates of duration and effort required to accomplish the sequences of activities as you move through maturity levels with defined blocks of data.
In this view, we see the five maturity levels depicted as chevrons and the four core capability areas depicted as end-to-end arrows underneath them. The stair steps above the chevrons refer to the overall progression that is accomplished and referenced in the core of our cover graphic model.
We have seen a lack of coherent target benefits and outcomes provided in initial data governance programs as well as product and consulting marketing approaches. Getting it “right from the start” was a hallmark of our experience as partners at Knightsbridge Solutions. Knightsbridge used this term in its marketing, selling and delivery to ensure we communicated the expected, long-term outcomes with our clients from day one. Today, we are very careful not to talk in generic terms about the value of governance or the need to treat data as an asset. We’ve all learned that more specific goals, objectives, and measurable outcomes are needed in order to secure permanent, long-term sponsorship from our executives.
The three stair steps communicate what is achieved as we move through the five maturity levels and allow us to target what level is most appropriate to the needs of the enterprise and the level of sponsorship we currently seek more precisely.
Let’s briefly review the five maturity levels and four core maturity areas we defined and supported with detailed activities in Chapter 4. Our model does not start with chaos or uncontrolled environments. “Defined” is the initial level our activities target and the minimum level that must be achieved to move forward in any progression. So while the entry point for these activities may be uncontrolled and undefined, we chose to begin our maturity progression with an initial level that is meaningful and foundational to the rest of the work we must do.
The remaining maturity levels build on a defined state through controls, improvements, standardization, and integration. Each of these levels is clear and distinct enough to support equally clear and distinct activities. As we reviewed in Chapter 4, these activities are also clear and specific about the capability area we are addressing. This distinction is critical, since we do not expect overall capability progression against multiple or undefined capability areas. We also know from years of experience that different clients require different capability area progressions at different times.
The four core capability areas we have defined in this book start with establishing your permanent governance function so that the detailed activities for your governance are included at the start. Then we progress to Stewardship activities and advance into Data Relationship Management and finally Quality and Risk Controls. Each of these areas has distinct activities that can be sequenced into both defensive and offensive sequences of activities. It’s worth noting that, as your experience probably indicates, capability areas must often be addressed simultaneously, particularly at the outset of a new governance function or overhaul of previous attempts.
Both the governance program and stewardship capability areas must be executed together to deliver results. We covered the details of the Playbook model in Chapter 4, so this summary is provided to explain the relationship of the Playbook maturity progression to our cube deployment model.
Several things become apparent when looking at the sequence slide. The first thing you notice is that each capability level has a distinct set of activities associated with it. We know from our assessment work that these activities provide both the checklist and guidance on what needs to be completed to establish progress in each capability area within a particular part of the organization and its scope of data. Providing a clear sense of how much progress each part of the organization has made is one of the challenges of reporting to management and executive teams. It’s important to be distinct about progressing the level of governance, controls, and improvement for a certain set of data. We need to communicate the pace of improvement resulting from the overall level of work being completed.
The second thing you notice is that certain capability levels have more activities or appear denser than others. This has to do with the level of intensity required to get through the first two to three levels of capability. There are simply more activities to be performed in early stages of capability maturity than in later ones. Some of these are necessary on a single iteration basis, and others are needed repeatedly. As in so many areas of our life and work, our future work stands on the shoulders of what we produced before. So it’s fair to say that the initial foundation is packed very tightly, which allows it to support a very broad base of data analytics for governance and improvement over time.
We’ve also learned from many client experiences that there are additional activities to be defined for later maturity levels. Very few programs or functions have reached the later levels across the enterprise. There is also the changing nature of Big Data and analytics that emerges only as this very young field matures.
Another thing we notice in the sequence graphic is the lack of lock-step progression indicated by this layout. There are many ways to sequence activities and there are dependencies from one level to the next or even across capability areas, which we often treat as workstreams. These are called out in the Playbook in a detailed level, but overall there is great flexibility in the way you combine activities to produce results.
Mapping Your Deployment Priorities
Getting to the point at which you know what you want to accomplish and are ready to produce your sequence is a four-step process. This chapter focuses on the last of these four steps: defining and managing your deployment sequences. The first three steps are addressed in general here and more specifically in our assessment chapter.
A demand pipeline approach provides a window into your assembly process. Using strategic weighting allows all your constituents to see the application of enterprise priorities to their demands. Once you have this ranked demand list, you can start sorting across the top priority items to determine your scope areas and required activities.
Deployment schedules provide an overall program plan. This schedule operates much like an audit plan that typically shows the annual rotation of internal or external auditors through a business by line of business and geography. The deployment schedule shows all the business areas and their respective data scope. This allows you to interact with your constituents and sponsorship to fully validate your course of action for the year. It is important that this schedule allows for some gaps in order to adjust to new priorities or events in the business and to support the ongoing recruiting, training, and career development of your teams.
The Overall Process of Deployment Planning
Generating deployment sequences from this point is a matter of identifying critical activities and their sequences in multiple executions areas. These areas each have a data scope specific to the priorities you are addressing. A finance area such as antimoney laundering (AML) might include data about certain types of financial transactions and counter-parties. At the same time, you might be looking at another area whose data scope includes counterparty risk. Both areas may need the same types of activities from the Playbook, so you assemble the activity sequence and then determine the need to stagger the two areas’ execution based on overall resource availability. This last point is important, because resource availability and overall business activities in each of these areas must be taken into account. You may have the right resources to commence with each area at once, but the business, in this case finance group, may be engaged in year-end close or audits and have limited time and access for your teams.
Deployment Patterns
Data Cycle
There are many approaches people use to implement data and analytic governance. We’ve boiled down two distinct approaches that we’ve used to good effect with many customers across industry and government. These simple approaches each apply to distinct situations. While many variations and alternatives exist, it is very helpful to a program or permanent business function engaged in governance to establish two consistently used tracks. Each track must satisfy the requirements of either an organizational or project-based approach. Each of these approaches leverages the same Playbook activities and resources but allows for different ways of executing and leveraging resources over time. The continuous cycle braces an expansive set of maturity levels. The goal is to produce a sustained set of controlled and improved data that can adjust to changes in business process, reporting, systems, and operational approaches over time. So the continuous cycle pattern is intended to address the breadth of the Playbook, including improvement and often standardization and integration.
• Ongoing maintenance and publication of data catalog/business glossary with parttime data stewardship
• Automated, ongoing profiling of data using database and business rules tests to determine quality and identify issues
• End-to-end traceability of data quality issues for root cause resolution
The first of these is a cycle approach used when we’re deploying in an organizational or functional area. This cycle engages people in the area within your scope through a continuous approach. This is the permanent organizational function we have discussed previously. This approach requires a continuous cycle, because we are placing data stewards, analytic stewards, and others in a position of ongoing responsibility for their data and the changes that occur within that responsibility. So this continuous cycle provides an initial governance standard and an ongoing change control function. Improving the maturity and outcomes of any governance capability across an organization requires some continuous cycle to provide sustained change control and other governance features. Thus consider, even within the scope of project-based governance activities, the need to follow your project with the continuous cycle approach.
The first stage in the cycle is the development of context. This establishes the scope of data, processes, organization and resources, and intended level of maturity to be reached over time by cycle iterations. Level I of the Playbook, or the “Defined” level of maturity, includes a number of activities that establish context for both the scope of activities, and the current condition of the data. The second phase in the cycle refers to establishing ownership and controls over the defined data or analytic constructs. The goal in this phase is to identify and assign responsibilities to owners of key data and analytics constructs. These owners, and the stewards they engage within their business or operational areas, are responsible for both change control and improvement of the data and analytics.
The stewardship phase engages the stewards, with owner support and approvals, and establishes the ongoing work to control changes and improve quality. The first responsibility of the stewards is to provide controls around the defined data and analytics. These controls include change controls and basic data quality discovery and measurement controls, otherwise known as detective controls. Stewards become responsible for knowing the data in their scope, the quality and issues of that data, and the process for controlling changes to the data. We are not trying to control regular flows of value changes in data; rather we are controlling changes in the structure and the meaning of the data through a consistent data stewardship pattern.
The “Improvement” phase builds on the work done by the stewards to date, because they have established the quality level and issues in the data within their scope. Improving quality for data and analytics also requires stewards to understand the demands users have and the ways users consume their data and analytics. Some quality improvements are prioritized based on the impacts the quality impairments are having on critical users of their data and analytics. This cycle closes with updates to context as a result of improving the quality of data and analytics. The context is expanded by both outcomes of quality improvement, including insights into additional data sources or analytic models needed to satisfy business requirements. Context is also expanded due to incoming changes in business process and data. As the context changes, the rest of the cycle is engaged. These changes drive additional data and analytics, requiring the other stages to be completed.
Data Sprints
The other approach commonly required to implement data analytics governance is a project-oriented approach we call data sprints. These projects require a much more agile, rapid execution rate and typically have a limited scope of required governance. Our experience indicates that data-intensive projects such as system transitions, transformations, and reporting analytics programs often need a level of governance that provides definition and control with only limited improvement. Sprints are very compressed, so we use a segmentation approach to limit the scope of data any one sprint addresses. The key is to complete sprinting for weeks, sometimes even less. The word complete refers to reaching a level of maturity for the data in scope. Typically, this level is Controlled, not just Defined. It is important that projects produce controlled data outcomes and so simply defining the data scope and the individuals responsible for it is not typically enough to satisfy the program requirements. Moving to a level of control over your data and analytics as part of your project or program ensures you deliver an outcome that can be sustained. At this point, it’s worth reiterating the need to follow successful projects and programs with continuous cycles of governance and improvement.
Sprints can be very aligned with agile methods and can use a variety of their tools, including daily scrum calls, scrum master, and other hallmarks of agile methodology. While these agile methods are not required for data sprints, they have proven highly effective in managing multiple, parallel Playbook activities across resources and within a short period of time. Daily scrum, or hogwash calls, are the single most important tool we found in assuring two key aspects of the sprint are successfully applied. The first is providing an opportunity for all team members to share major issues they face, which operates as a communication tool and a way of getting help or escalating issues. The second and equally as important facet is the ability to engage your sponsor or senior executive in these calls so the entire team feels the support, engagement, and sense of urgency executive sponsors bring to the table. These calls should be tightly run and take between 5 and 15 min to complete. We do not discuss details of an issue or options for resolution on the call. We log the issue and understand the timing and criticality of it, then assign it to the program manager or scrum master for later follow-up to make sure we understand the root cause and can assign actions to resolve it. Every issue raised is addressed the same day by the scrum master with appropriate team members. These methods have proven invaluable to executing sprints in 30 days or less on a consistent basis.
The other key driver to success in fast, short sprints is segmenting or scoping the data you will address. We think in terms of multiple, parallel sprint executions and so we tend to segment data based on the subject of the data. The key team members will be on the sprint to get that data to a level of definition and control within 4 weeks. It’s also important that you provide your data and analytic services partners with sufficient capacity to institute data-quality profiling on a discovery level in order to ensure you can actually apply controls into a second sprint event. This preserves the integrity of the execution and highlights gaps in business or other resource availability. A sprint lives and dies on the sense of urgency and the daily heartbeat of scrum or team calls and issue resolution.
We have found that between 30 and 50 data elements are appropriate to address in the scope of a single sprint. Similarly, we have found that three to five analytic models, depending on complexity, are an appropriate scope for a 30-day sprint. Exceptions abound however; we have seen upward of 20 analytic models get cataloged and have basic controls applied in a 4-week sprint. On the other extreme we have seen as few as 12 data elements fully addressed to Control level in a 4-week sprint. The differences in these ranges are often a combination of the complexity of the data or analytic models we are addressing and the information availability and turnaround time we get from key resources. We often have to distinguish effort from duration in the sprints.
• One-time cataloging, mapping, and analysis of data
• Project documentation (excel)
• Validated migration of catalogued data to the target system or store
The sprint diagram is a reflection of the way we often have to communicate the groupings of activities for our constituents and participants to understand. We use the Playbook and a sequence of activities to create a project plan with assignments and estimated durations and effort levels. But this high-level view is helpful with sponsors and with people whose resources we need to leverage. It’s also a convenient way to communicate some of the parallel execution features and dependencies of the data sprint.
Communicating Data Sprints
Data sprints can be difficult to explain to people who have not been through a project-oriented implementation of governance. Reactions to an initial discussion range from pushback all the way to an insistence that a continuous cycle approach is used in parallel but not as part of the project itself. We have developed some basic communication language to explain what the key hallmarks of a sprint are and when it is best used. The following is an excerpt from communication we’ve used successfully with several clients.
1. What is a data sprint?—A rapid, agile, and repeatable process using standard methods from the data management Playbook to assess, address, and establish controls over data and data-related processes, people, and technology.
2. How does it work?—As a planned series of activities conducted jointly by a scrum master and sprint leader and resources from internal business, operations, and technical areas as required by its scope and targeted outcomes.
3. When is this needed?—Nagging data issues are costing more than it will take to resolve—you need a proven, repeatable process that engages the right people quickly and inexpensively. It is especially needed when:
a. Controls or risk issues are clearly data-induced and require resolution, eg, AML, risk management, financial and client reporting errors, protracted financial and performance reporting issues, etc.
c. There is no clear process to engage technical and business stakeholders and to identify or resolve data issues; constant, redundant efforts, data stores, and interfaces are used to plug gaps and replace suspicious data.
d. There is no clear connection between operational challenges and the sources of the issues, or between reporting inconsistencies and sources.
e. Data governance has become an imperative, but it is not clear where or how to start without a massive program; you need to start small, win big, and iterate.
4. Key Features and Benefits
a. Fast, proven, repeatable process that can be taught across internal teams, which reduces external consulting cost
b. Establishes root causes and best alternatives to resolve nagging, costly, and risky data issues across processes and systems
c. Provides a solid foundation for ongoing data governance and quality monitoring
d. Is iterative and parallel; many sprints become relay races covering critical business, operational, and technology areas
5. Proven accelerators (execution and value realization) include:
a. Standard deliverables and templates transferred to client teams
b. Real scoping practices (this is the biggest stumbling block for data improvement and governance)
c. Data landscape review—quick context for planning and engagement
Data Risk and Exposure
Maturity models have been in common use for decades and can be very helpful in understanding where there are gaps between our current execution level and our desired or required level. It’s important to think about capabilities as the embodiment, or instantiation of skills, methods, and execution. Thinking about capabilities as a general construct relating to how smart or capable you are is not helpful in a business context, unless it is tied to a consistent execution level that measures to the capability model.
We have learned over the past 25 years that even the use of execution-oriented capability models is not enough business justification for major investment. Major industries, including financial services, healthcare, technology, professional services, and even government and regulatory bodies, have all shown the need to apply risk-adjusted approaches to data and analytics governance. Our approach to this is very simple and stems from our experience in internal audit, regulatory, and compliance work.
As an auditor, I was taught two key constructs of audit and control. The first was that there was “no substitute for controls conscious management.” This refers to the fact that implementing, maintaining, and testing controls requires executive support, based on the certain knowledge that the lack of controls will, very quickly, result in losses and damages. Therefore controls-conscious management is a critical component of the well-run organization. Seems simple enough, but we all know of companies with significant gaps in controls consciousness and commitment.
The second thing I was taught by the same internal auditor of a national bank, Mark DeLong, was that measuring risk alone is insufficient. Risk is required but not sufficient, because the likelihood of a problem occurring alone does not allow us to evaluate the impacts it could have. We have to measure both the risk of a thing happening, and the exposure we suffer when it does happen. So risk and exposure are the two levers we have to pull together to understand how likely the problem is to occur and how much it will impact us when it does. High risk of recurrence of things like cash and marketable securities losses due to poor physical controls is critical. Extremely high loss of paperclips is probably not such a critical issue. So measuring both the likelihood of a problem and the cost of it are critical to prioritizing the controls we put in place or improve to reduce risk. Mark taught me the balance between controls, risk, and exposure. Our entire Playbook rests on this construct and suggests the need to use risk and exposure ratings to prioritize our controls work with data and analytics. The third thing Mark taught me is that “risks don’t age well,” so our ability to identify, monitor, and control for risks is critical. DeLong is now Senior Vice President of Risk Management at Freddie Mac.
This Risk Thermometer graphic addresses the typical range of thinking people have about risk. It suggests that, as the risk of the thing occurring increases, we would increase the level of maturity we need for it. This is a very unidimensional approach and is necessary but not entirely sufficient for prioritizing our controls work. We have to move to a 2-D model to compare risk and exposure. After all, the risk of losing a lot of paperclips is probably not sufficient to justify a business case for paperclip governance, since the costs outweigh the benefits.
So we moved from the thermometer image to a 2-D approach that allows us to compare risk and exposure on their own axes. This risk-adjusted maturity model is actually risk and exposure weighted. This gives us the ability to determine the materiality, or overall importance and value, of a challenge we face with data or analytics. By scoring each problem or challenge for both risk and exposure, we’re able to place it on the grid and understand its relative importance and priority. We’re also able to identify the target level of maturity needed for controls, based on the severity of risk and exposure to any problem or challenge. While the placement of these maturity levels can vary, the overall notion is that, as risk and exposure increase, the value of higher-order controls such as improvement or corrective controls and standardization or the introduction of preventive controls is merited by business impact. So this matrix gives us a simple, visual way to understand the relationship of risk and exposure and the required levels of maturity as risk and exposure rise together.
Let’s use some examples that have been cleansed from various business settings. This table uses five discrete challenges that were identified to various detective controls approaches. In some cases, these were a result of a business need that created a project, while others came from detective controls over the review of reports and analytics that identified material variances. In each case, these have been vetted and scored as well as assessed for current maturity.
This table gives us the ability to prioritize based on a combination of risk and exposure, to establish our risk and exposure grid, and to set the target level of maturity we need to reach with our controls for each challenge. It is often helpful to use the grid as a scatter graph or plot of the density and set of risk and exposure challenges we’re facing. In the graph below you can see that we actually have a broad array of both risk and exposure in our challenges. We have seen high exposure issues brought down
across the board in organizations that engage in a programmatic approach to steadily maturing high sensitivity or impact areas. Many first-generation data governance programs and current attempts to govern analytics are lowering risk but not the high exposure areas first. This seems counterintuitive, especially when you consider the fact that the controls improvements made in high exposure areas often result in building overall knowledge, competency, and execution experience in the organization. This knowledge will help address the other areas you need to resolve.
Deployment Scoping and Planning
Now that we’ve addressed some of the ways to figure out which areas are most important to address and what deployment pattern options you have, we can move on to scoping and planning efforts. It is important to remember that we’re using our maturity levels to group the kinds of activities we must perform in order to reach a certain level of control. This is the overall Playbook content structured as a maturity model, with each activity grouped by level of maturity. We use this in order to select the activities we group for both sprints and continuous cycle of deployment patterns.
In the cycle approach, these activities are bundled based on the descriptions we gave you of the continuous cycle. It’s important to note again that in continuous cycle patterns we generally target a higher level of maturity to reach and sustain: typically at least Improvement and generally Standardization. Note that integration requires a distinct business case around consolidating duplicate or overlapping data and analytic platforms or content. In contrast, sprints typically address a narrower range of activities and limit themselves to reaching the maturity level within a short period of time and for a limited scope of data.
The project plan example above provides a visual representation of the way cycles can be planned and executed. The important thing to recognize is that cycles continue past their initiation. Any cycle initiation is typically about 3 months in duration, during which time you rotate through one cycle in one area of the business. That means engaging all the roles and executing on the Playbook activities based on a description of the cycle approach. There is another critical aspect of the cycle that is indicated in the project plan view: the tale that runs continuously from the initial cycle. We know that the cycle is continuous and that while there is a heavier amount of work to do the first time you execute the cycle, there is continuing work around change control, context updates, and improvements as business conditions, processes, and data change. It’s also important to note that the cycle can be focused only on data governance, or on analytics governance or, in some cases, both.
In the cycle project plan, you are trying to depict the relative scale of activity and effort in the initial cycle as opposed to the ongoing iterations. Business and operation folks generally ask how big the overall work effort will be, particularly on an ongoing basis. Much has been written around business cases for data and analytics governance and business impacts and outcomes. The truth is that we consistently find that once a standard set of methods, such as the ones the Playbook provides, are adopted and people’s skills and experience allow them to execute quickly, the amount of time per day, week, or month that a data or analytic steward spends on governance is a half to a quarter of the work they were spending to manually handle data or analytic issues.
Some other takeaways from this visualization relate to the amount of parallel execution your program can support. Remember, there are more shared or managed service resources needed to orient, train, and mentor business data and analytics stewards in this work. There are always questions and requests for help in the first iteration of these cycles. So it’s important to think about the scheduling of cycles across business areas based on the business areas’ annual calendar of activities and your resource capabilities to support multiple first iteration cycles at the same time. We’re often very sensitive to fiscal year and closing processes, major system events, planned business acquisition, or disposal events and overall reorganization and transformation efforts. That is not to say that this should be delayed until the weather is perfect and everyone is bored. We must prioritize and then adjust the pace at which we proceed based on the reasonable expectation of business participation, resource availability, and a stable work environment.
A final note on this cycle approach is to consider the availability of key data services from your partners at the end of the first cycle. A critical example here is the need to continue to run rules-based data profiling after the first cycle completes and updates the data-quality dashboard or heat map for each area where a cycle is completed. The enterprise data-quality dashboard or heat map is a critical service that short-share data service groups can provide. It’s very difficult to start a first cycle and come to the end only to realize that you are not prepared to continue key aspects of governance. Thus it’s also important to ensure your data owners, sponsors, stewards, and their analytics counterparts are lined up with the expectation of continuing their commitment and executing the new skills and capabilities they’ve developed. The cycle of deployment pattern is all about starting with a clean, single iteration but committing to a sustained effort that drives sustained controls and improvement.
The sprint approach, in contrast, is focused very differently. We use data sprints and analytic sprints in a very project-based approach, which is intended to provide a major project with controls and improvements based on its needs and scope. This is not to suggest that we do the work and a sprint with the expectation that no ongoing controls will be left in place. Quite the opposite is true, we seek to tie project areas that execute a sprint back into an organizational cycle that will result in a set of controls that are executed wherever possible. Not all projects need to result in ongoing governance. Many projects around sunsetting or consolidating systems, disposing of certain business assets or lines, and even certain reorganization or transformation projects will end without the need for permanent governance. It should be noted that, in the case of transformation programs, a cycle or multiple cycles are required in order to instantiate data and analytic controls and governance as part of the transformation itself.
Just as with the cycle pattern, the sprint pattern can accommodate a certain amount of parallel activity. The constraints here are similar to those in the cycle, because supporting projects doing sprints requires the same enterprise or shared services capacity that cycle iterations required. Projects and the sprints we used to support them are often more intensive, because they’re very short. Therefore the time allowed to help the team in a project understand the key activities they need to perform as part of governance is very limited. So in sprints, we use a simpler approach, and we limit the number of activities based on the need to get to a “controlled” level of maturity.
There is a risk with the data sprint or analytic sprint approach to addressing all your data or analytic issues in project form. It’s important to balance in your overall planning and roadmap activities a set of cycle patterns as well as sprint patterns. We’ve seen some of the best results occur when sprints were followed by cycles. This can be difficult because sprints are typically a project to construct and not subject to the broader scope of an organization or business unit cycle. Sprints are often very tightly scoped to as few as 30 to 50 data elements and must be completed in 30 days or less. To the best extent possible, it is very useful to make sure you plan your project-based sprints in a way that bundles them with business areas to create an initial critical mass for a follow-on cycle.
We depicted an example of where a cycle follows a sprint in the project plan. It is possible to use a shortened initial cycle when a sprint has covered enough scope to the level of “controlled” maturity. Typically, project-based prints cover too narrow a scope of data to shorten the first cycle duration; often a series of sprints leads into a cycle with the ongoing sustainment tail at the end. This is probably the best way to think about using a sprint in the project to drive to a more permanent governance function in the area that is home to the project.
Conclusion
We started this section of the deployment chapter by describing the fact that many different deployment patterns exist and are appropriate or valid depending on your needs and the skills of your organization. We highlighted two approaches that have worked well with our clients in a number of settings. We know it’s important to be able to support both project-oriented needs with sprints as well as ongoing committed governance functions with the cycle deployment pattern. We have also learned that where we start in a project with the sprint should be followed, whenever possible, with a cycle that sustains the governance we have started to put in place in the project. Each of these deployment patterns leverages the same standard activities, milestones, tools, and services called out in the Playbook. This means that you can reliably plan and execute either sprints or cycles because the underlying activities are standardized and can be consistently applied given a disciplined scope.
We encourage you to use your own terms to describe the deployment patterns here or variations you find more suitable for your organization, but be sure to do so in a way that is consistent. This consistency helps people understand when they should select a deployment pattern, based on their scope, timing, and required outcomes. Encourage people to consider cycle or permanent governance approaches at the tag end of their project-related efforts. In truth, there are very few sprints; most races are relay races that require ongoing cycle-based governance.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.