Shipulski On Design

Archive for the ‘Fundementals’ Category

X: When will you be done with the project?

Me: This work has never been done before, so I don’t know.

 

X: But the Leadership Team just asked me when the project will be done. So, what should I say?

Me: Since nothing has changed since the last time you asked me, I still don’t know. Tell them I don’t know.

 

X: They won’t like that answer.

Me: They may not like the answer, but it’s the truth.  And I like telling the truth.

 

X: Well, what are the steps you’ll take to complete the project?

Me: All I can tell you is what we’re trying to learn right now.

 

X: So all you can tell me is the work you’re doing right now?

Me: Yes.

 

X: It seems like you don’t know what you’re doing.

Me: I know what we’re doing right now.

 

X: But you don’t know what’s next?

Me: How could I?  If this current experiment goes up in smoke, the next thing we’ll do is start a different project.  And if the experiment works, we’ll do the next right thing.

 

X: So the project could end tomorrow?

Me: That’s right.

 

X: Or it could go on for a long time?

Me: That’s right too.

 

X: Are you always like this?

Me: Yes, I am always truthful.

 

X: I don’t like your answers. Maybe we should find someone else to run the project.

Me: That’s up to you.  But if the new person tells you they know when the project will be done, they’re the wrong person to run the project.  Any date they give you will be a guess.  And I would not want to be the one to deliver a date like that to the Leadership Team.

 

X: We planned for the project to be done by the end of the year with incremental revenue starting in the first quarter of next year.

Me: Well, the project work is not bound by the revenue plan.  It’s the other way around.

 

X: So, you don’t care about the profitability of the company?

Me: Of course I care.  That’s why we chose this project – to provide novel customer value and sell more products.

 

X: So the project is intended to deliver new value to our customers?

Me: Yes, that’s how the project was justified.  We started with an important problem that, if solved, would make them more profitable.

 

X: So you’re not just playing around in the lab.

Me: No, we’re trying to solve a customer problem as fast as we can.  It only looks like we’re playing around.

 

X: If it works, would our company be more profitable?

Me: Absolutely.

 

X: Well, how can I help?

Me: Please meet with the Leadership Team and thank them for trusting us with this important project.  And tell them we’re working as fast as we can.

Image credit – Florida Fish and Wildlife

X:  Me:  format stolen from Simon Wardley (@swardley).  Thank you, Simon.

What could we change to become happier? 

Happiness comes when our reality (how things really are) compares favorably with our expectations. If happiness comes from the comparison between how things are and our expectations, wouldn’t we be happier with any outcome if we change our expectations of the outcome? But how are expectations defined? What makes an expectation an expectation?  Where do our expectations come from?

If we expect to have no control over the outcome, wouldn’t we be happier with any outcome?  Aren’t we the ones who set our expectations? And hasn’t the Universe told us multiple times we don’t have control? If so, what’s in the way of giving up our expectations of control? What’s in the way of letting go?

What could we change to become more thankful?

Thankfulness comes when our reality, what we see or recognize, compares favorably with how we think things should be. If thankfulness comes from the comparison between what is and what should be, what if we changed our shoulds?  Wouldn’t we be more thankful if we lessened our shoulds and reality compared more favorably? But how are shoulds defined?  What makes a should a should? Where do our shoulds come from?

If we can help ourselves believe we don’t have control over how things should be, wouldn’t we be more thankful for how things are? And aren’t we the setters of our shoulds? And hasn’t the Universe often told us our shoulds have no control over it? If so, what’s in the way of giving up the belief that our shoulds have control over anything? What’s in the way of letting go?

Shoulds and expectations are close cousins and both influence our happiness and ability to be thankful.

At this Thanksgiving holiday, may we be aware of our shoulds and enjoy our friends and family as they are. May we be aware of our expectations and enjoy the venue, the food, the weather, and the conversations as they are. May we suspend our natural desire to control things and be happy and thankful for things as they are.

And may we love ourselves as we are.

Happy Thanksgiving.

Mike

 

Image credit — Bennilover

I was invited to an important meeting.  Here’s how it went.

I was invited to an important meeting.  I want you to attend with me.

I was invited to an important meeting with my boss.  Will you join me?

I was invited to an important meeting but I cannot attend.  Will you go in my place?

I was invited to an important meeting but the company will be better served if you attend.

I heard you were invited to the meeting instead of me.  I think that’s great.

Here’s a presentation I put together.  I want to explain it to you.

Here’s a presentation I put together.  What does it say to you?

Here’s a presentation I put together.  What’s missing?

I want you to create a draft of a presentation which we’ll review together.

I want you to create the presentation.  I’ll review it if you want.

I want you to create the presentation and deliver it.

I heard you helped someone create an interesting presentation and it went over well.  I’m happy you did that.

This is the situation and this is what I want you to do.

This is the situation and this is what I think we should do.  What do you think?

This is the situation. What do you think we should do?

This is the situation.  What are you going to do?

What’s the situation?

What’s the situation and what will you do?

What was the situation and what did you do?

I heard you helped someone with their situation.  That made me smile.

Image credit — Bastian_Schmidt

When you are stuck, often the problems you can describe are not the problems that are in the way.

The problems you solved last time make it more difficult to see new problems this time.

The problems you know of are not the problem.

When you have no problems, you have big problems.

When you have no problem, there is no way to justify additional resources.

When you have no problem, you better finish on time.

When you’re stuck on a problem, make it worse and solve it by doing the opposite.

Problems are not bad, even though bringing them to everyone’s attention may be bad for your career.

And if talking about problems is bad for your career, you are working at the wrong company.

Until you can explain the problem in plain language, you do not understand it.

And when you do not understand a problem, you can’t solve it.

Solutions start with a problem.

Two questions to ask: Where is the problem and when does it occur?

Problems are solved with microscopes and not telescopes. Get close to the problem.

Your problem is not new.  Someone has solved it in a different application, context, or product.

There are at least three ways to solve a problem: before it occurs, while it occurs, or after it occurs,

Sometimes solving a difficult problem requires the generation of an easily solvable problem. So be it.

Problems are more powerful than opportunities.  Call them by their name.

Because without problems, there can be no solutions.

Image credit – Andy Morffew

Whatever business you’re in, you’re in the people business.

Scan your organization for single-point failure modes, where if one person leaves the wheels would fall off.  For the single-point failure mode, move a new person into the role and have the replaced person teach their replacement how to do the job.  Transfer the knowledge before the knowledge walks out the door.

Scan your organization for people who you think can grow into a role at least two levels above their existing level.  Move them up one level now, sooner than they and the organization think they’re ready.  And support them with a trio of senior leaders.  Error on the side of moving up too few people and providing too many supporting resources.

Scan your organization for people who exert tight control on their team and horde all the sizzle for themselves.  Help these people work for a different company. Don’t wait. Do it now or your best young talent will suffocate and leave the company.

Scan your organization for people who are in positions that don’t fit them and move them to a position that does.  They will blossom and others will see it, which will make it safer and easier for others to move to positions that fit them.  Soon enough, almost everyone will have something that fits them.  And remember, sometimes the position that fits them is with another company.

Scan your organization for the people who work in the background to make things happen. You know who I’m talking about.  They’re the people who create the conditions for the right decisions to emerge, who find the young talent and develop them through the normal course of work, who know how to move the right resources to the important projects without the formal authority to do so, who bring the bad news to the powerful so the worthy but struggling projects get additional attention and the unworthy projects get stopped in their tracks, who bring new practices to new situations but do it through others, who provide air cover so the most talented people can do the work everyone else is afraid to try, who overtly use their judgment so others can learn how to use theirs, and who do the right work the right way even when it comes at their own expense.  Leave these people alone.

When you take care of the people part of the business, all the other parts will take care of themselves.

Image credit – are you my rik?

If you see something that matters, say something.

If you say something and nothing happens, you have a choice – bring it up again, do something, or let it go.

Bring it up again when you think your idea was not understood. And if it’s still not understood after the second try, bring it up a third time.  After three unsuccessful tries, stop bringing it up.

Now your choice is to do something or let it go.

Do something to help people see your idea differently.  If it’s a product or technology, build a prototype and show people.  This makes the concept more real and facilitates discussion that leads to new understanding and perspectives.  If it’s a new value proposition, create a one-page sales tool that defines the new value from the customers’ perspective and show it to several customers.  Make videos of the customers’ reactions and show them to people that matter. The videos let others experience the customers’ reactions first-hand and first-hand customer feedback makes a difference. If is a new solution to a problem, make a prototype of the solution and show it to people that have the problem.  People with problems react well to solutions that solve them.

When people see you invest time to make a prototype or show a concept to customers, they take you and your concept more seriously.

If there’s no real traction after several rounds of doing something, let it go. Letting it go releases you from the idea and enables you to move on to something better.  Letting it go allows you to move on.  Don’t confuse letting it go with doing nothing.  Letting it go is an action that is done overtly.

The number of times to bring things up is up to you.  The number of prototypes to build is up to you.  And the sequence is up to you.  Sometimes it’s right to forgo prototypes and customer visits altogether and simply let it go.

But don’t worry.  Because it matters to you, you’ll figure out the best way to move it forward.  Follow your instincts and don’t look back.

Image credit – Peter Addor

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

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

If you give a person the tools, time, and training, you’ve empowered them.  They know what to do, they have supporting materials, and they have the permission to spend the time they need to get it done.

If you give a person the tools and the time but not the training, they will struggle to figure out the tools but they’ll likely get there in the end.  It won’t be all that efficient, but because you’ve given them the time they’ll be able to figure out the tools and get it done.

If you give a person the time but not the tools or the training, they’ll go on a random walk and make no progress.  Yes, you’ve given them the time, but you’ve given them no real support or guidance.  They’ll likely become tired and frustrated and you’ll have allocated their time yet made no progress.

If you give a person the tools and training but not the time, you’ve demoralized them.  They have new skills and new tools and want to use them, but they’re too busy doing their day job.  This is the opposite of empowerment.

If you’re not willing to give people the time to do new work, don’t bother providing new tools, and don’t bother training them.  Stay the course and accept things as they are.  Otherwise, you’ll disempower your best people.

But if you want to empower people, give them all three – tools, time, and training.

Image credit — Paul Balfe

When planning the projects for next year, how do you decide which projects are a go and which are a no?  One straightforward way is to say yes to projects when there are resources lined up to get them done and no to all others.  Sure, the projects must have a good return on investment but we’re pretty good at that part.  But we’re not good at saying no to projects based on real resource constraints – our people and our budgets.

It’s likely your big projects are well-defined and well-staffed.  The problem with these projects is usually the project timeline is disrespectful of the work content and the timeline is overly optimistic.  If the project timeline is shorter than that of a previously completed project of a similar flavor, with a similar level of novelty and similar resource loading, the timeline is overly optimistic and the project will be late.

Project delays in the big projects block shared resources from moving onto other projects within the appropriate time window which cascades delays into those other projects.  And the project resources themselves must stay on the big projects longer than planned (we knew this would happen even before the project started) which blocks the next project from starting on time and generates a second set of delays that rumble through the project portfolio.  But the big projects aren’t the worst delay-generating culprits.

The corporate initiatives and infrastructure projects are usually well-staffed with centralized resources but these projects require significant work from the business units and is an incremental demand for them.  And the only place the business units can get the resources is to pull them off the (too many) big projects they’ve already committed to.  And remember, the timelines for those projects are overly optimistic.  The big projects that were already late before the corporate initiatives and infrastructure projects are slathered on top of them are now later.

Then there are small projects that don’t look like they’ll take long to complete, but they do.  And though the project plan does not call for support resources (hey, this is a small project you know), support resources are needed.  These small projects drain resources from the big projects and the support resources they need.  Delay on delay on delay.

Coming out of the planning process, all teams are over-booked with too many projects, too few resources, and timelines that are too short. And then the real fun begins.

Over the course of the year, new projects arise and are started even though there are already too few resources to deliver on the existing projects.  Here’s a rule no one follows:  If the teams are fully-loaded, new projects cannot start before old ones finish.

It makes less than no sense to start projects when resources are already triple-double booked on existing projects.  This behavior has all the downside of starting a project (consumption of resources) with none of the upside (progress).  And there’s another significant downside that most don’t see.   The inappropriate “starting” of the new project allows the company to tell itself that progress is being made when it isn’t.  All that happens is existing projects are further starved for resources and the slow pace of progress is slowed further.

It’s bad form to play Tetris with your project portfolio.

Running too many projects in parallel is not faster.  In fact, it’s far slower than matching the projects to the resources on-hand to do them.  It’s essential to keep in mind that there is no partial credit for starting a project.  There is 100% credit for finishing a project and 0% credit for starting and running a project.

With projects, there are two simple rules.  1) Limit the number of projects by the available resources.  2) Finish a project before starting one.

Image credit – gerlos

Life can get busy and complicated, with too many demands on our time and too little time to get everything done.  But why do we accept all the “demands” and why do we think we have to get everything done? If it’s not the most important thing, isn’t a “demand for our time” something less than a demand? And if some things are not all that important, doesn’t it say we don’t have to do everything?

When life gets busy, it’s difficult to remember it’s our right to choose which things are important enough to take on and which are not.  Yes, there are negative consequences of saying no to things, but there are also negative consequences of saying yes.  How might we remember the negative consequences of yes?

When you say to yes to one thing, you say no to the opportunity to do something else.  Though real, this opportunity cost is mostly invisible.  And that’s the problem.  If your day is 100% full of meetings, there is no opportunity for you to do something that’s not on your calendar.  And in that moment, it’s easy to see the opportunity cost of your previous decisions, but that doesn’t do you any good because the time to see the opportunity cost was when you had the choice between yes and no.

If you say yes because you are worried about what people will think if you say no, doesn’t that say what people think about you is important to you? If you say yes because your physical health will improve (exercise), doesn’t that say your health is important to you? If you say yes to doing the work of two people, doesn’t it say spending time with your family is less important?

Here’s a proposed system to help you.  Open your work calendar and move one month into the future.  Create a one-hour recurring meeting with yourself.  You just created a timeslot where you said no in the future to unimportant things and said yes in the future to important things.  Now, make a list of three important things you want to do during those times.  And after one month of this, create a second one-hour recurring meeting with yourself.  Now you have two hours per week where you can prioritize things that are important to you.  Repeat this process until you have allocated four hours per week to do the most important things.  You and stop at four hours or keep going.  You’ll know when you get the balance right.

And for Saturday and Sunday, book a meeting with yourself where you will do something enjoyable.  You can certainly invite family and/or friends, but it the activity must be for pure enjoyment.  You can start small with a one-hour event on Saturday and another on Sunday.  And, over the weeks, you can increase the number and duration of the meetings.

Saying yes in the future to something important is a skillful way to say no in the future to something less important.  And as you use the system, you will become more aware of the opportunity cost that comes from saying yes.

Image credit – Gilles Gonthier