Pursuit of Perfection, 1: Mission Creep

The best is the mortal enemy of the good.                                                                            

—Montesquieu

I am in Omaha this week and next week, visiting my parents.  This is why there was no essay on Monday.  In lieu of an essay, I was going to use this quote in my Quotes I Like series, as a way of talking about the fact that this week and next week might not get an essay on MWF, since I wasn’t going to prioritize essay-writing perfection over quality time with my parents.  But as I was writing the usual short paragraph explaining why I like the quote, it started to spin into a longer essay on a problem I have seen with a lot of process improvement work.  Turning a quick idea into a longer essay seems related to my tendency to turn one essay into two or three, so this seems pretty on-brand for me.  Since it is a paragraph-turned-essay-turned-two-essays, it also becomes a perfect example of today’s essay topic: mission creep.

Change is hard in any organization.  But lost in all the conversation about workflows and training and “change management” is that realizing real change is difficult to achieve in the typical workgroup process.  Most efforts to change processes and targets die with a whisper in subcommittees and workgroups throughout an organization.  I once reported to my boss on a process change that was successfully piloted and ready for roll-out.  I was discussing how to execute this and she said, “You know, I think this is the first successful pilot in this department’s history.”  It was a striking statement and, upon reflection, neither of us could think of a single previous example.

In talking about this, we realized that the issue was not creating a successful solution, but in getting the process focused and productive to start with.  In the constant buffeting of work, the ability to focus on something distinct and different, something that fits within the “…and additional duties as assigned…” boilerplate of everyone’s job description, was difficult.  Coordinating this with the schedules of a half-dozen other people (or, God forbid, more) was even worse.  Getting all those people aligned, though, was the hardest of all.  The biggest obstacle to getting something ready for opening night is that these groups will often make perfect the enemy of good. 

Now, avoiding this trap is easier said than done.  In some ways the structure built to create solutions leads to this suboptimal outcome.  These workgroups are generally formed when a problem is identified, and a leader pulls a team of people who are keenly aware of the current situation together to solve that issue.  The members are selected because they are “closer to the problem” which is a good.  But while they may have the knowledge base, they may lack the skills to organize and execute a solution process.  The group is often comprised of passionate people, but that passion doesn’t always translate into a workable product.  Included in this mix are often:

• Those that see this as the ONE CHANCE they will have to fix everything.  They have probably been complaining at the watercooler or their boss about the various issues that make their work 21% more annoying than it needs to be.  They will see this as an opportunity to address all ills, since they may never get this chance again.  These are the Alexander Hamiltons who don’t want to waste their one shot.
• Those that see this as an opportunity to build their resume.  By volunteering they can catch the attention of their boss and score points during performance appraisals.  Like the people above, they see this as their one chance to distinguish themselves from the pack and know that the quality of the final product will reflect back upon them.
• Those who are at the table because of their subject matter expertise.  They understand the inner workings of the data, or software, or facilities, or staff that need to be addressed to build a successful strategy.  These are the nerds¹ that can tell you what happens when you pull one thread.  They know the consequences of every change.

All these people are important.  They carry the knowledge base and passion.  They have been thinking about possible solutions for years.  But all also provide an environment for failure, because all have their own reason for making the pursuit of perfection their primary goal.  They want to solve all problems and account for all possibilities.

In this space, whether the leader who called for the workgroup to be created actually serves on this team is immaterial.  They may have other responsibilities, so they will not participate, often under the excuse of “I don’t want scheduling around MY calendar to be the problem.”  Or they will attend, but as they don’t know all the nuances, they may not be able to keep the team focused on the important details while also keeping the team out of the ditch. 

There are two main ways these groups find themselves at sea.  They can “go big” or “go small” (which seems like the two obvious issues), but impressively they can often do both at the same time.  I will explore “go small” in the next essay.  Here I will explore why or how a workgroup can “go big.”

Many have heard the phrase “mission creep.”  This phrase likely needs no real description, but here is one anyway.  Mission creep occurs when additional problems are added to the core issue, because they are highly-related or deemed necessary to the core objective.  This is a problem because by adding additional elements to a plan dilutes resources and focus.  Since the workgroup is comprised of people for whom this is not their “real job,” increasing the scope of work means decreasing the available time to address all elements present in this work.  Everyone understands why this is a problem.  So how does it happen?  Usually, one of three things paves the road to perdition.

Search for the first cause

We have all problem-solved and have had the realization that “if we want to fix Z, we first need to fix Y and if we want to fix Y, we first need to fix X…”  It is true that if we don’t account for root causes, we won’t create a useful solution or even prevent the system from breaking again.  I was working with some patient experience data and had a leader of the physician group want me to standardize the specialty labels in the data.  She wanted to see how some specialties fared compared to others.  The problem was that the labels were all alphanumeric labels, so a family practice doctor may have been tagged as “FP,” or “Family Practice,” or “family practice,” or “FAMILY PRACTICE,” with even a “Family PRactice” typo included in the list.² She wanted me to force-recode all of these so they would all align perfectly.  I said that I could, but it would not matter, since these variations were coming from some outside source, so unless that source got fixed, any adjustment I would make would not matter as new records filtered into the dataset.  So, before you can fix the output, you need to fix the input.  Years later, I would wager that this has still not been fixed.  Searching for the first domino in the line is not mission creep in-itself.  But differentiating between the real first-cause problems and just walking backwards and identifying new related problems can be difficult and is the reason why it is easy to fall into this trap.

Differentiating Nice from Need

This journey to find the headwaters of a problem can get compounded by those who see this as the one real opportunity to get a bunch of related issues addressed.  Often you will hear people ask, “Is this a must-have, or a nice-to-have” as a way of differentiating between the things that should be in-scope or out-of-scope for a project.  Much like dealing with dominos, this seems an obvious trap to avoid, but in the real world, it can be more challenging.  For many problems, once the work begins, it may be perceived as easier to just take care of a few related issues while the work is being done. 

A million years ago, in a house far-far-away, my wife wanted to reorganize the living room and dining room.  The rooms’ layout made sense when we first moved in but didn’t align with the real traffic patterns and needs that evolved in the subsequent years.  It would mean moving some big pieces of furniture, like a bureau, bookshelf and TV cabinet, which would in-turn mean emptying said items so they would be less impossible to move.  But then, since we are going to move all the furniture, perhaps we should use this as an opportunity to clean the carpets.  Oh, and if we are going to move the furniture and clean the carpets, perhaps it is a good time to repaint the walls. 

It wasn’t necessary to do these things (not dominos that needed to be addressed) to reorganize the rooms, but the logic was simply that since the effort was already going to happen, why not kill three birds with one reorganization.  It also meant that a task that was scheduled to take one Sunday afternoon was now going to take days.  Given that we both worked 40-hour jobs, it would more likely take weeks.  Now, I agreed with the need to clean the carpets, and I agreed that the room could use a new coat of paint.  The question was whether these were need-to-have things or nice-to-have things.  Were they worth changing the timeline of the work.  We ended up biting the bullet and doing everything and lived in a chaotic setting for a couple of weeks.  It was successful because we rescoped the project and changed the timeline.  In business, though, being able to change timelines or redraw the scope of the project may not be under control of the workgroup.  Or, more importantly, the workgroup may not know HOW to reframe the work and timeline.  They simply find themselves with massive mission creep because no one asked an important question at an opportune time.

Pursuit of Stakeholders

As work gets fleshed out and as the mission starts creeping, it can become clear that the right people may not be at the table.  The team realizes that someone from scheduling should be here to discuss what the current workflow looks like for them.  Someone from data management should be here to discuss what the data architecture looks like so we can adjust the demands to the existing supplies.  Or the team realizes that itoget support for a more complete solution, they need to get more stakeholders at the table to add heft and urgency to the task.  Of course, adding stakeholders means either convincing them that the current work will benefit them, or reworking the work, so they will get benefit from it.  Not only does adding cooks to the kitchen make the process more cumbersome, but it also changes the desired outcome.

I worked on a project to address gaps in on-boarding patients to a health system.  It was obvious that we would need folks from Scheduling in the room.  We would need Clinic Manager representatives in the room.  We even got a physician to join the team.  We had the right stakeholders to figure out how to easily bring new patients to the fold.  But while we had the same general target (making it easier to bring in new patients), we did not have the same focus for the work.  Scheduling was focused on making it easier for scheduling.  The clinic manager was focused on making it easier for clinics to manage.  The doctor was focused on making it easier for physicians to accept new patients.  I was focused on making it easier for patients to navigate the process.  As you might imagine, each of these elements were different and, in some cases, conflicting.  Having the right stakeholders was key to creating a big overhaul, but it also created a surprising amount of fighting and hostility. 

Like so many pitfalls we all face, getting broad advice to avoid them often doesn’t help.  We don’t try to make life difficult for ourselves.  We don’t see how adding this one little thing will be a problem.  There is a reason why the phrase “The road to hell is paved with good intentions” has meaning.  In the next essay, I will discuss the other issue with creating workable solutions and discuss how to really avoid these traps.  For the moment, simply reflect on how easy it is to slide down this slippery slope.

¹The frequent readers of these essays know that I use the word “nerd” with great affection.  I consider myself a nerd.  If you are new here, well, I hope you can understand that my use of this word comes from love.

²If you don’t know why this is an issue, I envy you.  Suffice to say that it does.  Just say “alphanumeric recode” to your data nerd and watch the nervous tics manifest.