I’ve written in the past about the nicely crafted accountability model that exists within ITIL. (See http://www.itsmwatch.com/itil/article.php/3794216/The-IT-Accountability-Model.htm).   One of the most prevalent questions we get what person or area of the organization is best suited to play the role of process owner.  Unfortunately, the standard consultant answer, “It depends…” is the answer.  But the following guidelines might help to pinpoint be best person or place for these roles for some of the more commonly implemented processes:

Process

Incident Management: One could make a good argument that this role should be owned with the Service Desk function.    Whether or not it is the Service Desk Manager who assumes these responsibilities depends upon the size and nature of your service desk.  Service Desks that handle more than 200 calls per day, should consider this a dedicated role – particularly if this person is also responsible for oversight of a Major Incident process.  This person should be reviewing incident metrics, documentation, opportunities to turn data into knowledge, and implementation of continuous improvement metrics.  This person also has to rally staff that are outside of the Service Desk to participate within service level commitments, for issues that need to escalate to groups with deeper element-level skills.  This is one of the easier processes to find a process owner home for.

Problem Management: Problem management has two missions:  get to the root cause of the reactive issues (the incidents that have occurred) and proactively identify trends as a means of identifying problems.  Tougher to pinpoint a definitive owner here.   In larger organizations, we have seen the emergence of a service delivery function where this role may logically reside.  In smaller enterprises the oversight of this process may also reside in the Service Desk or within the realm of Event Management (monitoring – perhaps a NOC group), being mindful that it cannot conflict with the incident management goal of rapid restoration.   The individual responsible for Problem Management must be able to leverage resources from level 2 and 3 organizations outside of their direct functional responsibility to perform successful root cause resolution and to assist in the identification of trends.

Change (Configuration & Release) Management:Many think  of  Change Management as an operational function – likely due to its role in protecting the “production” services through prudent evaluation of risk versus benefit.  It is, however,  a governance role – a control point and oversight for two other tightly related processes: Service Asset & Configuration management (SACM) and Release & Deployment management.   Some large organizations have Enterprise Risk Management functions in place where  Change Management would find a logical home.  Small organizations may assign the ownership of all three processes to one individual as an approved Change drives asset and configuration repository updates and spawns the release of developed changes to production.  All three represent a collective of governance over the risk and quality of service delivery.   As with Incident and Problem management processes. Change, SACM, and Release & Deployment necessitate the oversight and cooperation of cross-functional teams within the IT organization – always a consideration in determining “where” a role should reside organizationally.

Bottom Line

The typical first approach to this in most organizations is to not “upset the apple cart”, but slotting these roles into existing organizational buckets.  This might be a good initial pass, but the cross-organizational nature of Process  requires a longer term strategy for success.  This may mean some restructuring within the organization that positions process owners with the empowerment necessary gain cooperation and compliance to process from stakeholders throughout the organization.  Considering a Service Delivery organization or a Governance organization  outside of the standard IT organization silos that is staffed by managers that have the seniority and expertise to drive cross-functional efforts may be a key to a lasting strategy for Service Management effectiveness.

Valerie Arraj
valerie@cppit.com

‘What’s Your First Team?’

 In Patrick Lencioni’s fable ‘The Five Dysfunctions of a Team’ this is the question the new CEO asks her team of direct reports. Her point is that her leadership team: first, has to be a team; and second, that the leadership team itself has to be their priority. Too often this is not the case, leaders are closer and more loyal to the functional groups for which they are responsible.

 In our last post we discussed the temptation to reorganize that afflicts many leadership teams. Such reorganizations are often not successful because they do not begin with an understanding of the purpose of the organization chart. The result is that the chart is reordered, but the organization and the way it goes about its work is not truly restructured.

 In his recent ‘Predictable Success’ Les McKeown states that the organizational chart is meant to be a tool for decision making. To be an effective machine for decision making, management roles must be clarified and the organization must be prepared to work cross-functionally. Each management level must see their peer management team as their first team. This must begin at the highest leadership level.

 Most organizations do not evolve in this way and this is particularly true for most IT shops. We can illustrate this:

 The above graphic is a whiteboard that lists the brainstorming responses to the question, “What tools do you use to track your work?” This question was posed to representatives from an IT organization of about 500 people. (Yes, these responses were all from within the same organization).

 This graphic leads to some questions:

• If there is no central repository to track (and measure) the work that is being done, how can management obtain an accurate and consistent understanding of what is happening in the organization? We mean the whole organization, not just the separate functional units.
•  If there is no such clear understanding, how can the leadership team be a leader’s first team?

Clearly, the lack of coordination at this basic level of tracking and monitoring work indicates an organization for which the leaders are closer to their functional teams.

 If this is not addressed, if the work is not restructured such that everyone is doing similar things in a consistent way,  no level of shuffling an organization chart is likely to lead to lasting improvement. The first task is to address the symptoms and that means understanding and structuring how the organization does its work at its most basic level. Only then can the organization chart be turned into an effective machine for decision making.

- Bill Cunningham
bill.cunningham@cppit.com

“…we have observed that our current system of (job) titles is inconsistent. Our reorganization… provides an opportunity to take a fresh look at titles …”
 

The above is a quote from an IT organization that is undergoing a major reorganization. This is at least the third such major restructuring that this IT shop has undergone in the past 5 years.

 The leadership team has worked on this for 5-6 months and they are now focused on getting the job titles correct on their new organizational chart. For half of a year the line workers and middle managers have been waiting for the details of the managerial reshuffle. What do you suppose this has done to morale and effectiveness?

 Reorganizing is a frequent activity for managers unsure of how to improve performance. Sometimes a reorganizing effort is necessary and useful, but more often it is an excuse to do something when faced with a crisis or other driver to improve. It offers the balm of activity and the hope of making things better.

 A reorganization can be exactly the right thing to do, but only if it is clearly understood what the reorganization is intended to accomplish and how the revised organizational chart will help.

 Otherwise an organization can fall into a sort of trap. When the first reshuffling does not work, then a second, and even third, reorganization is undertaken.

 In ‘The Fifth Discipline’ Peter Senge makes the point that many organizations frequently reorganize only to find that the underlying issues they were seeking to address resurface. This is because there is an underlying systemic structure that is not addressed by the new org chart. The old patterns of behavior re-assert themselves despite the new formal structure.

 Management is indeed difficult, but IT Leaders are fortunate. They have available a set of best-practices frameworks that provide guidance in addressing many of the deeper structural issues in their organizations.

 By adopting a Service Management best practices management framework, such as ITIL, IT leadership can begin addressing the structural issues that are likely prompting the idea to reorganize. A reorg may indeed follow, but at least it will be the result of providing true re-direction and restructuring.

 This is admittedly more difficult than spending five months meeting over lunch and working on a new organizational chart and consistent job titles. But it is much more likely to lead to lasting change, and to set the stage for consistent improvement.

- Bill Cunningham
bill.cunningham@cppit.com

Unequivocally, tools should not lead the process.  Gather your requirements, define your processes and then choose a tool that most closely aligns.  But when looking for a tool what are the top 5 things you should consider?

1. Choose the appropriate tool for the size, complexity and level of expertise within your organization. Smaller organizations will not require the tool scalability that is critical to larger organizations.  Simplier is better for organizations that don’t have the staff or skills to support customizations and migrate those customizations as software upgrades are adopted.  These enterprises may want to consider SaaS offerings.
2. Native capabilities or the ability to integrate with other tools to include the following process areas:
   • Incident Management*
   • Service Request Management*
   • Knowledge Management* (integration with off the shelf knowledge base products)
   • Problem Management
   • Change Management
   • Configuration Management (ability to integrate or federate to external repositories).
   • Service Level Management
   • Service Catalogue Management (ability to integrate)Workflow and escalation rules should be customizable for each process.
3. Integration with internal administrative systems (HR or LDAP) for authentication and list of supported contacts. CTI capabilities.  Network and system monitoring integration.
4. Reporting capabilities – native reporting should be parameter driven, but the best case scenario affords users the ability to create their own reports.
5. Visualization – dashboards, CMDB CI relationship visualization or service maps, visual process status.

The specific requirements of your organization should lead you to a tool whose architecture, complexity and supported  process areas or integration capabilities will meet your current and future needs.

*Self-Service capabilities are helpful here

I was semi-impressed yesterday when I visited a global retail chain, signed up for a new credit card and they handed me back the application form for me to destroy.  Retail stores that manage payment card information must abide by strict rules governed by PCI — the Payment Card Industry standard developed to protect card information.

The form that I filled out had Personal Information (PI) and not payment card information, so therefore would not fall under the PCI purview.

I asked the retail clerk processing my information what would happened if I left the form behind – in an attempt to better understand the security process.  The retail clerk told me that they place remaining forms in the bin behind her and that a disposition company destroys everything in the bin.  They receive a certificate from the said company once the data is destroyed for proof.

Good start.  The company could have taken this protection process a step further by having a more secure bin with a cover and a lock instead of using a standard looking waste paper basket.  Still, one giant leap for better InfoSec Data Protection.

201 CMR is here to stay, at least until H.R. 2221 gets passed

How is your company doing so far with meeting the Massachusetts regulation for the protection for PI?  If you are outside the Commonwealth and do not store Mass. residence PI, are you doing anything to protect your state’s residents PI?

jay.martin@cppit.com – ITIL, CISM, ISMAS – www.cppit.com

In a recent survey conducted by Global Knowledge in partnership with Tech Republic, the following are the top 5 certifications and corresponding average salaries:

PMP® – Project Management Professional $104,253
CCNA – Cisco Certified Network Associate $79,695
MCP – MS Certified Professional $74,438
MCSE – MS Certified Systems Engineer $86,454
ITIL® v3 Foundation $101,185

Global Knowledge reports, “Does the type of training one receives make a difference? Again, the answer is “yes”. After controlling for tenure, respondents who took only IT training had lower average salaries than their counterparts who did not take training in the prior year($74,025 vs. $80,130). However, if the respondent also took some form of project management or business-related training (including ITIL®) in addition to his or her IT training, that deficit reversed ($86,021 vs. $80,130).” To view the complete survey visit http://blogs.techrepublic.com.com/hiner/?p=3873&tag=nl.e101

We see this as a very positive sign that there is an increase in the value of process skills in the organization.  And for a second year in a row!!!  (See my 2009 blog entry at http://cppit.com/blog/2009/04/22/recent-study-says-economic-counter-trend-in-demand-for-it-process-and-architecture-skills/ )

Still good to be a geek; even better to be a process-oriented geek .

Let’s face it.  The configuration management database is really the Holy Grail of IT Service Management.  Business services  are defined  that support one or more business processes.  These business services  connect to various software and hardware elements (or infrastructure services) that represent connectivity, processing and storage capabilities used to support the business service.  Ideally through an extension of the CMDB referred to as the Coniguration Management System (CMS)  you might also connect supplier contracts (underpinning contracts), OLA’s, and SLA’s.  Additionally you would include links to incidents, problems and changes.  The end goal would be to have optimal visibility to see what services you are supporting along with all of the past, present and future activity regarding these services.  It is the IT data warehouse that transforms data from multiple IT management operational data store so that key IT management decisions can be made.

The vision for a CMDB/CMS strategy is spot on as a critical underpinning for holistic service management.  The execution piece is very tricky.  And, in the case of the CMDB, this is a consummate example of the importance of ITIL’s  guidance on breaking vision down into manageable, achievable interim goals.

For organizations that have substantial infrastructure and have no current tracking mechanism, be realistic about the results you hope to achieve.  Auto discovery tools can be helpful but are also very complex and require you to access all points in the network to give you comprehensive results.   A structured, slow but reliable approach to getting your arms around the relationship models is to target a handful of services to begin with and do one service at a time. Once each service is validated in the CMDB assuring that you are managing it under your change management process is key.

Identifying business critical services and prioritizing them within this strategy will allow you gain better control and visibility to the areas that are most important to your enterprise as the first phase of this process.  Once you’ve got these critical services captured, you can tackle others.  In a large organization, this discover & control method will be a multi-year process, but the approach makes the CMDB promise achievable.

I mentioned in my blog in late November that the cost to Health Net over loss of an unencrypted hard drive containing 450,000 patient records (revised down from 1.5m) would be much greater than the cost of securely controlling and protecting their information assets. Health Net will begin the process of emptying their wallets in an effort to build a defense against the lawsuit levied against them by Attorney General Richard Blumenthal.

The breach occurred in May of 2009 and was not reported until November. As discussed, Connecticut’s breach notification law are fairly strict and I would assume holding off reporting such an incident for 5+ months is over the top which could cause Blumenthal to make Health Net an example for all to see. To add fuel to the fire, the American Recovery and Reinvestment Act of 2009 (also known as the HITECH act) also imposes notification mandates that were apparently neglected. See my November blog post under security entitled “Health Net Breach — A Failure of People, Process & Technology” for more details.

jay.martin@cppit.com

CISM, ISMAS

www.cppit.com

The national Data Accountability and Trust Act, H.R. 2221 passed within the House of Representatives earlier this month (Dec. 8th, 2009).  The Bill — as with 201 CMR 17.00, the Massachusetts Protection for Personal Information — seeks to protect consumer personal information and requires notification to individuals in the event of a breach, albeit from a national level.  The bill is set to go before the Senate next and then the President.

H.R. 2221 would require “for profit” organizations to develop the necessary security policies and safeguards to protect U.S. Residence personal information within 1 year of passing.

More to come later…

jay.martin@cppit.com

CISM, ISMAS

www.cppit.com

The recent Health Net data breach of 1.5 million patient records due to a lost hard drive included unencrypted personal information such as names/addresses, medical records, Social Security numbers and other financial information.  A breach of this magnitude is shocking and what is more astounding is that the breach apparently occurred in May 2009 and was not reported to the Connecticut Attorney General’s office until this month (November, 2009).  The breach may be a gross negligence of HIPAA, FTC “Red Flag” Regulations, Connecticut’s Public Act 08-167, CGS 36a-701(b) and other state regulations/breach laws.  

I am sure that Health Net, like most companies, felt they developed the necessary controls to meet such regulations.  But a breakdown of this magnitude proves a failure of the company to institute “strong enough” information security policies, employee awareness programs and technology across the company to protect against this major corporate risk.   That is why we have been advising our clients to develop a risk-based information protection plan that estimates their potential loss against the cost of securely controlling and protecting their information assets.  The monetary penalties and consequences to Health Net for this breach will far outweigh the “should-have” preventative costs of deploying the right controls for this threat.  If the lost hard drive were encrypted, I wouldn’t even be writing this blog.

In his statement, Attorney General Richard Blumenthal stated that “I will vigorously and aggressively seek damages, penalties and other appropriate remedies, if warranted.”

This is not an option:  *Information security programs that include people, process, technology and partners must be vigorously managed and improved upon over time.*     Comments are welcome.

jay.martin@cppit.com

www.cppit.com