Big Sky Thinking

Most companies struggle on some level with decision-making. Let’s face it; keeping a large company working in a coordinated manner is no simple task. In the case of IT, this problem tends to be exacerbated by the fact that there is a lack of common language between groups. The business speaks in terms of finance and marketing, while IT talks about projects in terms of features and technical feasibility. The result is a lack of alignment, which hurts both groups. The solution to this dilemma is governance. The goal of governance is to fix broken processes and bring focus back to the strategic priorities of the business. In this entry, I suggest that we can look at governance through three lenses: control, communication, and change.

Effective governance exerts control either through formal authority or influence, depending on the degree of (management) centralization and the authority granted by executive leadership. In either case, the governance board works to establish standards and policies for the organization to guide development efforts. In addition, establishing a project approval process is essential to managing priorities and keeping IT departments focused on key initiatives instead of working in reactive mode to respond to the request of the day. The goal here is to balance the needs of the business with technical requirements to develop solutions that deliver business value and are secure and efficient to maintain.

The benefits we hope to achieve through control begin with communication. Project selection, policies, and standards should all be established through conversations between the business and IT within the context of strategic objectives and desired outcomes. These decision points hinge on a common understanding of the value delivered, the risks mitigated, and the cost to implement. Alignment between the business and IT is essential to set the right policies and to ensure that organizational compliance is high. Furthermore, a formal project selection process allows the IT and the business to set priorities together, stop projects that aren’t delivering value, and redeploy resources where they are most needed.

The last dimension of governance is change; how do we remove political obstacles and also get users to adopt the solution? Governance offers the opportunity to establish a structured, organized change management process to get us from our current state to a desired future state. Politics represent one barrier that can be challenging to overcome. It is the role of business stakeholders on the governance council to help IT overcome political barriers by identifying and addressing issues early on. User resistance to change is another matter entirely. Resistance to change is rooted in a desire to avoid disruption to the user’s established routine and to stay with the systems they know well. The best way to counteract this resistance is to improve communication and involve end users early in the development cycle. The project lifecycle should take care to generate user buy-in by asking for feedback, evaluating and incorporating changes from the user population, and supporting the transition to the new system.

Another look at the three C’s of Governance:

Control
· Formalize project selection/prioritization
· Employ IT portfolio management
· Establish standards
· Define policies
· Balance formal authority against influence
· Deliver consistent solutions

Communication
· Communicate business value – How will we benefit from this project?
· Gather business requirements – Does the solution meet our needs?
· Create transparency and better understanding of IT activities and performance
· Improve understanding of objectives and expectations
· Improve visibility of project issues and priorities
· Change perception of IT as a ‘cost center’ to strategic partner

Change
· Involve users earlier in the development cycle
· Capture enhancement requests
· Improve solution adoption
· Establish communication plan
· Identify and plan for objections/resistance to change
· Overcome organizational politics
· Provide end-user training

Labels: change management, governance, IT, policies, standards

In one of our earlier entries, "Identity Management: Observations from the Trenches", we discussed some of the pitfalls of rushing to implement an Identity Management solution without looking at data quality, data requirements, and starting with a point solution instead of an enterprise approach. I wanted to add to that discussion and emphasize the importance of knowing your processes before you implement identity management projects.

Many times a project can seem straightforward both technically and organizationally, but often there is something you don’t know that will send it to the scrap heap. Let’s look at the following example: a company wants to improve the time to provision new hires into their non-connected systems by sending an automated email as soon as the user’s identity is created in the directory. Based on the way the process runs today, the client believes they can save two weeks in new hire provisioning, and they are eager to cash in on this golden opportunity. Fair enough.

At this point, the development team is ready to start building something immediately. The core infrastructure is already in place, we just need to slap in some workflow with emails and we are golden, right? Not so fast. It turns out upon further evaluation, that the organization did not clearly understand their onboarding processes. The assumed bottleneck, that staff were not receiving notifications of a new hire promptly, was not really the problem. Instead, the delay in the process was caused by the manual assignment of the user’s id by another department. This id was required for all provisioning activities, including creation of the user’s identity in the IdM system, which means that system-generated emails buy us nothing; they simply automate a part of the process that is already working fine.

So what are our lessons learned?

a)Bring key stakeholders (business owners, corporate staff, etc.) into the early planning meetings and touch base with them regularly

b) Start by mapping out your processes from recruiting through creation of the user identity in the directory (work with your stakeholders to complete this analysis)

c) Identify key data that are needed (user id, etc.) to support the project, where the data reside, and when they become available along the process

d) Validate your process maps with your stakeholders. Step everyone through the process and discuss:

a. the process steps (Are they correct? In the right sequence?)

b. process timing (How long does each step take?)

c. data flow (What data are available when?)

d. process bottlenecks (What are the slow points in the process? Rank them in terms of time consumed.)

e. process dependencies, and identify any process changes that will be required (Can we get people into the ERP system sooner? Can key data fields be entered earlier? Do we need to change the way approvals occur in the process?)

Labels: business process, directory, edirectory, governance, Identity Management, provisioning