Posted on

Definitive Process Library? Huh?

This morning one of North America’s leaders in IT best practice consulting, PLEXENT, surprised me with a headline: IT Improvement: What is a Definitive Process Library (DPL)?

Besides a marketing term they made up, it made me wonder, what exactly is a Definitive Process Library?

My conclusion after research: it is a marketing term they made up.

ITIL does not define a DPL. ITIL does define a Definitive Media Library (DML) in Service Transition (Release and Deployment Management):

One or more locations in which the definitive and authorized versions of all software CIs are securely stored. The DML may also contain associated CIs such as licenses and documentation. It is a single logical storage area even if there are multiple locations. The DML is controlled by Service Asset and Configuration Management and is recorded in the Configuration Management System (CMS).

Replace “software” with “processes” and you almost have a definition of DPL, if you would choose to do so (for reasons other than marketing and self-promotion). But why would you?

An organization oriented around services supported by processes would be deeply affected by at all levels, including:

  • The organizational chart
  • Roles and responsibilities
  • Approval matrices
  • Authorization rights
  • Communication plans
  • Key Performance Indicators and reporting metrics
  • Human capital management
  • Automation tools

To name just a few. ITIL provides a conceptual framework dealing with these challenges, including the CMDB, the CMS, and the SKMS.

For services ITIL has added the Service Portfolio and the Service Catalog, concepts which for knowledge management purposes could be dealt with through the broader framework of Knowledge Management.

For processes, they are stored in the CMDB and managed through Change Management. No other consideration is required, besides how you publish, communicate and manage the downstream impacts (some of which are mentioned above).

In practice I have not observed any outstanding or notable best practices. I have seen them stored and published on a file share, on SharePoint, on the Intranet in a CMDB, and as email attachments. Have you seen best practices that uniquely stand out? If so let me know, I would love to hear it.

Posted on

Ditching the Resume

I want to be the ITSM guru who never needs to write another resume. Ever.

I am not there yet, I admit, but it is my professional goal. Not to be rich. Not to pass the Service Strategy exam. Not even to understand what really makes up that nebulous ITIL V3 CMS.

You may wonder if it is because I hate HR types. Maybe, but I think I don’t really hate HR types. Actually I think HR is the most undervalued job in corporate America. HR has the largest impact on organizational performance, yet it is often an administrative job that collects time sheets and writes and distributes the formal HR manual that nobody reads.

I have a friend who I would trust implicitly for any ITSM engagement. He has it all. The certification. The theory. The practical experience. The communication skills. Practical tool knowledge. He plays a musical instrument. I know he is looking and I hope I can be the one to find him something.

I want to be known the way I know him. I won’t need a resume.

The resume is an anachronism. It is a two-page summary of a person’s professional life that warrants 10 seconds of a hiring manager’s life, in order to ascertain whether the applicant can spell correctly or pay for a professional resume preparation service.

This is the pinnacle of our knowledge-worker economy? If so we are all doomed.

I heard somewhere that eighty percent of Americans lie on their resume. Maybe it was sixty percent. It doesn’t matter.

Knowledge workers need to move beyond this. The resume is a standard tool to describe commoditized products.

If your professional career has to be confined to a static resume, then you are competing with 100,000 other commodities around the world. You are a commodity, like pork bellies or light-sweet crude that costs less than bottled water.

I started this the other day. It isn’t finished yet, but I am calling it my Visual Resume. Publicly I am posting only a low-res portion of it. Email me and I will send you the fuller version of it.

http://about.me/gregorytucker

Posted on

Four Day Workweek

I found this CNET article interesting. The benefits of a four-by-ten workweek include lower energy costs, higher retention, higher morale, and higher productivity. It might also improve commute times.

A past study showed changing the lighting improved productivity, albeit temporarily. Reverting it back had the same affect. Productivity improves temporarily because employees feel management cares about their concerns. The affects of the four-by-ten workweek may be termporary as well.

I see resistance from managers who would say “we are already getting ten hours per day out of the employees, so wouldn’t this simply cut off 20% of our productivity?” This one is harder to address, except that productivity drops with number of hours worked. Productivity is hard to measure, but number of hours worked is easy, so managers often opt for the latter as a proxy of productivity. Most execs would continue to work five or six (or seven) days per week anyway.

From an IT perspective, I see this having a positive affect on Change Management and Release Management–longer change windows on the weekend for changes, upgrades, and rollouts. We might expect higher success rates, but to my knowledge this has never been studied.