Decision governance for project managers
Project managers need to ensure that decision governance processes and controls are in place as part of the project planning. They need to perform the following roles:
•Ensure that the project is staffed in a way that supports effective decision governance
•Plan for decision governance
•Manage risks and problems that occur within the process of decision governance
In addition to the project management for governance, this chapter deals with organizational change within the context of Decision Management Systems, and the role of a Center of Excellence (CoE) in managing that change.
The following topics are covered:
2.1 Staffing the project team
One of the most important parts of managing a decision-centric project is ensuring that the environment starts off right to develop a decision governance process. Key to this is paying attention from the beginning to the roles needed, and starting with some idea as to who will fill the roles during the staffing of the project.
On a project involving operational business decisions, the most critical roles to fill from the start are the IBM Operational Decision Manager (ODM) Architect and the Business Users. Ensure that you have people who know the business to fill the Business Users roles, especially SME and Business Policy Analyst (BPA). The ODM Architect is key to the Center of Excellence for ODM, and the Business roles are key to defining the requirements and
the rules.
Not as critical, but still important is the role of Business Analyst. This is particularly true if the Business Analyst will do the authoring, which is a preferred practice for business rules. They will have a critical role in governance of the decisions.
Chapter 3, “Roles and responsibilities in governing decisions” on page 21 describes the roles and responsibilities associated with governance. Project Managers should be sure to read this chapter.
2.2 Planning for decision governance
There are two ways that organizations frequently develop decision governance plans and processes.
Some organizations, particularly ones that understand the decision paradigm and have strong business leadership, can develop their governance plan during the development of the first iteration of the decision services.
Many clients find themselves approaching governance separately after the first iteration of the rules. This can occur for the following reasons:
•This is the first time that the project team has worked with ODM, and they want to “walk before they can run”.
•The business is not ready to engage with decision governance.
•Governance for a new version of ODM is being put in place after a migration.
This chapter will present two options for decision governance planning:
•The implementation of governance within the implementation of the first iteration of the decision service.
•The implementation of governance as a separate iteration, preferably immediately after the first iteration is complete, but as a governance-only implementation.
Because the tasks are largely the same, they will be discussed only once.
2.2.1 Governance within the first iteration
The following section describes a high-level plan for a successful decision governance implementation, as implemented within the first iteration of the decision service. Some of the tasks run in parallel.
Table 2-1 presents both the first-iteration tasks and the governance tasks. Governance tasks are detailed in the dark blue boxes:
 
Tip: It is important to make decision governance one of the primary deliverables of the project. This is true whether the decision governance is done during the initial release, or as a separate release.
•Hold a decision workshop to bring IT and business together:
 – First the decision service itself is discussed, analyzed, and an initial design is done.
 – Second, governance for the decision service is discussed, analyzed, and designed. Discuss how decision services will be implemented and maintained by different teams.
•Define, build, and test the decision service and its surrounding application.
•In parallel, define, build, and test the decision governance process.
•Design, build, and test the infrastructure and deployment architecture.
•Train the business how to use Decision Center and how to create business releases.
•Go live with your first successful decision governance project.
•Create the Center of Excellence to promote decision governance to new areas of the business.
Table 2-1 Decision governance planning within the initial release plan
Task
Week
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Application Design Workshops
All Stake-holders
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Decision Governance Workshops
 
 
All Stake- holders
 
 
 
 
 
 
 
 
 
 
 
 
Define Decision Service
 
 
 
 
BAs, Architects, and Developers
 
 
 
 
 
 
 
 
 
 
 
Architect Solution
 
 
 
 
 
Architect Solution
 
 
Build Object Model (XSD, Java)
 
 
 
 
 
 
Java Developers
 
 
 
 
 
 
Test and fix defects in technical artifacts
 
 
 
 
 
 
 
 
 
 
Java Developers
 
 
 
Define Business Rules
 
 
 
 
 
 
BAs, Rule Authors, ODM Architects, and Developers
 
 
 
 
 
 
Define Decision Governance Process
 
 
 
 
 
 
BAs, Rule Authors, ODM Architects, and Developers
 
 
 
 
 
 
Build Decision Service
 
 
 
 
 
 
BAs, Rule Authors, ODM Architects, and Developers
 
 
 
 
 
 
 
Build tests and scenarios
 
 
 
 
 
 
 
 
 
BAs, Rule Authors, ODM Architects, and Developers
 
 
 
 
Script Build and Deploy in All Environments
 
 
 
 
Script Build and Deploy in All Environments
 
Provision Hardware (Cloud or On Premise). Install Product, enable firewalls, create users, roles and security.
 
 
 
 
Infrastructure Team
 
 
 
Create test scripts for Decision Services
 
 
 
 
Test/QA Team
 
 
 
 
 
 
Create Test scripts for Decision Governance process
 
 
 
 
Test/QA Team
 
 
 
 
 
 
Test Decision Service
 
 
 
 
 
 
 
 
 
 
 
Test/QA Team
Test Decision Governance Process
 
 
 
 
 
 
 
 
 
 
 
Test/QA Team
Refine Decision Governance Process
 
 
 
 
 
 
 
 
 
 
 
 
BAs, Authors, ODM Architects, and Developers
2.2.2 Governance tasks
This section describes the governance tasks required for the project.
Decision governance workshop
All of the business and IT stakeholders should be present for a workshop to learn about decision governance. They should discuss the organizational requirements for decision governance, determine requirements, and plan the full decision governance process. This is typically a series of discussions over a full week. The workshop is managed by the project manager but driven by the ODM and IT architects.
One concern is the time required for this process, particularly because if you are doing this within the first iteration, it will immediately follow the workshop defining the contents and scope of that iteration. However, leaving stakeholders out presents a significant risk to the development plan.
The decision governance workshop includes the following activities:
•Present the purpose and goals of decision governance. An individual with significant understanding of decision governance, either from within your organization or a consultant, presents to all stakeholders the unique needs, requirements, and goals of decision governance.
•Develop an organizational map. Define the current organization of the people who will be involved with the development and maintenance of the decision service. This group includes those who are involved with systems that interface with the decisions, people involved in quality assurance, end users, deployers, business users, and IT developers.
•Review the roles and responsibilities as described in Chapter 3, “Roles and responsibilities in governing decisions” on page 21. Overlay the decision governance roles and responsibilities on the organizational map.
•Describe the existing IT governance processes. Identify where the decision management needs can be integrated into the existing process. For example, many organizations have a requirement for regression testing. Regression testing for decisions may be understood as the same process as IT regression testing in your organization, which would mean that the only need in this is to provide new tools for decision testing.
•Identify and document new decision governance processes, including authoring, test, deployment, and execution processes.
•Identify supporting tools that will be needed for any of the governance processes. In addition to tools provided within ODM, you should identify any other tools that may be needed, or which are already used in your organization and would support your decision governance.
•Identify the expected organization of the decision logic, and define as project roles. For example, in our Loan Validation scenario, determining eligibility of the loan application may belong in one business organization, while a separate organization may maintain the logic for insurance requirements. These are project roles, as discussed in Chapter 3, “Roles and responsibilities in governing decisions” on page 21. For any projects that will be kept separate, identify who will be able to access that decision logic within ODM and who
will not.
•Discuss versioning plans. Will there be interim releases between main releases? Are emergency releases possible? How often will the releases be made? Identify use cases for business policy changes, how business policy changes are initiated, and what the process for approving policy changes for implementation is.
•Discuss your process for deployment, including the details of approvals required for deployment, who will deploy (IT or the Business) in what circumstances, and how decision deployment will relate to deployment of applications interfacing with the decision services.
•Discuss whether your build and deployment will be automated (see Chapter 9, “ODM DevOps” on page 127) or whether it will be manual.
•Identify how ODM will enforce these roles, responsibilities, project roles, and versioning requirements. Discuss the decision governance framework if you are planning to use it.
•Document all of the decisions made, and ensure that all attendees agree.
Defining the decision governance process
As part of the workshop the decision governance process and how it integrates with existing IT governance processes is determined. The workshop includes assigning roles, permissions, and responsibilities. The team fully vets the process against existing IT change use cases for the policy to be realized.
Implementing and refining the decision governance process
The Business Users, ODM Architect, and ODM Rule Developers implement and test access and permissions within Decision Center, unit test the process for incorporating changes from Rule Designer (for technical changes) and a variety of releases and release combinations. These tests are generally done in a test environment or sandbox version of Decision Center and not in the production Decision Center environment.
Script build and deploy in all environments
The DevOps team (or a combination of Infrastructure and Development teams in organizations which do not have a dedicated DevOps team) prepares scripts for automatically building and deploying RuleApps. Build and deployment scripts can be developed in parallel to the decision services development.
Creating test scripts for the decision governance process
The primary purpose of the decision governance test scripts is to ensure that the decision governance process works correctly. Test scripts are created by an IT QA team, and their purpose is to verify the decision governance use cases identified during the workshop. They include the following test cases:
•Test users are assigned the correct roles.
•Are the users able to create releases, approve change activities, make changes to rule artifacts, test and deploy. Are they denied access when they should not be able to perform these actions?
•If using DevOps, test the build and deploy script.
•If manually deploying, ensure that only the appropriate users can deploy.
Using a second Decision Center in the test environment
Decision Center is usually installed in the production environment. However, for testing and refining the governance process, an additional installation of Decision Center in the test environment is a good practice. This allows the decision governance process to be tested before it goes into production.
However, do not make the mistake of continuing to maintain rules in the test Decision Center after you go “live”. It is there only for testing and once fully tested, users should move to the production Decision Center. The production environment is where all real decision authoring should be performed. Occasionally, the decision services from the production environment can be brought back to the test environment if the decision governance process needs refining and retesting.
 
Tip: Plan for two installations of Decision Center, one in a test environment and one in a production environment. This will allow you to accomplish the following tasks:
• Verify governance processes and permission management
• Perform and verify upgrades of ODM outside of production
2.2.3 Governance only process
Table 2-2 on page 15 presents the timeline, in a similar format as Table 2-1 on page 11, for a situation where the governance work is done outside of a project iteration. This frequently happens when an organization is new to decisions, and needs to go through the process of a first iteration. It can also happen when an organization is migrating to a new version of ODM with a significantly different governance framework.
In this case the tasks are basically the same as described previously. However, there will not be decision development tasks interspersed between the governance tasks.
Table 2-2 Decision governance planning for governance only iteration
Task
Week
 
1
2
3
4
5
6
7
8
9
10
Decision Governance Workshops
All Stake
holders
 
 
 
 
 
 
 
 
Define Decision Governance Process
 
 
BAs, Authors, ODM Architects & Developers
 
 
 
 
 
Script and Build Out Decision Governance
 
 
 
 
DevOps team - OR ODM Developers
 
 
Create users, roles and security for Decision Governance
 
 
 
 
DevOps team - OR ODM Developers
 
 
Create Test Scripts for Decision Governance Process
 
 
Test/QA Team
 
 
 
Test Decision Governance Process
 
 
 
 
 
 
 
Test/QA Team
Refine Decision Governance Process
 
 
 
 
 
 
 
 
BAs, Authors, ODM Architects & Developers
 
Note: The Governance only process is shorter in time, because it is assumed that resources in this scenario are fully invested in governance, rather than being shared with the development team. The person-hour effort is similar, and depends on the complexity of the task. Complexity cannot be estimated until after the workshops are complete.
2.3 Project risks and problems associated with decision governance
An important part of managing a decision management system (DMS) project is associated with managing the risks and issues. The following risk areas impact the project from a decision governance point of view. If they are present, they should be identified, evaluated, and tracked within the governance portion of the project:
•Lack of communication between business and technical teams, or lack of access to knowledgeable business people.
•Lack of ODM Skills.
•Lack of Business Analysis, SME and Business Policy Analyst Skills.
•Weak project organization.
•Inadequate training or preparation in Business Rule paradigm or approach (resulting in a lack of understanding of the separate roles of business and technical teams).
•Ineffective or incomplete rule testing strategy.
•Overly complex domain model, particularly if it includes a significant portion of information the rules do not use (often occurs when an organization implements an enterprise model as a domain model).
•Implementing decision governance in an organization with weak IT governance procedures requires additional training and buy-in, especially from technical teams. There is a significant risk that the IT organization will not see the advantage or need for decision governance in this situation.
2.4 Changing your organization to realize your decision governance vision
It is frequently necessary to make changes within an organization to realize your decision governance vision. Sometimes this is only to accommodate new roles, but at times it is necessary to more intentionally organize around the decision governance process. This section describes how changes within an organization impact governance and how they can be handled.
Here are some steps to help you get started:
•Start by identifying the specific governance roles that your organization needs, including the responsibilities that these roles have. This is your governance vision.
•Map the governance roles that you identified to functional roles within your organization identified in your organization map. This action might possibly involve identifying specific people to fill a governance role. This is your governance reality.
•Identify the gaps in people or skills as well as the changes that are required to move towards your governance vision. Here are some possible changes:
 – Temporarily use external consultants to disseminate the required skills through your organization.
 – Training people (formal or on the job) to give them the skills they need. Use IBM approved on line or in class courses for this. (See reference section “Online resources” on page 170).
 – Hiring new people to complement your existing team.
 
 
Tip: Identify gaps in people or skills as well as the changes required to move towards your governance vision.
Before you attempt any organizational changes, it is important to consider the emotional response of the people who might be affected by such a change. The organizational change that is required for supporting operational decision governance and management may not be extensive, especially compared to other types of organizational changes, but it does have an impact. With this situation in mind, you should focus on two fundamental points when you consider this specific type of organizational change:
•Develop your workforce
•Communication is key
Workforce
As the organization works towards supporting operational decision management, the future needs of the organization are more clearly defined and the following questions should be answered:
•What are the new roles and their responsibilities?
•How many people are required to fill each role?
•What knowledge of your existing business logic is required for each role?
•What are the skills that are required for each role?
To answer these questions, start with a small subset of key stakeholders that can provide their input and participate in constructive discussions around the organizational changes, what the changes mean to the other stakeholders, and to make sure that most potential roadblocks are identified and mitigated early on.
The answers to the previous questions then let you identify in more detail how the gaps to achieve the goals of the organizational change can be filled. To summarize, it is important to perform the following tasks:
•Identify specific employees who play the roles that are identified.
•Identify skills or knowledge gaps and create development plans for each employee.
•Identify training and education that might be required to help employees achieve
the goals.
The key stakeholders can help provide details about all this information and prepare the material that is required to present to all the stakeholders in follow-up meetings. These meetings are important in supporting your communication goals for the organizational change.
It is important to privilege business knowledge over existing technical skills, particularly in identifying Decision Authors, Decision Validators, and Decision Testers. Operational decisions center on your existing and future Business logic, and require a deep operational understanding of that logic. It is usually easier, and often better, to train someone who knows the business deeply to write business rules than it is to bring someone with a technical background to understand the business.
Also, someone with roots in the business will develop better vocabulary, better presentations, and more maintainable, simpler rules. Technical resources cross trained to understand the business inevitably bring their technical jargon and understanding to the task, which is not good for business rules. Organizations that feel that their business is incapable of taking over the rules, inevitably have rules written by programmers rather than business experts. Business people also have a natural level of ownership of the business logic, which helps provide buy-in to the changes.
Communication
Because you might encounter some resistance from some employees, it is important for you to address this resistance quickly and help them align with the vision and direction the organization is taking. To achieve success, it is critical that communication with stakeholders take place early so that they are made aware of the change and provided with information about the change. With time, they start understanding and accept the change before they take ownership of the change and commit to it.
Here are some key points to remember:
•Communicate the vision of the change early by providing details about the benefits
and impact:
 – Reasons for the change
 – Benefits for them and the organization
 – Details of the change (when, where, and who is involved)
•Communicate often and repeat the message through multiple channels
•Involve the stakeholders by having an open dialog with them
The changes might be as simple as identifying the roles and responsibilities and assigning them to specific people in your organization. In that case, the communication may be achieved by calling a meeting with all the stakeholders that are involved and discussing with all of them the roles and responsibilities that are required, reviewing them, and assigning them to the people in the room. Then, the details can be discussed and clarified. Should you take this approach, be ready to discuss the topics about the workforce development as detailed previously.
2.4.1 The role of the Center of Excellence
It is important to highlight the potential role a Center of Excellence (CoE) has with helping an organization through a change, and with helping the people build the skills and knowledge they need to fill their new roles. While the work of a Center of Excellence is not limited to Governance, it can support the decision governance process as well as other best practice processes in relations to your decision services.
 
Tip: The CoE does not have to be an official office, at least not at the beginning. It can simply be a group of practitioners sharing their experiences with others.
The CoE can take a simplified form at the beginning where it simply consists of a community of practitioners within the organizations where the participants share their experiences, practices, and guidance with others.
This community can play an important role in the success of decision management and governance in your organization. At first, the participants are the people that run the first project in your organization, but as the usage of decision management continues to expand, these people possibly become the experts in the community.
The CoE community should help with the following tasks:
•Acquiring and keeping required skills so that the skills are available for other projects internally. This task allows for sharing of resources among multiple projects.
•Developing a broader set of people with the required skill base by supporting new people in developing their skills and knowledge.
•Providing coaching and mentoring for new people by giving them with a way to communicate with more experienced people.
•Documenting good practices and methodologies in your specific organization.
•Providing a first point of contact for people to discuss issues or challenges they are facing.
It is important to make sure that there is some enticement tied to the participation in the CoE and that the time spent by participants contributing to the community might have to be absorbed by each project. But this action might be a critical success factor for using decision technology in your organization.
The building of a CoE might require external expertise to kick-start the process and to get the CoE established. As it is built, the internal CoE staff should acquire the knowledge and skills required to keep the CoE running after the external resources leave. The CoE should also capitalize on the experience and practices of the first few projects as a starting point for future good practices, and practices to avoid!
 
Tip: If ODM skills are lacking it is a good idea to bring in temporary experts to kick-start your organization’s CoE.
The evolution of the Center of Excellence
With time, the initial CoE can evolve into more:
•Project people become CoE champions to support the next project.
•The participation in the CoE community is essential for gathering common knowledge.
•Eventually, there might be a need to fund a specific role to lead the CoE.
•Champions can eventually evolve into the next level as internal consultants as part of
the CoE.
•The CoE must be adapted so that it fits with your processes and evolves over time.
Much more could be said about the topic of the Center of Excellence, but it falls out of the scope of this IBM Redbooks publication.
2.5 Conclusion
In this chapter, we provided a high-level view of the implementation of governance from the project manager’s view, with some details as to the tasks that would be typically encountered in the implementation project.
Specifically, we noted the following ideas:
•Governance Development Activities can be planned into an initial release, or into a separate technical release.
•The identification of appropriate roles and responsibilities, especially on the business side is a crucial component of the management of a decision services project.
•Managing change is as important as managing project tasks, and a Center of Excellence can be a valuable tool for doing that.
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.103.202