For 12 years, I blogged and wrote a whole bunch. For the past year and a half, I’ve let myself be pulled away from so many of the things that make me me… including writing. Today I heard one of the best anecdotes ever, and it’s the spark that will be pulling me back in. (Thanks, John.)
(And if you’re in a client/contractor relationship, you’ll have discovered that estimates are the lifeblood of the relationship, even as they drain all the life and all the blood out of the relationship, slowly and deliberately.)
Sometimes I get caught asking engineers for estimates even when the task we’re embarking on is new, unknown, uncertain, and requiring lots of learning and exploration and discovery. I should know better. But I cave, because the concept of the software estimate is so enticing: with a good estimate, I’ll know exactly how much time someone will need to spend working on a task that’s still kind of nebulous and mostly unknown. (That was a joke.)
My friend John shared the best anecdote ever today about why software estimation is so frustrating (liberally embellished):
Imagine that you’re standing on a hill looking down at a labyrinth, or a corn maze. It’s reasonably small… you can see that the corn maze is definitely doable, you can see a couple paths in and out, and the entire maze is a similar size to other mazes you’ve successfully found your way out of. So you’re pretty sure once you get to the entrance, you’ll find your way out.
But there’s no way you can say exactly how long it will take you to escape. Maybe you’ll run right through from start to finish, and it will be smooth. Maybe you’ll get stuck in the beginning, and spend a long time before winding your way out. Maybe you’ll run right close to the end, but have no idea you’re a few feet away from the exit, and you’ll get stuck there for a while.
And maybe you’ll make it halfway through, get lost, go in circles, and eventually just die in the maze.
Problem is, I can tell you how long it’s taken me to get across comparable mazes, but I have no way of knowing how long it will take me to escape from this maze, and just having another engineer in the maze to pair with me and see things I’m maybe not seeing is no guarantee at all that either of us will get us. Statistically, we’ll probably make it out, but the estimate I give you is just a guess.
Unfortunately, it’s a guess that’s going to make a lot of people unhappy, no matter what. Because even if I make it out of the maze fast this time, then they’ll expect that I’ll zoom through the next maze.
Fifteen or so years ago, I was a member of a review team that assessed a major, multi-million dollar software project. We were asked to perform the review because the project had some issues — it cost nearly $2M a year, was not yet delivering value to users, and had been running for 17 years.
Were I the ultimate decision-maker, my plan of action would have been simple: shut down the project, reconstitute a team with some representation from the old team, and use the lessons learned to rearchitect a newer, more robust solution. It would have customer involvement from the start to ensure a short time-to-value (and continuous flow of value). But there was one complication: the subject matter for this software package was highly specialized and required active involvement from people who had deep knowledge of the problem domain… and the team already had about 60% of the world’s experts on it.
Still, I was focused on the sunk costs. I felt that the organization should not choose to keep the project going just because over $20M had been poured into it… the sunk costs should not factor into the decision.
But then something very curious happened two years later, as the project was still hemorrhaging money… I was put in charge of it. So what did I do? Launched a two-month due diligence to reassess the situation, of course.
I was not on the review team this time, but their assessment was not a surprise — can the project, reconstitute the team, use the lessons learned to plan a new approach to delivering value quickly.
So that’s what I did… right? NOOOOO!!! I decided to try a little harder… because of course we could get the current software project to be stable and valuable, if we just gave it a little more time.
Even I was shocked by my transformation. Why was I feeling like this? Why was I ignoring the facts? Why was I, all of a sudden, powerless to make the appropriate and most logical choice?
Turns out, I was just demonstrating human nature via the Endowment Effect — which says, simplistically, that once you own something you value it more than before you own it. This is not just a curiosity though… because it can get in the way of effective decision-making.
Think about it:
Before you buy a house, you psychologically devalue it because you want to get a better deal. But once you move in, your psyche inflates the value because you stand to win as the value increases.
Why is it that leaders often value the opinions of consultants more than the opinions of full-time staff? Because consultants are more expensive, and once their reports have been submitted, you now own the intellectual property… and value it more.
The same effect occurs if you buy a company. You may be sensitive to issues and opportunities for improvement prior to the sale, but once your signature is on the dotted line… the endowment effect kicks in, and the rose-colored glasses magically appear.
This has a huge implication for quality and process improvement. Once you own something, you are less able to see the problems that need to be solved. This is why we use external auditors for our ISO 9001 programs, or review panels for our government projects, or a quality award assessment process for evaluating how well we are translating strategy to action.
Other people can see areas for improvement that you can’t, if you’re an owner of the process that has problems. The lesson? Get external eyes on your internal issues, and pay attention to their insights.
(special shout-out to those of you who saw the typo the 30 sec it existed!)
In college, to meet my phys ed requirement, I chose a class where I wouldn’t have to exert much physical energy: golf. Almost three decades later, I still can’t play golf, but I did learn one thing in that class that has helped me through life.
When you’re trying to reach a goal, figure out a process to help you reach that goal, then focus on the process instead of the goal. I used this approach to improve my putting. Here’s how it worked: to get the ball in the hole, don’t aim for the hole… aim for a point along the line that goes to the hole, which should be easier to hit. If your ball hits that midpoint, it’s more likely that your putt will go in.
For example, if you’re at the white dot, aim for the Red X, not the hole:
This approach centers you on the process of making the putt. Getting your mind off the pressure of the goal results in the freedom to focus on what’s most important: developing the discipline and habit that will lead to success.
Bryan Cranston, the actor who played Walter White in Breaking Bad, had a similar experience until he was in his mid-40s. Although he had landed many roles in films and television series, none were the kind of long-lived and memorable performance Cranston was aiming for. So he made a conscious effort to shift his perspective.
Author Scott Mautz, citing Cranston’s 2016 memoir, describes the process:
Early in Cranston’s career he was an auditioning machine for commercials or guest-starring roles, a bevy of high-pressure stabs that might serve as at least a step up to the big time. But he was walking into a slew of rooms where he felt he had no power. All that changed when a mentor suggested a new outlook, and it led to an honest-to-goodness six-word secret to his success.
Focus on process rather than outcome.
Suddenly, Cranston felt free. He approached each audition as not going to get something, but to give something–a performance. And giving a great performance requires staying obsessively focused on the process of preparing to be able to give a great performance. He learned that if he overly focused on the outcome (will he get that part?) it set him up for disappointment and left him yearning for validation. Focusing solely on the outcome had also kept him from taking risks as he didn’t want to give a potential gig away with a mis-step.
But this mindset shift, of falling in love with and staying laser-focused on the process, changed everything for him. Soon after he adopted it, he got the role in Malcolm in the Middle, and then the career-changing Breaking Bad starring role.
When you have a challenging or aspirational goal in your sights, like when your organization is starting a lean transformation or digital transformation, it can seem overwhelming. The heavy feeling can actually prevent you from getting where you want to go.
The solution is to identify your intermediary goals — the ones you can achieve by developing and tuning an operational process. Let go of the aspirations, and focus on the daily work, creating the habits that will make you and your organization successful.
Over the past few years, Agile has gained popularity. This methodology emerged as a solution to manage projects with a number of unknown elements and to counter the typical waterfall method. Quality practitioners have observed the numerous similarities between this new framework and Lean. Some have speculated that Agile is simply the next generation’s version of Lean. These observations have posed the question: Is Agile the new Lean?
ASQ Influential Voices Roundtable for December 2019
The short answer to this question is: NO.
The longer answer is one I’m going to have to hold back some emotions to answer. Why? I have two reasons.
Reason #1: There is No Magic Bullet
First, many managers are on a quest for the silver bullet — a methodology or a tool that they can implement on Monday, and reap benefits no later than Friday. Neither lean nor agile can make this happen. But it’s not uncommon to see organizations try this approach. A workgroup will set up a Kanban board or start doing daily stand-up meetings, and then talk about how they’re “doing agile.” Now that agile is in place, these teams have no reason to go any further.
Reason #2: There is Nothing New Under the Sun
Neither approach is “new” and neither is going away. Lean principles have been around since Toyota pioneered its production system in the 1960s and 1970s. The methods prioritized value and flow, with attention to reducing all types of waste everywhere in the organization. Agile emerged in the 1990s for software development, as a response to waterfall methods that couldn’t respond effectively to changes in customer requirements.
Agile modeling uses some lean principles: for example, why spend hours documenting flow charts in Visio, when you can just write one on a whiteboard, take a photo, and paste it into your documentation? Agile doesn’t have to be perfectly lean, though. It’s acceptable to introduce elements that might seem like waste into processes, as long as you maintain your ability to quickly respond to new information and changes required by customers. (For example, maybe you need to touch base with your customers several times a week. This extra time and effort is OK in agile if it helps you achieve your customer-facing goals.)
Both lean and agile are practices. They
require discipline, time, and monitoring. Teams must continually hone their
practice, and learn about each other as they learn together. There are no magic
Information plays a key role. Effective flow of information from strategy to action is important for lean because confusion (or incomplete communication) and forms of waste. Agile also emphasizes high-value information flows, but for slightly different purposes — that include promoting:
Rapid, targeted, and effective action
The difference is easier to understand if you watch a couple cat videos.
This Cat is A G I L E
This cat is continuously scanning for information about its environment. It’s young and in shape, and it navigates its environment like a pro, whizzing from floor to ceiling. If it’s about to fall off something? No problem! This cat is A G I L E and can quickly adjust. It can easily achieve its goal of scaling any of the cat towers in this video. Agile is also about trying new things to quickly assess whether they will work. You’ll see this cat attempt to climb the wall with an open mind, and upon learning the ineffectiveness of the approach, abandoning that experiment.
This Cat is L E A N
This cat is using as LITTLE energy as possible to achieve its goal of hydration. Although this cat might be considered lazy, it is actually very intelligent, dynamically figuring out how to remove non-value-adding activity from its process at every moment. This cat is working smarter, not harder. This cat is L E A N.
Hope this has been helpful. Business posts definitely need more cat videos.
For this month’s Influential Voices Roundtable, the American Society for Quality (ASQ) asks: “In today’s current climate, transformation is a common term and transformative efforts are a regular occurrence. Although these efforts are common, according to Harvard Business Review two-thirds of large-scale transformation efforts fail. Research has proven that effective leadership is crucial for a change initiative to be successful. How can an individual become a successful Change Leader?“
Change is hard only because maintaining status quo is easy. Doing things even a little differently requires cognitive energy! Because most people are pretty busy, there has to be a clear payoff to invest that extra energy in changing, even if the change is simple.
Becoming a successful change leader means helping people find the reasons to invest that energy on their own. First, find the source of resistance (if there is one) and do what you can to remove it. Second, try co-creation instead of feedback to build solutions. Here’s what I mean.
Find Sources of Resistance
In 1983, information systems researcher M. Lynne Markus wanted to figure out why certain software implementations, “designed at great cost of time and money, are abandoned or excessively overhauled because they were unenthusiastically received by their intended users.” Nearly 40 years later, enterprises still occasionally run into the same issue, even though Software as a Service (SaaS) models can (to some extent) reduce this risk.
Before her research started, she found these themes associated with resistance (they will probably feel familiar to you even today):
By studying failed software implementations in finance, she uncovered three main sources for the resistance. So as a change leader, start out by figuring out if they resonate, and then apply one of the remedies on the right:
As you might imagine, this third category (the “political version of interaction theory”) is the most difficult to solve. If a new process or system threatens someone’s power or position, they are unlikely to admit it, it may be difficult to detect, and it will take some deep counseling to get to the root cause and solve it.
Co-Creation Over Feedback
Imagine this: a process in your organization is about to change, and someone comes to you with a step-by-step outline of the new proposed process. “I’d like to get your feedback on this,” he says.
That’s nice, right? Isn’t that exactly what’s needed to ensure smooth management of change? You’ll give your feedback, and then when it’s time to adopt the process, it will go great – right?
In short, NO.
For change to be smooth and effective, people have to feel like they’re part of the process of developing the solution. Although people might feel slightly more comfortable if they’re asked for their thoughts on a proposal, the resultant solution is not theirs — in fact, their feedback might not even be incorporated into it. There’s no “skin in the game.”
In contrast, think about a scenario where you get an email or an invitation to a meeting. “We need to create a new process to decide which of our leads we’ll follow up on, and evaluate whether we made the right decision. We’d like it to achieve [the following goals]. We have to deal with [X, Y and Z] boundary conditions, which we can’t change due to [some factors that are well articulated and understandable].”
You go to the meeting, and two hours later all the stakeholders in the room have co-created a solution. What’s going to happen when it’s time for that process to be implemented? That’s right — little or no resistance. Why would anyone resist a change that they thought up themselves?
Find the resistance, cast it out, and co-create solutions. But don’t forget the most important step: recognizing that perfection is not always perfect. (For quality professionals, this one can be kind of tough to accept at times.)
What this means is: in situations where change is needed, sometimes it’s better to adopt processes or practices that are easier or more accessible for the people who do them. Processes that are less efficient can sometimes be better than processes that are more efficient, if the difference has to do with ease of learning or ease of execution. Following these tips will help you help others take some of the pain out of change.
One of the heuristics we use at Intelex to guide decision making is former US President Truman’s advice that “imperfect action is better than perfect inaction.” What it means is — don’t wait too long to take action, because you don’t want to miss opportunities. Good advice, right?
When I share this with colleagues, I often hear a response like: “that’s dangerous!” To which my answer is “well sure, sometimes, but it can be really valuable depending on how you apply it!” The trick is: knowing how and when.
Here’s how it can be dangerous. For example, statistical process control (SPC) exists to keep us from tampering with processes — from taking imperfect action based on random variation, which will not only get us nowhere, but can exacerbate the problem we were trying to solve. The secret is to apply Truman’s heuristic based on an understanding of exactly how imperfect is OK with your organization, based on your risk appetite. And this is where loss functions can help.
Along the way, we’ll demonstrate how to do a few important things related to plotting with the ggplot package in R, gradually adding in new elements to the plot so you can see how it’s layered, including:
Plot a function based on its equation
Add text annotations to specific locations on a ggplot
Draw horizontal and vertical lines on a ggplot
Draw arrows on a ggplot
Add extra dots to a ggplot
Eliminate axis text and axis tick marks
What is a Loss Function?
A loss function quantifies how unhappy you’ll be based on the accuracy or effectiveness of a prediction or decision. In the simplest case, you control one variable (x) which leads to some cost or loss (y). For the case we’ll examine in this post, the variables are:
How much time and effort you put in to scoping and characterizing the problem (x); we assume that time+effort invested leads to real understanding
How much it will cost you (y); can be expressed in terms of direct costs (e.g. capex + opex) as well as opportunity costs or intangible costs (e.g. damage to reputation)
Here is an example of what this might look like, if you have a situation where overestimating (putting in too much x) OR underestimating (putting in too little x) are both equally bad. In this case, x=10 is the best (least costly) decision or prediction:
# describe the equation we want to plot
parabola <- function(x) ((x-10)^2)+10
# initialize ggplot with a dummy dataset
p <- ggplot(data = data.frame(x=0), mapping = aes(x=x))
p + stat_function(fun=parabola) + xlim(-2,23) + ylim(-2,100) +
xlab("x = the variable you can control") +
ylab("y = cost of loss ($$)")
In regression (and other techniques where you’re trying to build a model to predict a quantitative dependent variable), mean square error is a squared loss function that helps you quantify error. It captures two facts: the farther away you are from the correct answer the worse the error is — and both overestimating and underestimating is bad (which is why you square the values). Across this and related techniques, the loss function captures these characteristics:
Not all loss functions have that general shape. For classification, for example, the 0-1 loss function tells the story that if you get a classification wrong (x < 0) you incur all the penalty or loss (y=1), whereas if you get it right (x > 0) there is no penalty or loss (y=0):
# set up data frame of red points
d.step <- data.frame(x=c(-3,0,0,3), y=c(1,1,0,0))
# note that the loss function really extends to x=-Inf and x=+Inf
ggplot(d.step) + geom_step(mapping=aes(x=x, y=y), direction="hv") +
geom_point(mapping=aes(x=x, y=y), color="red") +
xlab("y* f(x)") + ylab("Loss (Cost)") +
ggtitle("0-1 Loss Function for Classification")
Use the Loss Function to Make Strategic Decisions
So let’s get back to Truman’s advice. Ideally, we want to choose the x (the amount of time and effort to invest into project planning) that results in the lowest possible cost or loss. That’s the green point at the nadir of the parabola:
What this means is — if we don’t plan, or we plan just a little bit, we incur high costs. We might make the wrong decision! Or miss critical opportunities! But if we plan too much — we’re going to spend too much time, money, and/or effort compared to the benefit of the solution we provide.
The trick is to FIND THAT CRITICAL LEVEL OF TIME and EFFORT invested to gain information and understanding about your problem… and then if you’re going to err, make sure you err towards the left — if you’re going to make a mistake, make the mistake that costs less and takes less time to make:
The moral of the story is… imperfect action can be expensive, but perfect action is ALWAYS expensive. Spend less to make mistakes and learn from them, if you can! This is one of the value drivers for agile methodologies… agile practices can help improve communication and coordination so that the loss function is minimized.
## FULL CODE FOR THE COMPLETELY ANNOTATED CHART ##
# If you change the equation for the parabola, annotations may shift and be in the wrong place.
parabola <- function(x) ((x-10)^2)+10
my.title <- expression(paste("Imperfect Action Can Be Expensive. But Perfect Action is ", italic("Always"), " Expensive."))
arrow.x <- c(10, 10, 10, 10)
arrow.y <- c(35, 50, 65, 80)
arrow.x.end <- c(6, 6, 6, 6)
arrow.y.end <- arrow.y
d <- data.frame(arrow.x, arrow.y, arrow.x.end, arrow.y.end)
p + stat_function(fun=parabola) + xlim(-2,23) + ylim(-2,100) +
xlab("Time Spent and Information Gained (e.g. person-weeks)") + ylab("$$ COST $$") +
annotate(geom="text", x=10, y=5, label="Some Effort, Lowest Cost!!", color="darkgreen") +
geom_point(aes(x=10, y=10), colour="darkgreen") +
annotate(geom="text", x=0, y=100, label="$$$$$", color="green") +
annotate(geom="text", x=0, y=75, label="$$$$", color="green") +
annotate(geom="text", x=0, y=50, label="$$$", color="green") +
annotate(geom="text", x=0, y=25, label="$$", color="green") +
annotate(geom="text", x=0, y=0, label="$ 0", color="green") +
annotate(geom="text", x=2, y=0, label="minutes\nof effort", size=3) +
annotate(geom="text", x=20, y=0, label="months\nof effort", size=3) +
annotate(geom="text",x=3, y=85, label="Little (or no) Planning\nHIGH COST", color="red") +
annotate(geom="text", x=18, y=85, label="Paralysis by Planning\nHIGH COST", color="red") +
geom_vline(xintercept=0, linetype="dotted") +
geom_hline(yintercept=0, linetype="dotted") +
geom_segment(data=d, mapping=aes(x=arrow.x, y=arrow.y, xend=arrow.x.end, yend=arrow.y.end),
arrow=arrow(), color="blue", size=2) +
annotate(geom="text", x=8, y=95, size=2.3, color="blue",
label="we prefer to be\non this side of the\nloss function") +
Now sometimes you need to make this investment! (Think nuclear power plants, or constructing aircraft carriers or submarines.) Don’t get caught up in getting your planning investment perfectly optimized — but do be aware of the trade-offs, and go into the decision deliberately, based on the risk level (and regulatory nature) of your industry, and your company’s risk appetite.
It can be difficult to focus on strategy when your organization has to comply with standards and regulations. Tracking and auditing can be tedious! If you’re a medical device manufacturer, you may need to maintain ISO 13485 compliance to participate in the supply chain. At the same time, you’ve got to meet all the requirements of 21 CFR 820. You’ve also got to remember other regulations that govern production and postmarket. (To read more about the challenges, check out Wienholt’s 2016 post.) There’s a lot to keep track of!
I have not shared all the commonalities of or differences between ISO 9001:2015 and the Baldrige Excellence Framework. Instead, I have tried to show the organizational possibilities of building on conformity assessment to establish a holistic approach for achieving excellence in every dimension of organizational performance today, with a look to the strategic imperatives and opportunities for the future. Baldrige helps an organization take this journey with a focus on process (55% of the scoring rubric) and results (45% of the rubric), recognizing that great processes are only valuable if they yield the complete set of results that lead to organizational sustainability… I encourage organizations that have not gone beyond conformity to take the next step in securing your future.