Growing a Business is like Migrating Services to the Cloud

When a business is in a transition between sizes, for example from Small to Medium-sized, all the business systems are expected to be able to grow with it at the same pace and at the same level of quality. Many don’t realize the demands of growth don’t necessarily scale well without fundamental changes in how it operates both in their management controls, process workflows, and the responsibilities of the personnel managing the processes.

The same holds true for migrating applications and services to the cloud. When applications are hosted on internally owned and managed servers, the maintenance and reliability of the hardware and software is managed by internally controlled resources. When they are moved to the cloud, organizations lose the level of control of quality and reliability unless fundamental changes to the system are made to be more fault tolerant, flexible to demand spikes, and redundant in the event of hardware failures or response times as a result of a multitude of causes, such as human errors, cut transmission lines, and power outages. Read an interesting account of how Netflix uses their Chaos Monkey to insure the best user experience even during major system failures.

On the surface, just doing more of what was always done may look like the growth process is healthy and successful, but there are probably obstacles looming just out of sight waiting for the right time to surface. A healthy dose of planning and evaluation with a multi-disciplined team can go a long way to preventing catastrophe or at the very least identifying the potential risks.

 

photo credit: Mykl Roventine / CC BY 2.0

Operational Excellence doesn’t have to be an Either-Or Decision

Six Sigma vs. Lean; Shingo Prize vs. Malcolm Baldrige

Lean, Six Sigma, and other methodologies and programs are great, but none of them solve all the problems all organizations experience. As an example, Lean doesn’t solve difficult scientific problems with complex interactions. I am a Lean practitioner and certified Six Sigma Black Belt and have used both of them to solve difficult problems, but I don’t wedge my experience with either into every situation or issue I encounter.

Possibly organizations could be better served by the technical community if instead of focusing on a single cookie cutter strategy for improvement for the entire enterprise, they used the one(s) or a blend that best matched their needs, current conditions, and vision for the future. All environments, cultures, and challenges are unique, why should we expect a “one size fits all” program to be the silver bullet?

Mocking Change

In software development mocking is a deliberate effort to simulate other system elements, such as a database, with a representation of the element in order to test a portion of the software without interacting with the actual database. Mocking is a tactic to make sure that software works as expected throughout the development process and when changes are introduced.

When facing the implementation of a big change in a business process or initiative, why not mock the elements of the change that might be complex or difficult in order to solicit as much feedback as necessary about what might go wrong or isn’t getting adequate consideration to ensure a positive experience for all the participants and stakeholders?

 

photo credit: Teddybear Junction / CC BY 2.0

Five Ways to Incorrectly Use Technology

How you adopt technology in your personal life is a personal choice. How technology is used in an organization affects many others, requiring careful consideration to provide its benefits without negative repercussions.

The top five ways organizations incorrectly use technology:

1. Implement a technology for technology’s sake.
2. Pick a technology because it is cool, trendy, or new.
3. Use it to fix a broken process.
4. Introduce it without adequate trials or testing.
5. Pick the version with the most bells and whistles.

I’m a big proponent for the use of technology when it is used in a way that truly supports the organization from every perspective. Nobody Likes Bad Change™ in technology, work, or life. Let’s do our part to introduce only good change:

• use the right technology
• for a specific process
• considering the available resources
• at the appropriate time
• to achieve the desired outcome

 

Photo credit: Qole Tech / CC BY 2.0

Resistance to Change – Inevitable or Preventable?

I hear and read about resistance to change frequently. Most of the time it is referred to in a negative light or as an inherent human weakness. Wouldn't it be more productive if we focused on the “Change” itself rather than the “Resistance”?

We have all been on the receiving end of change that didn’t work out well for us, so it is natural to be apprehensive. If we think back to one of those “bad” changes, can we think of ways the change could have been approached that would have made it a better experience for the both the leaders and the participants?

Resistance to change can often be prevented – and I don’t mean through the use of force, quite the opposite. Just a few ways to improve the adoption of change is through the application of:

• betas
• simplified learning tools
• prototypes
• pilot trials
• demonstration
• user experience observation and testing
• involvement

The general expectation is that change should be “good”. A common experience is that it isn’t. If change wasn’t actually “good”, we wouldn’t constantly be trying to introduce it. We should probably put more effort into making sure everyone that is impacted by the change understands the benefits and agrees that it actually is “good”. If they did, we probably wouldn’t be experiencing so much resistance.

Other posts about keys to successful change implementation

Project Failure - Just Set It and Forget It

Improvement projects are always at risk for project slip and subsequent failure. It is necessary to be tenacious about communication and countermeasures to prevent. One of the most dangerous times is after initial release of new tools, software, or processes. Communication and feedback are most critical here. It is often easier for people to slip back to the old way than pick up something new – even if you perceive the new way as being easier. Don’t just walk away, even if it looks like a slam dunk.

There are two ways that resistance to the new process show up:

1. Vocal communication
2. Silent death

In the case of vocal communication, make sure to pay close attention to the concerns being voiced. They may sound like complaints, but they are really the ticket to success. If you can address their legitimate concerns, people will hop on board and bring others with them.

If all things are quiet with a lack of feedback or communication, proactively look closely for the presence of warning signs. Hesitating to uncover silent concerns and put countermeasures in place quickly will drastically reduce the momentum needed to get the best result. That is how so many corporate initiatives become “just another corporate initiative”.

Group Agreement vs. Executive Order in Moving Initiatives Forward

Executives have the job of setting the strategies and objectives for an organization to meet/exceed their corporate goals. The managers and front line people further down the organizational hierarchy are responsible for making it actually happen.

• Can an organization move forward with only an executive directive? Sure, some can.
• Will it be as effective without group agreement? Not likely.

The less group agreement you have, the more likely the initiative will be point optimized in each of the organization’s vertical silos. The maximum effectiveness is achieved when the optimization takes place horizontally across departmental or functional boundaries. Group agreement is fundamental to that process.

You Might Have the Wrong Plan If…

You might have the wrong plan or approach to solving a problem if:

• The leader or project owner comes into the problem solving meeting with a list of action items already formulated and starts delegating them to the “participants” in the meeting.
• People are talking negatively about the plan in their cubicles or around the water cooler and no one is stepping out as a spokesperson for why it is the right plan/approach.
• Groups of people are openly showing resistance to change.
• The attendance at the status meetings declines every time the group meets.

You are on the right track to a good plan if:

• People eagerly start listing activities that need to be accomplished and volunteer to take care of them (following through).
• People in the participant group are heading off resistance from others without escalation to the project owner or leadership.
• People have a sense of pride and ownership of the process they have a hand in crafting.

This is most applicable when the problem at hand crosses departmental and/or geographic boundaries and would be best solved using true employee involvement from a cross-disciplinary team.

* I’m obviously not an artist so please cut me some slack on the cartoon.

Healthcare Reform – Rewrite or Refactor?

Few people disagree that the healthcare system in the US needs to be reformed. How many people would agree about the best way to successfully accomplish it?

The article Understanding Healthcare Reform lists just a few of the elements of healthcare with links to several sub-categories within each of the following elements:

• coverage
• payment systems and costs
• patient safety
• health information technology
• medical research

For me the article is a reminder of just how complicated the healthcare system is. When a solution is required of a large scale system like healthcare, one has to consider whether it should be completely overhauled - or refactored* piece by piece. Without the right approach to the problem, it is conceivable that the solution could create substantially bigger problems than the current system. Joel Spolsky, a contributor to Inc magazine and owner of a New York software company, summarized it best in Things You Should Never Do, Part I, in reference to re-writing a software program from scratch.

“It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.”

If healthcare is to be reformed without the risk of creating more problems related to care, coverage, or cost, the system will have to either be refactored fixing one broken piece at a time - or piloted in a smaller representative area or areas and refined and scaled out until the system proves it meets everyone’s expectations.

 

* definition from wikipedia: Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal quality attributes of the software, for example to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, to improve performance, or to improve extensibility.

Healthcare and software seem like completely different subjects, but there are many parallels between large complex software programs and other large complex systems from other industries like healthcare.

Questions Lead – Answers Follow

One of the fundamental mistakes I have seen repeatedly that leads to the loss of expected impact of improvement to a business process is making changes based on individual observations, education, and experience alone. What is missing is asking questions of all the people impacted by a proposed change. The people that operate, support, audit, and reap the benefits of a process, collectively referred to as stakeholders for the purposes of this post, often have valuable knowledge about a process.
Processes are used to complete a task, or multiple tasks, repeatedly in a consistent manner. The nature of the repetition gives the local stakeholders many observations with which to build a mental repository of data about a process. There is one tool (often under-utilized) at everyone’s disposal that allows the harvesting of that valuable data. Asking questions will yield valuable insight about exceptional conditions, frequencies and probabilities of occurrences, pareto of key information, historical perspective, and trends. The information may not appear as reliable as data from a sophisticated electronic data collection device, but undervaluing it will certainly reduce the effectiveness of an “improvement”.

Technorati Tags: Employee Involvement,Business Process Improvement,Bayesian Statistics