Why resist process?

We’re admittedly process consultants, and have a bias towards supporting process.  That said, we see a number of instances where process is resisted.  Why?

One client asked for a gap analysis of their processes to industry standard process.  We started down the path of a binary (yes, you have the process….or no, there is a gap.)  As we got further into the engagement, we were struck by the naiveté of this approach.  While technically NONE of the processes were documented, the truth is the organization was following a process.  So a binary wouldn’t fairly evaluate status.

A colleague suggested a shift to something more of a Capability Maturity Model Integration (CMMI) approach.  In this approach, we evaluated the Maturity of the processes.  Using this approach, we were quickly able to evaluate a series of processes and their current and intended maturity. 

What we discovered was a series of processes suitable for the existing business, largely operating on the “tribal knowledge” of a series of long term employees.  Adding staff was a challenge, as this knowledge needed to percolate to anyone new to the group.  This often took time, a rare commodity in this growing organization.

That said, the only way for them to grow and leverage their processes was to document them, in simple, clear language, so others could be brought to bear.

Sometimes it seems process is equated to bureaucracy or a way of doing things in the least efficient manner.  The US Tax Code comes to mind as the working example.  Well-designed process does not need to be bureaucratic…if anything, it should be enabling.

Another client was working on the handoffs between various parts of the organization.  In (lightly) documenting the process, some “sticking points” were apparent.  We challenged the process owner to address those sticking points.  “Oh, I am concerned about rocking the boat.”

Our view is simple.  Improving process can be incremental or disruptive.  Either approach has merit and application.  If you’re not improving the business process…then you are not making a difference.

“Process” is not a four letter word.  Process is important in achieving consistent, repeatable results. 

Some organizations are successful delivering business process outsourcing (BPO).  How have they done this?  They’ve passionately tackled certain processes and optimized every step.  Certain functions lend themselves nicely to business process outsourcing (payroll as an example.)  It’s our belief non-core business functions should be considered as candidates for BPO.

Core functions should be where businesses focus their attention on optimizing process.

Why do some people "get" process? (Hint - it's about the customer)

Over the past two weeks, I’ve compared notes with two friends over process.  In this context, “compared notes” equals commiserate over situations in organizations where getting the group to follow process is a challenge.

What struck me was how three different people could have such similar views, literally to the point of being able to finish each other’s sentences on the topic.  How did that happen?

So I started to do a check off list….

•  Age – the three of us are all around the same age.  Let’s just say I have the grey hairs to show for it.
• Sex – two females, one male.  Doubtful.
• Similar upbringing – One from Oregon, one from New Hampshire, and one from Ohio.  Hmm.  West coast, east coast, and north coast.  You couldn’t get much more diverse and stay in the United States.
• Collegiate schooling – Oregon, Massachusetts, Ohio.
• Worked for same company – nope.

I was lamenting a lack of insight when one offered, “It’s about values.  We share a value for the customer.”

We share a value for the customer.

A value provides the basis for action. Over my career, I’ve found having a value for the customer is often a good starting point for a decision.  It can’t be a “the customer is always right” blind faith decision…as sometimes the customer is trying to get something they are not paying for.

In a recent meeting an SVP for a large (IT) company said he looked for people with two characteristics:

• team player
• customer focus.

There’s that pesky customer again.

A large financial services firm espouses a simple value framework for decision making….in order

• Client
• Firm
• Self

In this context, client is customer.  This simple rubric provides clarity for the quality of the organization.

So how does process get wrapped into a value around the customer?  It’s about having predictable results. Customers value predictable results.  And in my experience, internal staff (not to be confused with an internal customers) prefer predictable results.

What often happens is someone in the heat of the moment thinks they know best, and shortcuts the process.  Over time, this leads to anarchy and a loss of predictability.

And for all you saying you don’t like process, please note I abhor “bad” process, and bureaucratic process.  Process, when designed and well executed, is a facilitating and not debilitating tool.

You Can’t Manage What You Can’t Measure

Harvard Partners’ Business Continuity and Disaster Recovery Practice Lead, John Manning, always says, “You can’t manage what you can’t measure.” John uses this to help clients assess risk and prioritize business continuity and disaster recovery initiatives. We recognize the same holds true across Information Technology (IT).

IT is a discipline focused on understanding user needs, delivering solutions, and creating business outcomes. IT should be measurable, well-organized, and predictable. Every decision, be it a simple one or one made during a crisis, is based on either reducing business risk or increasing business value. Decisions and recommendations should be fact-based.

An IT Assessment is a fact-based, holistic tool for measuring expectations and perceptions of IT relative to capabilities, resources, vulnerabilities, and internal IT priorities.

Qualitative and quantitative inputs help identify areas of achievement and those needing improvement. Dashboards provide metrics giving IT the means to identify and prioritize areas for remediation.

Narratives resulting from an IT Assessment are typically driven from business input or industry best practice and help to identify areas where user perception is different than IT reality. Many times, improvements in communication (a weakness for most IT organizations) create positive attitudes towards IT and technology.

While the outcome of an IT Assessment aids in decision making, the process of performing an IT Assessment should be collaboration between users, IT staff, and those performing the assessment. Every response and metric has a story and those stories contain the clues to uncovering the underlying cause of many issues.

IT Assessments should be used to fix root cause issues rather than provide temporary fixes for symptoms.

In a recent IT Assessment Harvard Partners performed for a $200M company, many areas for improvement were identified along with dozens of vulnerabilities (none critical). A prioritized list (by category) of improvements was proposed with estimated effort and benefits. Using the results, IT managers identified and prioritized specific initiatives designed to improve IT and the impression people have of IT.

This organization is now well down the path to improvement, with the business realizing immediate and substantial gains.

The Value of Consistent Format

“Here’s the Format Manual,” was intoned during orientation for one company. Without even looking up, a small pamphlet was envisioned. Instead, a 1” thick three ring binder was presented.

In it was every conceivable form of communication along with the specified format. Yes, two column for a memo, in the company’s unique (yes, unique) font, including the flow of the overall document. It felt very restrictive; leaving me wondering what led a partnership to commission a “Format Manual.”

I now “get it.” Here’s why.

My business is helping companies develop IT Strategy. We often take complex subjects and present them in a compelling manner. This has led us to develop a library of hundreds upon hundreds of PowerPoint slides, all stored on SharePoint for staff to access.

This intellectual property library allows us to quickly respond to client needs….pulling together non-client specific data quickly and professionally.

For this to be effective, the slides must all have the same look and feel…otherwise we can’t build presentations from existing materials.

Recently, a presentation was developed where a lot of time was spent on modifying the format…limiting the value of those materials.

All our presentations have black letters on white backgrounds. This one has white letters on a black background. Personally, making notes on a black background slide is nearly impossible.

The fonts were changed, introducing a new font, and in some cases shading. As before, these slides don’t “look” like ours, and certainly can’t be reused.

We use stock photos in most of our presentations…for a professional look. This author had to use black and white cartoon figures….and hand drawn figures. It just doesn’t hold together for me. In fact, it cheapens the look.

My sense is authors should spend time on developing concepts and presenting compelling ideas as a prime focus, not on changing format.

As I thought about this blog entry, I was drawn to an example of where format is varied and it works. Google’s Doodles come to mind. They are compelling.

That said, they are temporary, they are clever, they don’t impact function….

I respect that IBM’s used Helvetica forever. Every IBM document is the same.

When was the last time the New York Times used a different font than…say….Cheltenham. Every 100 years or so. Heck, even when they went digital they scanned the old image.

So…let’s give it a decade before we change formats. Until then, let’s focus on content.

Inventory Management in Data Centers

We are seeing a large number of companies re-engaging in data center construction activities after the Great Recession of 2008-2010. After putting large expenditures on hold, companies are finding data center environmental constraints (power, cooling, and white space) are requiring infrastructure upgrades and/or relocations.

We are finding many companies would benefit from inventory management disciplines typically found in retail or manufacturing environments.

Many IT organizations have “lost control” of their inventories because of parochial approaches in departments managing the underlying information. In other words, they are suffering from an overwhelming amount of data!

In a retail or warehousing environment, every item (or Stock Keeping Unit (SKU)) is tracked closely in a master catalog, with annual physical inventory and/or cycle counting approaches used to maintain a key understanding. There is often one number universally used through the organization (sales, distribution, warehousing, manufacturing, design, sales administration, etc.). Each department can then use their own systems for understanding products. These approaches are well understood in the arguably more mature retail/warehousing environments.

Information Technology departments often suffer from a hubris preventing a shared perspective. Each department uses their own view…often with overlap, and not uniformity. Each department manages “their data”, often creating different indexing inhibiting sharing for the total organization’s good.

For example, an IT organization may use the following “keys” for storing their data:

Department	Key	Issue
Data Center	Server Name	Process breaks down if server upgrades use same name
Networking	IP Address	Does not uniquely identify a machine.
Server team	MAC Address	Not externally identifiable

Obviously this is a contrived example. In the real world, organizations use a combination of identifiers to uniquely track an environment. Unfortunately, these schemes often break down and, are not maintained, and often struggle to reflect a virtualized environment.

That said, how can we leverage this parochial view for a breakthrough in understanding.

What’s a company to do?

Many companies start down the path of an iron-clad asset management initiative. Often a czar of asset management is appointed, and new processes are introduced. Some companies even go so far as to place RFID tags on servers. As a place to start, Asset Management will make a marked improvement.

The real answer may be more subtle.

A configuration management data base (CMDB) is a repository of information related to all the components of an environment. The CMDB is a fundamental component of the IT Infrastructure Library (ITIL) framework’s Configuration Management process.

One could argue CMDB is a fancy way of doing asset management. The key difference is CMDB repositories frequently involve federation, the inclusion of data into the CMDB from other sources, such as Asset Management, so the definitive source of the selected data retains accountability for the data.

In the retail/warehousing environment, the individual areas are responsible for their data and have “figured out a way” to share (federate) the data so the organization has a single shared view.

Our recommendation to companies beginning any data center process is spend the time “up front” understanding their data, and rationalizing into a system transcending the data center construction effort. Since a data center effort requires a solid inventory, enter into the discovery effort with an eye towards all the data needed…not to derail the migration effort, but to accelerate it during the move and beyond.

As a side benefit? You will find servers that can be repurposed or decommissioned…better leveraging the strategic IT investment with savings in complexity, license and maintenance costs, repairs, etc.

The Value of Frameworks

There are two sides to me. There’s the go-to-work-every-day-and-pay-bills guy, and there’s someone longing to be in New Hampshire, where the state motto, “Live Free or Die,” is appealing.

The same is true of frameworks.

I want to be able to do things my way and “slam” things to production. Yet I recognize such anarchy (applied to everyone) will inevitably lead to a very shaky production environment. And when I hear of organizations where it takes longer migrating items to production than to do the development and testing, I want to pull my hair out.

A neatly dressed cable plant is a thing of beauty, readily maintainable:

And left to their own devices, sometimes you’ll end up with this:

So where is the dichotomy?

The issue is frameworks, such as Systems Development Lifecycles (SDLC) or IT Infrastructure Library (ITIL), applied indiscriminately, can cripple an organization.

My belief is you have to understand the framework, and then selectively extract those items appropriate for your organization (or an organization of your size.)

For example, ITIL describes a program change management process. Should a two person firm implement the exact same process as a 1200 person development organization? I would submit “no.”

Do I believe changes should be documented, understood, tested, released and verified regardless of the organization’s size? Of course. In the two person firm, a change management meeting can be accomplished over coffee…where a larger firm will need commensurately larger process.

The underlying tenants and directions are always the same…it’s the degree organizations implement items that varies.

As IT consultants, we see many organizations where the nuances of implementing processes are lost. And since processes are living things, they need occasional maintenance.

It’s rare we see an organization truly devoid of process (although undocumented processes, or “local practices,” are more common than one might expect.) We find helping organizations dial in the right degree of process key in “rightsizing” the process to the organization so they receive the benefits without being bogged down in a bureaucratic nightmare is a true value add.

When changing process, it’s important to analyze proposed changes and make sure the root cause is being addressed. We recently got a call from a client concerned their recently enhanced problem/incident process was failing. Quickly, we determined a process “role” went unfulfilled on a single incident. This does not mean the process is bad; to the contrary the process was right and all roles need to be filled.

By rightsizing process, and regularly evaluating effectiveness and appropriateness, we believe organizations can operate with high performance.

Thoughtful Transition Management..the neglected art.

I find it thoroughly amazing many technology organizations still seem to forget or neglect the the most fundamental aspects of transitioning technology products into the hands of their customers.  I’m not referring to the technology bits and bytes about how to move code into production or fire up a new storage device, I’m talking about the act of thoroughly setting user expectations, delivering just the right about information to them and lastly, preparing the support staff to provide great service.

Often, there is a HUGE gap in a firm between the highly intelligent technologists (application coders, database admins, telephone/voicemail engineers) and the end users.  The result is often a good product poorly received—or significantly less well received than it could have been if someone had just taken the time to think through all aspects of delivering it into the hands of a user.  I think this typically happens when senior management’s concern has shifted too far toward technology or cost cutting and away from the business humans at the other end of the keyboard.

The best organizations bridge this gap by involving their support staff in the delivery of new technology.  They don’t just tell them about what is happening (some don’t even do that), they educate them on both the business opportunity and solution.  When techies and their management truly consider their customers they know it makes sense to empower support staff with knowledge and tools allowing them to provide great service.  They recognize support groups often know the customers better than anyone and leverage that relationship to communicate salient points about what is coming down the road.  Whenever possible, they employ support staff to develop and deliver training materials and execute desk-side transition steps when they are necessary.  How better to prepare and educate a helpdesk for a new product than to involve them in the deployment and training?  For organizations with a high rate of technology churn, constant application changes or high touch, business-urgent users this delivery process is best managed by a dedicated person or team focusing on consistency and congruity of each transition step across projects.

I get it that ITIL processes cover this topic but only to a degree.  I believe there is a certain common sense and empathy that no framework can meaningfully outline.  Technology organizations do well when they thoughtfully consider exactly what the end user will experience with technology change and engage the support organizations early in the project.  This attention to detail fundamentally matters and is absolutely a service differentiator.  For me, doing this is a “Duh.”

This post was prepared by Charles Kling, Associate Partner at Harvard Partners.

He can be reached at charles.kling@harvardpartners.com

Tradeoffs – Lessons for IT from the Gulf Disaster

Seeing a “Gulf Disaster – Tracking the Numbers” chart on CNN.COM this morning made me ill:

CNN.COM June 29, 2010, 9:00AM EST

As an engineer by training, and a lifelong technologist, I know there’s no good reason for the shortcuts taken by my fellow engineers on at BP.

And while the company is working feverishly to clean up their image, the Gulf area will take decades at minimum to recover:

BP Website

Think about systems in the rest of the world. In the following picture in a hospital ER room, there are

Picture by Author

a wide variety of systems working together in harmony and safely. There’s power, oxygen, vacuum, heart monitor, eye/ear devices, and the ubiquitous television (the TV is out of the picture, and the control is not.) And then there are mechanical systems (gurney, HVAC, structural, lighting, etc.) This picture was taken with a RIM BlackBerry, and sent to my hosted Microsoft Exchange email over the AT&T network.

By having solid designs and safeguards, these tools make the medical profession more effective and save lives.

When it comes to energy, we shouldn’t have to decide between oil or the environment. Engineers know how to do things safely. When shortcuts are taken (as is now being suggested in the Gulf), inevitably “bad” things happen.

Engineers are not infallible. Mistakes, or out of bound conditions do happen even to the best with disastrous results:

tokyo5.wordpress.com/2009/07/

As systems types, we are often “under the gun” to deliver things quickly. And with some planning, “just in time” philosophies, and some smarts, we can deliver!

When you are asked to make a professional compromise….consider alternatives to mitigate risks and achieve the objectives. And remember what can happen when risks are not mitigated.

Big Bang Doesn’t Work

“We have no choice. We have to do a hot cut Friday night. It’ll be tough, but we’ll have the weekend to clean up. We’ll be fine on Monday.”

Ever hear words to this effect? I have. Multiple times. And I’ve always regretted not pushing back when I hear them! Whenever I’ve been lulled into the wisdom of the “big bang”, minor issues are amplified due to the scope.

Whether bravado, fact or simply be worn down, the charge to victory was compelling. While nobody likes hearing “Big Bang,” words like “simpler, cleaner, quicker, less risky, technically required” get tossed around like a football on a fall weekend.

My contention is people lull themselves into a sense of “Big Bang” being the only way to do a deployment. The ugly truth is with the exception perhaps of the Year 2000 a decade ago, most times a “big bang” isn’t needed. In fact, NOT doing “big bang” often requires more planning and creativity and yields a more satisfactory cutover.

For example, when deploying a new phone system, why not do a group or floor at a time? And can’t the old phones be kept in place for a week or so (if only for outgoing calls?)

When deploying a trading system, perhaps start with one commodity type.

Moving a data center? Bring up the network to the other center, and move servers/applications/data a little at a time.

Yes, you may have to run systems in parallel. You may have to have contingencies for “failing back.” Your users will have to understand how you are doing the transition, and will have to help make sure systemic controls are in place.

These are good things.

You will have to make sure you keep the books and records of the firm intact. There’s no excuse for values getting corrupt due to the transition.

If they worse thing happening during a transition is your users declare the target environment solid and want to accelerate the transitions…that’s a good thing. And this isn’t an invitation for “big bang” after a short trail….stick to your guns for an orderly transition as planned. Acceleration is good, having an excuse to do “big bang” isn’t!

Where are Businesses with DR and Business Continuity?

I recently refinanced my house for a lower interest rate. The final days leading to the closing give insight to the business continuity and DR improvements companies can strive to achieve.

My refinance was with the mortgage holder. This US bank, one of the big four and the recent benefactor of bailout funds, was more than happy to accept my refinance application.

As a bill-paying-never-in-arrears-with-my-mortgage customer, the approval process was lengthy. (“If only you’d missed some payments we could make this happen quickly” Argh.) Once finally approved, I wanted to move quickly to the closing to immediately begin reaping the benefits of the lower rate.

The closing was scheduled with great expectation for 8AM on a Wednesday.

This is when the company flaws became pronounced.

At 2:00PM the day before the closing the bank called, “We’re sorry, we don’t have the final closing numbers because our computers are down.”

“So a big name bank with billings of dollars (and bonuses to match) can’t access my closing account information. OK, interesting… banks should have generally available systems, outages are really unacceptable. Oh well, I’m sure it is temporary,” I thought.

Wrong…the next day, around 9:00AM, we rescheduled to 2PM.

And then we rescheduled to 4:30PM.

At this point, I asked for a manager. The manager sheepishly acknowledged, “We’ve now got the final numbers, but the Title Company we use has staff ‘working from home’ due to heavy snow in Maryland. They not able to work effectively from home.”

So this bank subcontracts certain key elements of the closing process to other firms…and obviously the business continuity plans are ineffective. When was the last time these plans were exercised? If Maryland is getting hammered with snow, why not redirect the work to the west coast? Why isn’t the bank asking these questions of the firm they use?

Another day goes by, and I’m still paying the old, higher rate on the mortgage. Somehow, this doesn’t seem right. And what reasonable recourse do I have? I am paying the bank for a service, and they hired the other companies. The DR and continuity plans are clearly inadequate. How do I get reimbursed for the extra day at the old interest rate? How do we address the poor service issue?

As a customer, there’s little we can do beyond being vocal, especially at the end of a long road. The companies providing the weak service get paid no matter what, and are not held accountable.

Ironically, if a gas pump at a local gas station doesn’t work, you either use a different pump or go to a different station. There is a direct impact on the sales and profitability of the station. It’s a simple model.

How does a bank get held accountable by their customers? Go to a different bank…easily said, and harder to do at the end of a process. I don’t envy Department of the Treasury Secretary Timothy F. Geithner trying to sort the bank accountability issue!

Did I eventually close? Yes. I did discover this bank has an active social media monitoring effort. To their credit, they picked up on some tweets in the waning moments of the process and tried assisting.

The closing attorney and I did have a bit of a disagreement; I insisted the computer generated forms use my name and not someone else. We’ll talk data quality in another post!