The Emotional Side of Lean

I read an interesting article in January's edition of the Journal for Quality and Participation about the need for emotional intelligence in a project. It’s by Rangarajan Parthasarathy, and you can read it here. It pulls together the principles of project management, evidence-based management, and the emotional quotient necessary to making a project successful.

In order to truly make the recommendations of a Lean project work, you have to have more than just knowledge of statistics and Lean tools and how to apply them to your project. You should reach across the groups with equities in the program and work the kind of relationship management magic that creates an atmosphere where everyone is looking forward together toward the same goal. You have to be able to create a sense of ownership among the stakeholders. Essentially, you must “sell” the solution.

It’s hard to find good project leaders who can consult as a part of the team without losing the evidence-based management required by Lean. A great way to overcome that is to assign specific roles; partner a person with the “soft” skills required to keep all of the people and personalities running in the same direction with a person that has the quantitative ability to keep the data collection and analysis clean and productive. I believe that the lack of attention to the emotional side of a project, particularly the acceptance and ownership of the resulting changes, is a preventable source of failure.

Role Based Access Control – Part III: Defining and Implementing Roles

We have discussed the benefits of Role Based Access Control and outlined a method to rationalize user applications as a first, critical step in the roles definition process. Today’s discussion provides an overview of how to define the roles that grant users entitlements to applications and systems. This process includes the use of role mining tools, the definition of role structures, and the development of a role catalog.

Role Definition Step 1: Leverage Mining Tools and Methods

Once application rationalization has been completed, we can safely assume that our applications are aligned to our organizational roles. At this point, we can formally define our user roles by collecting and refining this information to derive a role model. These roles will be closely tied to your existing job positions, which will map to a defined set of applications and access levels. For organizations with a large number of employees and applications, we recommend using software to assist in managing the role definition effort. Some products to help you accomplish this task are:

· CA’s Eurekify Sage

· Sun’s Role Manager

· SailPoint

These tools analyze existing user access patterns across multiple systems and applications to define access privileges and associate those privileges to roles.

Role Definition Step 2: Determine Role Catalog Structure

A Role Catalog is a database designed to help manage the list of roles and information about each role, and most RBAC products have one. Role Catalogs are an important tool because they associate each role with permissions, policies (e.g., separation of duty), and even other roles depending on the type of role service levels being managed.

Current RBAC standards define four role service levels, and we recommend using these standards to define your role catalog structure. The rules are:

• Level 1 - Flat RBAC – establishes and maintains many-to-many relationships among user-role and permission-role assignments.

• Level 2 – Hierarchical RBAC – extends coverage to include user-role and inherited roles (role-to-role) assignments.

• Level 3 – Constrained RBAC – applies separation of duty constraints and policies, both static and dynamic.

• Level 4 – Symmetrical RBAC – provides a permission role review and auditing interface for role administrators.

Source: The NIST Model for Role-based Access Control

Role Definition Step 3: Define a Hierarchical Role Structure and Role Inheritance Model

The number of users, the types of roles and your security requirements will help you determine which RBAC Level to implement. If you are planning for a Level 2 – Hierarchical or higher, then you will also need to consider defining the role relationships or role inheritance model.

Inheritance allows for roles within the hierarchy to leverage the privileges of the lower roles. This can significantly reduce the number of roles you need to create. A typical hierarchy starts with three tiers of Roles:

– Tier 1: Permission Roles

These are the lowest tier of role that can be granted. Permission roles are typically defined and managed by the network file system, database or directory administrators. Examples include: Create, Delete, Modify, View Files, Data records or Directory Attributes.

– Tier 2: Technical or Application Roles

Technical Roles can inherit the existing lower tier Permission Roles. Technical roles are generally controlled by Application and or Directory Administrators based on how the application manages user or groups. The benefit of the inheritance is you directly assign a single Role to the user, but the user inherits multiple lower tier permissions.

– Tier 3: Organizational Roles

Organizational Roles inherit the lower tier roles and are directly assigned to the user. Organizational roles are typically defined by Operations and Management as the Job Title or Job Function.

NOTE: Most organizations will find that three tiers for inheritance are sufficient. While you can add as many tiers as you need, extra tiers tend to have an exponential affect on the number of roles and the relationships you must manage.

Role Definition Step 4: Define Role Administration processes

Once you have your roles and the role relationships defined, you can begin the process of determine the best administration process for you role catalogue. The administration process should indentify:

· Role Catalog Administrator

· Administrative process

o New role requests and approval process

o New role creation process

o Role Requests and approvals

o Security and Separation of Duty override approval process

o Auditing and Reporting process

For medium to large sized organizations, you may find the implementation of an Identity Management System (IDM) to be the best way to administer roles. Most IDM product vendors have also included RBAC in their product suite, which makes the overall system much more tightly integrated.

Enterprise-level RBAC provides a framework to manage access rights efficiently and enforces security/access policies across different user groups more effectively than previous administration models. Analyzing, developing and maintain your Role Based Access Control system may seem difficult at first, but the operational and cost benefits for those that are successful are significant. And those that administer their RBAC system with and Identity Management Framework enjoy the true benefits of process automation. With RBAC in place you are able to rapidly address changes in organizational structure and business processes while managing information security risks and access controls.