Archive for the ‘Decisions’ Category

Did you do anything different today?

In that familiar situation, how did you respond in an unfamiliar way?

Instead of your usual yes, did you say no?

With your regular chair available in the conference room, why not sit in a different one?

Instead of using your right hand to brush your teeth, why not try your left? How would it feel?

When someone misbehaved in a meeting, how did you respond? Or did you?

If no one recognized your different behavior, was it different enough? Why not rerun the experiment?

With the same choices on the menu, what’s in the way of asking for a special order?

Instead of going to the meeting, did you ask someone to go in your place as a growth opportunity?

When you pay attention, you notice more opportunities to demonstrate novelty. Do you pay attention?

If it didn’t create a sensation in your body, did you do anything novel?

When you saw someone respond differently, did they like it when you praised their behavior?

When you have a chance to help someone be successful, why not help them?

When you have the chance to make a different choice, why not make it?

When you have a chance to respond differently, why not do it?

When you have a chance to feel uncomfortable, why not feel it?

One more question for you — What novelty did you demonstrate today?

Image credit — Mike Beales

When in doubt, look inside.

When we quiet our minds, we can hear our bodies’ old stories in the form of our thoughts.

Pay attention to our bodies and we understand our minds.

Our bodies give answers before our minds know the questions.

If we don’t understand our actions, it’s because our bodies called the ball.

The physical sensations in our bodies are trailheads for self-understanding.

Our bodies’ old stories govern our future actions.

If a cat sits on a hot stove, that cat won’t sit on a hot stove again. That cat won’t sit on a cold stove either.  Our bodies are just like the cat.

Our mouths sing the songs but our bodies write the sheet music.

Our bodies make decisions and then our minds declare ownership.

When we’re reactive, it’s because our bodies recognize the context and trigger the old response.

When a smell triggers a strong memory, that’s our body at work.

Bessel was right. The body keeps the score.

 

Image credit — Raul AB

Function first, no exceptions.

Before a design can be accused of having too much material and labor costs, it must be able to meet its functional specifications.  Before that is accomplished, it’s likely there’s not enough material and labor in the design and more must be added to meet the functional specifications.  In that way, it likely doesn’t cost enough.  If the cost is right but the design doesn’t work, you don’t have a viable offering.

Before the low-cost manufacturing process can be chosen, the design must be able to do what customers need it to do.  If the design does not yet meet its functional specification, it will change and evolve until it can.  And once that is accomplished, low-cost manufacturing processes can be selected that fit with the design.  Sure, the design might be able to be subtly adapted to fit the manufacturing process, but only as much as it preserves the design’s ability to meet its functional requirements. If you have a low-cost manufacturing process but the design doesn’t meet the specifications, you don’t have anything to sell.

Before a product can function robustly over a wide range of operating conditions, the prototype design must be able to meet the functional requirements at nominal operating conditions.  If you’re trying to improve robustness before it has worked the first time, your work is out of sequence.

Before you can predict when the project will be completed, the design must be able to meet its functional requirements.  Before that, there’s no way to predict when the product will launch. If you advertise the project completion date before the design is able to meet the functional requirements, you’re guessing on the date.

When your existing customers buy an upgrade package, it’s because the upgrade functions better.  If the upgrade didn’t work better, customers wouldn’t buy it.

When your existing customers replace the old product they bought from you with the new one you just launched, it’s because the new one works better.  If the new one didn’t work better, customers wouldn’t buy it.

Function first, no exceptions.

Image credit — Mrs Airwolfhound

How To Finish Projects

Finishing a project is usually associated with completing all the deliverables.  But in the real world there are other flavors of finishing that come when there is no reason or ability to complete all the deliverables or completing them will take too long.

Everyone’s favorite flavor of finishing is when all the deliverables are delivered and sales of the new product are more than anticipated.  Finishing this way is good for your career.  Finish this way if you can.

When most of the deliverables are met, but some of them aren’t met at the levels defined by the specification, the specification can be reduced to match the actual performance and the project can be finished.  This is the right thing to do when the shortfall against the specification is minor and the product will still be well received by customers.  In this case, it makes no sense to hold up the launch for a minor shortfall. There is no shame here.  It’s time to finish and make money.

After working on the project for longer than planned and the deliverables aren’t met, it’s time to finish the project by stopping it.  Though this type of finishing is emotionally difficult, finishing by stopping is far better than continuing to spend resources on a project that will likely never amount to anything.  Think opportunity cost.  If allocating resources to the project won’t translate into customer value and cash, it’s better to finish now so you can allocate the resources to a project that has a better chance of delivering value to you and your customers.

Before a project is started in earnest and the business case doesn’t make sense, or the commercial risk is too high, or the technical risk is too significant, or it’s understaffed, finish the project by not starting it. This is probably the most important type of finishing you can do.  Again, think of opportunity cost.  By finishing early (before starting) resources can start a new project almost immediately and resources were prevented from working on a project that wasn’t going to deliver value.

Just as we choose the right way to start projects and the right way to run them, we must choose the right way to finish them.

Image credit — majiedqasem

Do you create the conditions for decisions to be made without you?

What does your team do when you’re not there?  Do they make decisions or wait for you to come back so you can make them?

If your team makes an important decision while you’re out of the office, do you support or criticize them? Which response helps them stand taller? Which is most beneficial to the longevity of the company?

If other teams see your team make decisions while you are on vacation, doesn’t that make it easier for those other teams to use their good judgment when their leader is on vacation?

If a team waits for their leader to return before making a decision, doesn’t that slow progress?  Isn’t progress what companies are all about?

When you’re not in the office, does the organization reach out directly to your team directly? Or do they wait until they can ask your permission?  If they don’t reach out directly, isn’t that a reflection on you as the leader? Is your leadership helping or hindering progress?  How about the professional growth of your team members?

Does your team know you want them to make decisions and use their best judgment? If not, tell them.  Does the company know you want them to reach out directly to the subject matter experts on your team? If not, tell them.

If you want your company to make progress, create the causes and conditions for good decisions to be made without you.

Image credit – Conall

It’s good to have experience, until the fundamentals change.

We use our previous experiences as context for decisions we make in the present.  When we have a bad experience, the experience-context pair gets stored away in our memory so that we can avoid a similar bad outcome when a similar context arises.  And when we have a good experience, or we’re successful, that memory-context pair gets stored away for future reuse. This reuse approach saves time and energy and, most of the time keeps us safe.  It’s nature’s way of helping us do more of what works and less of what doesn’t.

The system works well when we correctly match the historical context with today’s context and the system’s fundamentals remain unchanged.  There are two potential failure modes here.  The first is when we mistakenly map the context of today’s situation with a memory-context pair that does not apply.  With this, we misapply our experience-based knowledge in a context that demands different knowledge and different decisions.  The second (and more dangerous) failure mode is when we correctly identify the match between past and current contexts but the rules that underpin the context have changed.  Here, we feel good that we know how things will turn out, and, at the same time, we’re oblivious to the reality that our experience-based knowledge is out of date.

“If a cat sits on a hot stove, that cat won’t sit on a hot stove again. That cat won’t sit on a cold stove either. That cat just don’t like stoves.”  Mark Twain

If you tried something ten years ago and it failed, it’s possible that the underpinning technology has changed and it’s time to give it another try.

If you’ve been successful doing the same thing over the last ten years, it’s possible that the underpinning business model has changed and it’s time to give a different one a try.

Hissing cat” by Consumerist Dot Com is licensed under CC BY 2.0.

When You Don’t Know What To Do…

When you don’t know what to do, what do you do?  This is a difficult question.

Here are some thoughts that may help you figure out what to do when you really don’t know.

Don’t confuse activity with progress.

Gather your two best friends, go off-site, and define the system as it is.

Don’t ask everyone what they think because the Collective’s thoughts will be diffuse, bland, and tired.

Get outside.

Draw a picture of how things work today.

Get a good meal.

Make a graph of goodness over time.  If it’s still increasing, do more of what you did last time.  If it’s flat, do something else.

Get some exercise.

Don’t judge yourself negatively.  This is difficult work.

Get some sleep.

Help someone with their problem.  The distraction will keep you out of the way as your mind works on it for you.

Spend time with friends.

Try a new idea at the smallest scale. It will likely lead to a better one. Repeat.

Use your best judgment.

Image credit – Andrew Gustar

Things I Sometimes Forget

Clean-sheet designs are fun, right up until they don’t launch.

When you feel the urge to do a clean-sheet design, go home early.

When you don’t know how to make it better, make it worse and do the opposite.

Without trying, there is no way to know if it will work.

Trying sometimes feels like dying.

But without trying, nothing changes.

Agreement is important, but only after the critical decision has been made.

When there’s 100% agreement, you waited too long to make the decision.

When it’s unclear who the customer is, ask “Whose problem will be solved?”

When the value proposition is unclear, ask ‘What problem will be solved?”

When your technology becomes mature, no one wants to believe it.

When everyone believes the technology is mature, you should have started working on the new technology four years ago.

If your projects are slow, blame your decision-making processes.

Two of the most important decisions: which projects to start and which to stop.

All the action happens at the interfaces, but that’s also where two spans of control come together and chafe.

If you want to understand your silos and why they don’t play nicely together, look at the organizational chart.

When a company starts up, the product sets the organizational structure.

Then, once a company is mature, the organizational structure constrains the product.

At the early stages of a project, there’s a lot of uncertainty.

And once the project is complete, there’s a lot of uncertainty.

Toys Never Forget” by Alyssa L. Miller is marked with CC BY 2.0.

Trust-Based Disagreement

When there’s disagreement between words and behavior, believe the behavior.  This is especially true when the words deny the behavior.

When there’s disagreement between the data and the decision, the data is innocent.

When there’s agreement that there’s insufficient data but a decision must be made, there should be no disagreement that the decision is judgment-based.

When there’s disagreement on the fact that there’s no data to support the decision, that’s a problem.

When there’s disagreement on the path forward, it’s helpful to have agreement on the process to decide.

When there’s disagreement among professionals, there is no place for argument.

When there’s disagreement, there is respect for the individual and a healthy disrespect for the ideas.

When there’s disagreement, the decisions are better.

When there’s disagreement, there’s independent thinking.

When there’s disagreement, there is learning.

When there’s disagreement, there is vulnerability.

When there’s disagreement, there is courage.

When there’s disagreement, there is trust.

“Teamwork” by davis.steve32 is licensed under CC BY 2.0

Learn to Recognize Waiting

If you want to do a task, but you don’t have what you need, that’s waiting for a support resource. If you need a tool, but you don’t have it, you wait for a tool. If you need someone to do the task, but you don’t have anyone, you wait for people. If you need some information to make a decision, but you don’t have it, you wait for information.

If a tool is expensive, usually you have to wait for it. The thinking goes like this – the tool is expensive, so let’s share the cost over too many projects and too many teams. Sure, less work will get done, but when we run the numbers, the tool will look less expensive because it’s used by many people.  If you see a long line of people (waiting) or a signup list (people waiting at their desks), what they are waiting for is usually an expensive tool or resource. In that way, to find the cause of waiting, stand at the front of the line and look around. What you see is the cause of the waiting.

If the tool isn’t expensive, buy another one and reduce the waiting. If the tool is expensive, calculate the cost of delay.  Cost of delay is commonly used with product development projects. If the project is delayed by a month, the incremental revenue from the product launch is also delayed by a month.  That incremental revenue is the cost of delaying the project by a month. When the cost of delay is larger than the cost of an expensive tool, it makes sense to buy another expensive tool. But, to purchase that expensive tool requires multiple levels of approvals.  So, the waiting caused by the tool results in waiting for approval for the new tool. I guess there’s a cost of delay for the approval process, but let’s not go there.

Most companies have more projects than people, and that’s why projects wait. And when projects wait, projects are late. Adding people is like getting another expensive tool.  They are spread over too many projects, and too little gets done. And like with expensive tools, getting more people doesn’t come easy. New hires can be justified (more waiting in the approval queue), but that takes time to find them, hire them, and train them. Hiring temporary people is a good option, though that can seem too expensive (higher hourly rate), it requires approval, and it takes time to train them.  Moving people from one project to another is often the best way because it’s quick and the training requirement is less.  But, when one project gains a person, another project loses one. And that’s often the rub.

When it’s time to make an important decision and the team has to wait for missing information, the project waits. And when projects wait, projects are late. It’s difficult to see the waiting caused by missing or uncommunicated information, but it can be done. The easiest to see when the information itself is a project deliverable. If a milestone review requires a formal presentation of the information, the review cannot be held without it. The delay of the milestone review (waiting) is objective evidence of missing information.

Information-based waiting is relatively easy to see when the missing information violates a precedent for decision making.  For example, if the decision is always made with a defined set of data or information, and that information is missing, the precedent is violated and everyone knows the decision cannot be made. In this case, everyone’s clear why the decision cannot be made, everyone’s clear on what information is missing, and everyone’s clear on who dropped the ball.

It’s most difficult to recognize information-based waiting when the decision is new or different and requires judgment because there’s no requirement for the data and there’s no precedent to fall back on. If the information was formally requested and linked to the decision, it’s clear the information is missing and the decision will be delayed.  But if it’s a new situation and there’s no agreement on what information is required for the decision, it’s almost impossible to discern if the information is missing. In this situation, it comes down to trust in the decision-maker. If you trust the decision-maker and they say there’s information missing, then there’s information missing. If you trust the decision-maker and they say there’s no information missing, they should make the decision. But if you don’t trust the decision-maker, then all bets are off.

In general, waiting is bad.  And it’s helpful if you can recognize when projects are waiting. Waiting is especially bad went the delayed task is on the critical path because when the project is waiting on a task that’s on the critical path, there’s a day-for-day slip in the completion date.  Hint: it’s important to know which tasks and decisions are on the critical path.

Image credit — Tomasz Baranowski

Uncertainty Isn’t All Bad

If you think you understand what your customers want, you don’t.

If you’re developing a new product for new customers, you know less.

If you’re developing a new technology for a new product for new customers, you know even less.

If you think you know how much growth a new product will deliver, you don’t.

If that new product will serve new customers, you know less.

If that new product will require a new technology, you know even less.

If you have to choose between project A and B, you’ll choose the one that’s most like what you did last time.

If project A will change the game and B will grow sales by 5%, you’ll play the game you played last time.

If project A and B will serve new customers, you’ll change one of them to serve existing customers and do that one.

If you think you know how the market will respond to a new product, it won’t make much of a difference.

If you don’t know how the market will respond, you may be onto something.

If you don’t know which market the product will serve, there’s a chance to create a whole new one.

If you know how the market will respond, do something else.

When we have a choice between certainty and upside, the choice is certain.

When we choose certainty over upside, we forget that the up-starts will choose differently.

When we have a lot to lose, we chose certainty.

And once it’s lost, we start over and choose uncertainty.

Image credit — Alexandra E Rust

 

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives