Project Management Never Takes a Holiday

As we get into the holidays, this is the perfect time to take stock of your current projects and make your resolutions for next year. Things get a little bit quieter, and that creates a fantastic atmosphere for catching up on all of those things that you should be doing all the time... but just don't quite get to. "Project management" covers a wide swath of activities- but they all come back to one constant theme: control. Without clear knowledge of the progress along each of the lanes of your project, you will quickly lose control. Even the most experienced project and program managers can lose control.

Unfortunately, it doesn't take long for a project to spin out of control without proper measures in place. First, you have to look at your project scope. Is it a many-tentacled monster with smaller sub-projects sprouting out of everywhere? Is it growing rapidly (and by rapidly, I mean by 25% or more over 6 months)? Is it complex? Does it have built-in reporting requirements? if the answer to any of these questions are yes, you need project control in the form of tracking mechanisms and documentation.

Your first response is likely that you know what is going on and you certainly don't need to bury yourself in paperwork that gets completed and then stashed in a drawer, never to be used. I like to call that stuff "shelfware." That's why you have to design your methods of control to fit into what you're doing- specifically to your project and to the way you work, the way your team shares information- both internally and with your stakeholders. There are lots of great ideas, and you can force yourself to get the templates built and the information flowing by scheduling a meeting with your major stakeholders on a regular basis, with a structured format. That structured format will get them used to what you need them to know. Look back over the last 90 days and see where your "fire drills" were. If they were cleared up with a bit of explanation and additional communication- learn from those experiences and put that information out on a regular basis, in a format that the people who need it can relate.

Now that you've done that, it's time to tackle the big beast. Here's how you do it:

• Break your project into "lanes"
• Assign each of those lanes personnel who have those day-to-day responsibilities
• Put in writing (to share with your team and stakeholders) the SCOPE of each of those lanes
• Break up all of your tasks into those major lanes
• Write task charters to lay out what's in scope for that part of the project
• Create a project milestones chart (I like to use a plain-old Gannt chart because it doubles as a calendar of when things are due and where your dependencies are)
• Post your chart where people can see it and follow along

Make sure that if you were to be kidnapped by aliens tomorrow, that the people you work with would know exactly what was going on across your entire project- what people were doing, what those activities are in support of, and WHY.

If nothing else, it will make your life a little easier as the project manager, and the regular investment of time in "housekeeping" sorts of activities like this will afford you control over your project, real oversight, and maybe even some extra time to celebrate holidays... you know, while you're not working.

Statistics are Sexy

In an era of almost unlimited data availability managers are inundated with information of all types from multiple sources. In this environment, the manager must be able to filter out the relevant from the noise, and must also identify the data that can be transformed into something useful. Once you're left with a narrowed down pile of data, you can turn that into information that your team, your stakeholders, and your leadership can use to facilitate informed decision making.

Wait! That's not the end! Information is only truly useful to those people if it is communicated effectively. "Effectively" means that:

• It supports a well-defined purpose or decision-making objective; and
• It's in the right format for the message and the audience, and
• It provides clarity, rather than just more volume.

This is where the statistician on our team comes in. Statistics provides the means to analyze and extract real value from your pile of collected data. They can be descriptive- explaining the current reality in clear, concise terms; they can also be predictive- extrapolating trends to aid in decision making. Unlike other types of information, reliable statistical data when combined with a well-thought-out case for change is difficult to refute. A well-crafted, data-based argument is incredibly effective when trying to gain consensus among stakeholders on the way ahead.

Hal Varian, the Chief Economist for Google, was interviewed about the affect technology has on innovation. In that interview, he talks about how Statistician is the "sexy" job of this decade, as Computer Engineer was the sexy "it" job of the 90s during the tech boom. Keeping a skilled statistician within arm's reach can help you focus conversations and enhance your team's decision making activities by providing support for your business case for change. In a world where data and data sources are growing exponentially, a statistician can extract the value from that data and transform it into the representation needed to support your decision making processes. The statistician can inform and empower your stakeholders. Statistics aren't just critical to determining your path, but are also the key to explaining those choices to others.

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.

Best of the Blog: Decision Making Traps

In reviewing the most recent Google Analytics info on this blog, I've been struck by the response to our posts on HBR's classic article on decision-making traps, which appeared some time ago. Based on the popular demand, I have posted below the links to each of the entries.

Part I: The Anchoring Trap

Part II: The Status Quo Trap

Part III: The Sunk Cost Trap (my personal favorite)

Part IV: The Confirming Evidence Trap

Part V: The Framing Trap

Part VI: The Estimating and Forecasting Trap

We're glad so many enjoyed these posts.

Role-Based Access Control – Where to Begin - Part II

In Part I of this series we discussed the benefits of implementing Role-Based Access Control. In order to realize these benefits, we need to understand what applications their employees use to be productive in their jobs.

Question: How does someone go about developing a coherent and consistent definition of Roles across the information systems?

Answer: Application Portfolio Management (APM) and Application Rationalization

Application rationalization can help address the following:

• Identify users that do not need access to the application
• Establish a baseline for each position and how they use the information in applications
• Identifies types of access required for each job/position
• Prioritizes applications and identifies best candidates for RBAC implementation

Application Rationalization Step 1 - Eliminate the obvious

A good starting point to cleaning up this mess is to reach out to the application owners for the most sensitive/risky applications and show them the departmental positions that use the application and ask if those positions have the appropriate access. The application owners provide the first cut, eliminating those users in positions (and departments) who should never have access to the application.

Application Rationalization Step 2 -Identify the real needs

The next step is to go to the business managers in each respective department and get their approval as to which information and applications are required for each position.

• Remove user from applications they no longer need access to or use.
• Align information access with job responsibility/position.
• Prioritize applications that will benefit the most from RBAC automation

At the end of this exercise, you will have cleaned up the application environment – having both removed departments and users who are in job functions that should never have access, and having eliminated users who should no longer have access based on their current job responsibilities.

Application Rationalization Step 3 - Final Step

• Obtain buy-in from stake holders: Managers, Application owners and users.

Now all people in the same position will have access to the same applications. Determining the access each position requires makes it much easier to define roles and determine what applications a person should have access to and at what level. And that will be the focus of Part III of our RBAC series.

Coming soon: Role Based Access Control – Building your Role Library - Part III