When Process is Ignored

EVERY project I’ve ever been on starts with the adage, “we’re going to follow process on this one.” Inevitably, somewhere along the way systems processes tend to become optional, leading to issues.

Why?

Initial Intent	Evolution

 When building buildings a strict construction process is followed. There’s a project manager, the general contractor, all the subs….there are regular construction meetings, a strict budget process, and clear handoffs. In other words, a disciplined process is followed. Generally speaking, we’ve had great success building projects in a neat, tidy way. And they often end up being works of art:

Samuel Beckett Bridge – Dublin	Zakim Bridge – Boston © 2008 Katti Seiffer

Of course, when we don’t follow process:

The construction trades have been following the same fundamental processes for hundreds of years. IT, as an industry, can measure its lineage back decades.

Why do we, in IT, stop using process?

We all know what happens. A project starts running behind, and shortcuts start happening. Or, we say we’ll go back and address…and of course, we never do. (How often do we hear of a construction project saying they’ll go back and fix the foundation? They don’t. They go back and make it right from the beginning.)

I contend the reason we stop using process is we don’t perceive the process provides incremental value. It’s not a matter of not following the process, it’s the process wasn’t right from the beginning. Too often, processes are developed in a vacuum without a real world perspective. Or they are developed with strict adherence to a best practice (think IT Infrastructure Library) without “rightsizing” to the organization.

When processes are bureaucratic, they often get jettisoned when the heat gets turned up. Ironically, it’s when the heat gets turned up organizations should best be relying on their processes.

So my recommendation is simple. When processes are implemented, consider whether they feel overly bureaucratic. If so, they probably are. Make sure processes are “right sized” to your organizational challenges. Processes are living, they need occasional (well thought out and publicized) maintenance and upkeep. Change processes too often and they will not be used (nobody will know the rules)!

Heavy process can burden an organization. Rightsized processes can accelerate and improve the quality of the delivery.

Technology – When it’s not used or ignored

Every 6^th grader knows water freezes at 32 degrees Fahrenheit, or 0 degrees Celsius. And most people living away from the Equator know ice is slippery. So why is it the Town of Westborough MA does not understand this?

This morning I was awakened to the sound of crunching metal…and car tires spinning on glare ice. I knew it was going to be icy the night before…television weather said so. Apparently my town didn’t pay attention.

Why didn’t my town monitor the weather more closely? Why aren’t they using simply freeze warnings, avoiding issues like this? Aren’t the police out all night, and wouldn’t they have noticed?

I felt terrible for these two cars (a nurse going to work, and a veterinary student off to the emergency hospital). The police said not to worry, the sanders are now out. A little late, I suppose. And a police cruiser is on the way.

A few minutes later, and the sander did come….sliding down the road. I felt even worse for the man in this car. Look closely…the car is off the road. The sander came over the hill, lost control, and tossed the car off the road.

The driver needed medical attention. Another call to the police, and we’re assured help is on the way.

The policeman said it took him an hour to get to the house. The fire department took about 10 minutes.

While all I lost was some sleep and my mailbox post, one car was damaged hitting my mailbox, and the other car will probably be totaled after losing in a collision with the sander. The poor driver was taken away in an ambulance, and I hope he is OK.

Massachusetts recently enacted laws requiring owners to remove ice and snow…is the town exempt? This road is part of a state route…is the state responsible?

There are a variety of technologies available….

From the feds, to local firms, weather forecasts are available. There are road sensors available.

Heck The American Meteorological Society is based in Boston.

Freezing roadways contribute to hundreds of million dollars in damages annually.

Today, in my little town and to be fair in others , a little technology and a little common sense would have gone a long way.

DR , BCP and Dirty Little Secrets

BCP…Regulations…Real testing…DR…Capacity…Capability…

Do you have an honest view of your ability to recover? How do you fix your resilience or recoverability, or even begin?

DR and BCP – How good is your DR and BCP capability? Ask anyone in a position of authority from the smallest firm to a well known national company and the response will likely be similar. “DR, BCP. Yeah we do that.” But when pressed, what you actually do for it, many many people don’t have a true grasp on it. There are lots of reasons for this. Some people truly don’t have a clue and just shrug it off. Others know the true state of their recoverability and just don’t want anyone to know for obvious reasons. Others are aware of their underinvestment in Business Resilience and it scares the pants off them. Still others think they have a good program but have no confidence that it will work.

Those are my observations from the unscientific research and work I have done in this field. We like to call it the ‘Dirty Little Secret’

Business Continuity, how could you not do that well? That’s an easy one. BC covers a broad spectrum of a business. I like to explain BC and DR as:

BC = people and DR = systems.

Whether BC or DR, to do them well, one needs to know what to protect and what to let go. Also, the amount of risk that can be absorbed by the business across its lines. This can be accomplished with a BIA, a Business Impact Analysis. Properly done it can actually save you money as you will know what and where to spend your scarce dollars to get the most bang for the buck. Refreshing it regularly (12-18 months) will ensure that you keep up with any growth or change in your business. Not only growth, but these days, contraction. You may be able to see where you can trim some of your spending.

DR and BC are similar to life insurance. Many times companies grow and grow and grow and DR/BCP gets put off until later. We need production systems, development systems, upgrade production….We can put off the DR upgrade to the next release. Once that is done, it is easy to put it off again and again. The result? Very similar to a family; young people get married and have a little insurance (enough to be buried if any at all.) Time marches on…a house, kids, cars… obligations. One day you take stock and oops, I have $10K of insurance and 1 million in needs.

Insurance, you can always go and buy and if you die before you get any….well, you won’t really care but your family will be pretty mad at you.

You business responsibilities on the other hand will have a direct impact on your livelihood. Fail to recover from a DR or BCP problem and you will be out of work. You may also be liable to regulators, state or federal authorities, and possible criminal liability if attestations of recoverability are made that turn out to be patently false. Rest assured, if you fail, the lawyers will be standing over the carnage looking to asses accountability. You do not want to be in that position.

Have an honest discussion with your CEO, CIO, COO or CFO. One or all of them are ultimately responsible for assuring the survival of the firm. If you or they don’t truly know the real score, conduct a test. If this is a problem, engage a contractor or consultant to design and administer one for you or to do an assessment.

If you know you are deficient, but not sure of where to focus, conduct a BIA. This will give you the tools to build a roadmap to recoverability. Whatever you do, don’t let your firm’s recoverability go unaddressed. You can make a difference and expunge the dirty little secret.

This post was prepared by John Manning, Associate Partner at Harvard Partners. He can be reached at john.manning@harvardpartners.com
 

When DR is Fraud

I am a big believer in Disaster Recovery (DR), or having the processes with the electronics fail.

DR can also be used to perpetuate fraud, as I learned in a recent company.

We were a property management company, receiving rents monthly. We tended to go out on the 10^th day of the month to collect unpaid rents.

Imagine our surprise when two tenants had handwritten receipts for paid rent…yet the automated system did not show anything?

It turned out our new receptionist was pocketing cash deposits, and handing out handwritten receipts. We discovered this quickly, and she spent time in the big house.

The lesson is to make sure your manual processes and automated ones “tie out.” At this company, nobody was checking the manual receipt log…especially where we’d had no outages.

We were fortunate…at the end of the day we lost a few hundred dollars. A bigger company with more cash could have had a devastating issue.

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.

Can Systems Be Made Resilient?

I recently read an article about Google’s new self-driving car, and I was intrigued by a reference to the requirement that the computer hardware and software running the car be completely resistant to failure. In so many words, a “blue screen of death” while in motion would probably lead to a deadly blue screen of death.

I believe hardware and software can be made 100% resilient to failure, so why, as infrastructure professionals, do we never witness a truly resilient system?

Well, we do. A few devices with resilient hardware and software systems are:

• Apollo 11
  
  
• My car
  


• TiVo systems (note, I did not say Comcast or FiOS DVRs)
  


• Calculators
  
  

When something works well, we should take the time to examine how to replicate the processes leading to a better deliverable. Everything we do should include “lesson learned,” and every lesson learned should result in a project to make things better. Problems will diminish and our focus will shift to developing value-added business processes, rather than fixing what is broken.

In an article called “The Infrastructure Economics Breakthrough,” in this month’s Wall Street & Technology, Howard Rubin posits that infrastructure professionals have yet to deliver high quality infrastructure for less money. The panacea of “scale” we all talk about has not been attained and we [infrastructure folks] prevent investment in business deliverables that could drive higher profits.

Maybe one of the reasons we can’t optimize the infrastructure is that we are too busy fixing the hardware and software designed to give us an optimized infrastructure. When was the last time you implemented something that didn’t require a fix, patch, or an “enhancement” to get it to work correctly? We all know not to implement a “zero point release” of a product. We will let someone else shake out the bugs, and only then will we consider planning for an implementation. That doesn’t sound productive, and you know someone is going through the pain of being the early adopter.

I have a solution. Let’s ask Sam Palmisano, Larry Ellison, Eric Schmidt, Steve Ballmer, and other hardware/software CEO’s to drive cars with the hardware and software at the same level of quality at which they release their products. I bet they would think twice, and maybe we would see an improved focus on resilient systems.

Technology and Toasters

My wife and I frequently talk about technology. I love it, she hates it. WHY? I think that the pace of change has been stunning over the last two decade and the new devices that are available continue to amaze me. (I love my toys)

I recall getting a new PC that was 486 DX4 with a 20 meg hard drive….I was the baddest dude on my street with the hottest machine, ( amongst me and my geek friends)—- Pathetic.

What that 486 did teach me was how to load all my own software, configure DLL’s, and triage all of the obnoxious cryptic Microsoft error/warning messages. Before I had my 486, I was living large with a 286 but no Windows only DOS. By growing up with DOS, I was forced to gain an understanding of how those infuriating boxes worked. I also managed a helpdesk and software installation. Good training for knowing how the x86 architecture operated.

On the opposite, my wife is a consumer. Her background was in the insurance industry and legal profession. Her expectation is that when she presses the button she is delivered a good or service. That is, a screen appears that is useful and does something she wants. The analogy we use is that her PC should be like a toaster. She hits the button and it delivers something warm, tasty and useful. It meets her needs. He issue is that she is constantly required to know things that the operator of toaster wouldn’t be expect to know. For example, to install software, do you need a CD, is it a flash memory or do you have to go to a website. YUK, for a toaster, you insert the bread hit the button- BAM you get toast.

There is a bewildering array of things that kids can do the family PC that leaves us wondering….how did they get the home screen to be size 40 pt font? Again, it requires knowing how to navigate and get things back to a ‘normal state’. For the toaster, you turn one knob lighter or darker- simple. Why can’t the PC be more like that?

AH HA you say, you should get a MAC… Why should I. Granted they look cool, work cool and are very stylish, BUT, everything we have and do is PC based. It would require a paradigm shift in the house for all users. PLUS, PCs have been commoditized. There is great competition in PC architecture that continues to drive innovation, improve capability and reduce cost. The same can’t be said for Apple. They have and continue to try and keep a stranglehold on their franchise. We’ll see how long that lasts. Look at the Iphone. Very cool but the competition is really heating up.

So, what is the point of this rant? PC’s have a long way to go to be user friendly. What I see is convergence: the ease of use of Apple’s interfaces and set up, the commoditized pricing, and continual delivery of faster, smaller, and more efficient. Hopefully, PC’s will become more like toasters. Push the button and it will deliver simply every time.

This post was prepared by John Manning, Associate Partner at Harvard Partners.
He can be reached at john.manning@harvardpartners.com

Change

When you think of a piece of “computer paper,” what do you envision?

Do you think of a white “letter-sized” piece of paper sans perforations? Or do you think of an 11”x14 7/8” (or 8.5”x11 7/8”) “greenbar” paper, with sprocket perforations on either side of the paper? If you remember greenbar, you must be over 40!

Greenbar, paper with wide green (or blue) “bars”.

The bars helped the reader to follow the lines of text on wide printouts and reports. The bars were 1/2 inch wide which is 3 lines at 6 lines per inch or 4 lines at 8 lines per inch. Normally 132 characters would be printed across the width of the page at 10 characters per inch.

There was a whole industry around computer printouts. There were fiberboard covers, with neat nylon posts to hold the paper. These covers would then “hang” in special computer filing cabinets.

In the mid 80s, the shift to the current “standard” began. I was working for an office products company, and while we were predicting the paperless society, the company invented ion deposition printed to compete with laser or ink jet printing.

We were very excited when we began the shift from the old style printouts to the new. The first day, we were handing printouts to our users fully prepared for accolades. While most embraced the change, there was an accounting supervisor who quickly threw water on our enthusiasm. “I have no place to store these printouts.” Working for an office products company making 3 hole binders, I was rather taken aback by the comment. But, but, but…..

Over time, we overcame the objection, although we did for a long time print “greybars” on the paper.

We made many mistakes in our rush to be good corporate citizens all coming down to good change process.

We should have:

• “tested” the format change more.
  
  
  
  • - At first, we offered “3 hole punched” paper, and “plain.” We eventually switched to just 3 hole punched.
  
  
  • Greenbar was also a continuous sheet, where the new format is loose sheets. This required us to come up with a “packaging” solution.
  
  
  
  
• Communicated to our users more. Yes, we let them know it was coming. In hindsight, we could have done more…such as sending out sample reports, letting them have time to buy some 3 hole binders


• Switched formats at year end, or at least end of quarter. While minor, it would have eased some of the storage issues.

Where else are we having changes in the industry?

When greenbar was popular:

• There was no PC.


• Cell phones were the size of briefcases.


• “Dial up” was over an “acoustic coupler.” (In hindsight, it’s amazing an acoustic coupler ever worked.)


• Faxes were all printed on thermal paper. Leave the thermal paper by a window, and the fax went away!


• Flat panel displays have largely replaced the “tubes” even though “tubes” are less costly to acquire


• Many companies had one scanner, in an engineering or graphics area. Now, scanners are in many desktop printers and all fax machines (fax scanner may not have color – yet)

So what are the new technology innovations we still need to communicate and prepare our users to learn and embrace? Let me know.

By the way, we’re still going to be paperless. Someday.

How to be a Thought Leader in IT

Steve Sweeney, of Affinity, reached out after reading a thought leadership thought leadership blog and suggested a Curriculotta post, “How to be a Thought Leader in IT?”

The original blog post posits:

According to Wikipedia, a thought leader is a futurist or person who is recognized for innovative ideas and demonstrates the confidence to promote or share those ideas as actionable distilled insights

How does this apply to the real world? I am still thinking on this, but here are my early reflections:

• You need to be original in your thinking.

• You must have enough edge to force people to have an opinion.

• You must address issues that broaden everyone’s horizon.

• You must act as a gate-keeper that finds and share relevant information.

• You need to build a following that buy into and help spread your ideas.

Of course, all these elements apply in the IT realm.

A thought leader in IT needs to:

• Be knowledgeable in the business and technology. Understanding business is vital, and technology important. Understanding the technology application in the business setting is where the value is provided.
  
• Understand trends. This is one of the most challenging and rewarding aspects of the IT professionals role.
  
  It’s important to understand the business trends. I first met the late Michael Hammer while working in manufacturing. He was talking broadly about business process reengineerging, then in the nascent stages. His thought was if manufacturers where keeping track of retail level transactions, waste could be removed. Years (truthfully, decades) later, Dr. Hammer was using the same slides in a presentation on financial services Straight Through Processing (STP). After his talk, I asked him privately about his reuse. He smiled, and said some industries take longer than others…
  
  While arguably a simple comment, the thing about Hammer is he had a way of capturing trends in a simplistic way.
  
  Technology trends are also an obvious area for focus, and where a technologist often must make value judgments around technologies to back, and which players will be around. Once proud Massachusetts companies like Wang, Prime and Digital have given way (or been acquired) by the HP, Dell, or IBM.
  
  There are lots of companies making disk drives. In enterprise data centers EMC and Network Appliance are often found…although HDS, Compellent and 3Par have excellent products.
  
  Getting a sixth sense for the technologies taking off beyond the niche is the key. There are lots of great niche products available…understanding the ones with legs and financial support are differentiators.
  
  There are many ways to get aware of trends. Watch larger companies in your industry or others for where they are focusing. You can do this by reading publications, attending conferences or Society for Information Management meetings, or working with consultants.
  
  Keep an eye on where leading colleges and universities are researching.
  

  
  Don’t network with just the same groups. Keep an insatiable curiosity for the new, and applicability in your environment.
  

• Try something. In my mind, every IT shop, regardless of size, can fund a single skunk works effort. Take some of your best and the brightest people, and have them work on a “pilot” project determining the feasibility and value of some new thing.
  
  Silicon Valley started in a garage. The IBM PC was invented far from stodgy New York…in Boca Raton, Florida.
  

  While you won’t be creating a PC or launching an industry, you may be doing some leading edge work on worker mobility, desktop (specifically PC) video conferencing, behavioral intrusion prevention, or the like. Here, fund something you think has business applicability, with a 3-6 month deliverable timeframe, where “rough” is acceptable. You want to see a proof of concept, not a fully functioning enterprise ready deployment. That can come AFTER seeing the proof of concept.
  

  By the way, there is no reason why every person can’t do a little skunk works effort. The office superstore Staples original website was developed by three guys (a contract/commercial IT guy, a PC/networking guy, and an ops manager) using a (now defunct) outside firm interested in helping companies get on the web. The entire process was “hosted” external to Staples corporate as a way to eliminate technical risk (although the marketing people were not pleased with Staples’ skunk works on-ramp to the information super highway!)
  

• Partner with a local college or university – Interns are a great way to get work accomplished with some of the best and brightest. And as I like to say, they are naïve enough to do just about anything! Please respect interns will need management/leadership time (most corporate cultures are very foreign and “enterprise quality” is not in most curriculums.)
  

  One company, Fidelity Investments, had the Systems Associates Program (poorly abbreviated SAP) as a way to onboard interns. Interns would complete a 2 year assignment, made up of four 6 month rotations. At the end of two years, promising SAPs would often have the opportunity for permanent placement.
  

  These types of programs tie you closely to where the research and thought leadership often originates.
  

• Let the group work in teams – IT can often be an introverted function. IT is often made up of introverts, or geeks. When presented with a challenge, often the IT person starts working the effort alone. While useful for initial thought organization (especially for the more introverted), getting teams together will often generate an exponential increase in the number of ideas and innovation.
  
  

• Expect and accept failure as a part of a learning process – in a pilot group environment failure is contained, and is learning.
  
• Talk the successes up! Whether something you learn at a conference, invent on your own, develop in a skunk works effort….let others know what is working in industry. It can be your industry or others, it’s the applicability to your business that’s key.
  

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