Shipulski On Design

If you always want to be right, it’s time to ask new questions.

If you want to listen well, don’t talk.

If you want to start something new, stop something old.

If you want to do it again for the third time. give someone else a chance.

If you want it to be perfect, you don’t want to finish.

If you want to do something new, be unsure about what to do next.

If you want to hold tightly to things as they are, all you get are rope burns.

If you want to teach, find a student.

If you want someone’s trust, earn it.

If you want all the credit, you’re fast becoming a team of one.

If you want the Universe to change, don’t.

If you want to earn trust, tell the truth.

If you want good friends, be one.

Image credit — Sowhuan

If you want your new product development projects to go faster, reduce the number of active projects.  Full stop.

A rule to live by: If the new product development project is 90% complete, the company gets 0% of the value.  When it comes to new product development projects, there’s no partial credit.

Improving the capabilities of your project managers can help you go faster, but not if you have too many active projects.

If you want to improve the speed of decision-making around the projects, reduce the number of required decisions by reducing the number of active projects.

Resource conflicts increase radically as the number of active projects increases.  To fix this, you guessed it, reduce the number of active projects.

A project that is run under the radar is the worst type of active project. It sucks resources from the official projects and prevents truth telling because no one can admit the dark project exists.

With fewer active projects, resource intensity increases, the work is done faster, and the projects launch sooner.

Shared resources serve the projects better and faster when there are fewer active projects.

If you want to go faster, there’s no question about what you should do.  You should stop the lesser projects to accelerate the most important ones.  Full stop.

And if you want to stop some projects, I suggest you try to answer this question: Why does your company think it’s a good idea to have far too many active new product development projects?

Image credit — JOHN K THORNE

When there’s a disagreement, listen before you talk.  And if that doesn’t work, listen more. With this approach, disagreement cannot blossom into a problem.

When there’s a decision to be made, make it.  There are problems with any decision you make, and you might as well learn them as soon as you can.

When there’s a change coming, get people together and talk about what’s coming. One thing to remember – the talking you do before the change is much more meaningful than the talking after the change causes problems.

When an important project is behind schedule, pause the project.  Nothing causes dialog, problem-solving, and movement of resources like pausing an important project.

When person A says one thing to person B and another to person C, call a meeting with A, B, and C and within fifteen minutes the source of the problem will be apparent to all.

When someone doesn’t do what they said they’d do, send them an email asking when they’ll do it.  Then, at the same time every week, “reply all” to your email and ask them when they’ll do it.  That way, they get to see the ever-growing, time-stamped record of their problematic non-performance.

When there’s no owner of the problem, there can be no solution.  And that’s a big problem.

When it’s your problem, solve it.

When someone tries to give you their problem, don’t take it.  Like any gift, if you don’t accept it, the would-be giver still owns it.

When there are no problems, there can be no learning.

Image credit — Rob Oo

When you work in domains of high uncertainty, creating goals for the next year is exceptionally difficult.

When you try to do something that hasn’t been done before, things may blow up instantly, things may work out after two years of hard work, or things may never work.  So, how do you create the goal for that work? Do you give yourself one month to complete the work? And things haven’t worked out at the end of the month, do you stop the work or do you keep going?  If it blows up instantly, but you think you know why, do you keep going? Do you extend the due date for the goal?  At the start of the work, should the timeline have been set to one year instead of one month?  And who decides that?  And how do they decide?

When you have to create your goals for something that hasn’t been done before and the objectives of the work are defined by another team, yet that team hasn’t done the prework and cannot provide those objectives, what do you do? Do you create a goal for the other team to define the objectives? And what if you have no control over that team’s priorities and you don’t know when (or if) they’ll provide the needed information?  What does a goal look like when you don’t know the objectives of the work nor do you know when (or if) you’ll get that information.  Can you even create a goal for the work when you don’t know what that work is?  And how do you estimate a completion date or the resource requirements (both the flavor and quantity) when you don’t know the objectives?  What does that goal look like?

When you have to create your goals for a team of ten specialized people who each have unique skills, but you don’t know the objectives of the work, when that work can start, or when that work will finish, how do you cascade the team’s goals to each team members?  What do their goals look like?  Is the first goal to figure out the goal?  How many goals does it take to fill up their year when you don’t know what the work is or how long it will take?

When working in domains of high uncertainty, the goals go like this: define the system as it is, define something you want to improve, try to improve it, and then do the next right thing.  Unfortunately, that doesn’t fit well with the traditional process of setting yearly goals.

And your two questions should be: How do you decide what to improve? and How do you choose the next right thing?

Image credit — Rab Lawrence

Companies that are good at planning their projects create roadmaps spanning about three years, where individual projects are sequenced to create a coordinated set of projects that fit with each other.  The roadmap helps everyone know what’s important and helps the resources flow to those most important projects.

Through the planning process, the collection of potential projects is assessed and the best ones are elevated to the product roadmap.  And by best, I mean the projects that will generate the most incremental profit.  The projects on the roadmap generate the profits that underpin the company’s financial plan and the company is fanatically committed to the financial plan. The importance of these projects cannot be overstated.  And what that means is once a project makes it to the roadmap, there’s only one way to get it off the roadmap, and that’s to complete it successfully.

For the next three years, everyone knows what they’ll work on.  And they also know what they won’t work on.

The best companies want to be efficient so they staff their projects in a way that results in high utilization.  The most common way to do this is to load up the roadmap with too many projects and staff the projects with too few people.  The result is a significant fraction of people’s time (sometimes more than 100%) is pre-allocated to the projects on the roadmap.  The efficiency metrics look good and it may actually result in many successful launches.  But the downside of ultra-high utilization of resources is often forgotten.

When all your people are booked for the next three years on high-value projects, they cannot respond to new opportunities as they arise.  When someone comes back from a customer visit and says, “There’s an exciting new opportunity to grow the business significantly!” the best response is “We can’t do that because all our people are committed to the three-year plan.”.  The worst response is “Let’s put together a team to create a project plan and do the project.”.  With the first response, the project doesn’t get done and zero resources are wasted trying to figure out how to do the project without the needed resources.  With the second response, the project doesn’t get done but only after significant resources are wasted trying to figure out how to do the project without the needed resources.

Starting new projects is difficult because everyone is over-booked and over-committed on projects that the company thinks will generate significant (and predictable) profits.  What this means is to start a new project in this high-utilization environment, the new project must displace a project on the three-year plan.  And remember, the projects that must be displaced are the projects the company has chosen to generate the company’s future profits.  So, to become an active project (and make it to the three-year plan) the candidate project must be shown to create more profits, use fewer resources and launch sooner than the projects already on the three-year plan.  And this is taller than a tall order.

So, is there a solution?  Not really, because the only possible solution is to reduce resource utilization to create unallocated resources that can respond to emergent opportunities when they arise.  And that’s not possible because good companies have a deep and unskillful attachment efficiency.

Image credit — Bernard Spragg NZ

There are natural limits to the amount of work that any one person or group can do.  And once that limit is reached, saying yes to more work does not increase the amount of work that gets done.  Sure, you kick the can down the road when you say yes to work that you know you can’t get done, but that’s not helpful.  Expectations are set inappropriately which secures future disappointment and more importantly binds or blocks other resources. When preparatory work is done for something that was never going to happen, that prep work is pure waste.  And when resources are allocated to a future project that was never going to happen, the results are misalignment, mistiming, and replanning, and opportunity cost carries the day.

But how to know if you the team has what it takes to get the work done?  The answer is a capacity model.  There are many types of capacity models, but they all require a list of the available resources (people, tools, machines), the list of work to be done (projects), and the amount of time (in hours, weeks, months) each project requires for each resource.  The best place to start is to create a simple spreadsheet where the leftmost column lists the names of the people and the resources (e.g., labs, machines, computers, tools).  Across the top row of the spreadsheet enter the names of the projects.  For the first project, go down the list of people and resources,  and for each person/resource required for the project, type an X in the column.  Repeat the process for the remainder of the projects.

While this spreadsheet is not a formal capacity model, as it does not capture the number of hours each project requires from the resources, it’s plenty good enough to help you understand if you have a problem.  If a person has only one X in their row, only one project requires their time and they can work full-time on that project for the whole year.  If another person has sixteen Xs in their row, that’s a big problem. If a machine has no Xs in its row, no projects require that machine, and its capacity can be allocated to other projects across the company. And if a machine has twenty Xs in its row, that’s a big problem.

This simple spreadsheet gives a one-page, visual description of the team’s capacity.  Held at arm’s length, the patterns made by the Xs tell the whole story.

To take this spreadsheet to the next level, the Xs can be replaced with numbers that represent the number of weeks each project requires from the people and resources.  Sit down with each person and for each X in their row, ask them how many weeks each project will consume.  For example, if they are supposed to support three projects, X1 is replaced with 15 (weeks), X2 is replaced with 5, and X3 is replaced with 5 for a total of 25 weeks (15 + 5 + 5).  This means the person’s capacity is about 50% consumed (25 weeks / 50 weeks per year) by the three projects.  For each resource, ask the resource owner how much time each project requires from the resource.  For a machine that is needed for ten projects where each project requires twenty weeks, the machine does not have enough capacity to support the projects.  The calculation says the project load requires 200 machine-weeks (10*20 = 200 weeks) and four machines (200 machine-weeks / 50 weeks per year = 4 machines) are required.

Creating a spreadsheet that lists all the projects is helpful in its own right.  And you’ll probably learn that there are far more projects than anyone realizes.  (Helpful hint: make sure you ask three times if all the projects are listed on the spreadsheet.)  And asking people how much time is required for each project is respectful of their knowledge and skillful because they know best how long the work will take. They’ll feel good about all that.  And quantifying the number of weeks (or hours) each project requires elevates the discussion from argument to analysis.

With this simple capacity model, the team can communicate clearly which projects can be supported and which cannot.  And, where there’s a shortfall, the team can make a list of the additional resources that would be needed to support the full project load.

Fight the natural urge to overcomplicate the first version of the capacity model.  Start with a simple project-people/resource spreadsheet and use the Xs.  And use the conversations to figure out how to improve it for next time.

Defend – Protect your success in its current state.  In short, do what you did last time and do no harm.

Extend – Modify and adapt your success. In short, sell similar offerings to similar customers.

Transcend – Obsolete your best work before someone else does.

All three elements can be important to a company’s success and longevity, but it’s more important that the company’s resource allocation aligns with its priorities.  But how to tell if the company’s resource allocation matches its priorities?  Well, even though I was the one that asked it, I think that’s the wrong question because how a company allocates its resources DEFINES its priorities.  Though we don’t usually think of it that way, I think it’s a good way to think about it.  It’s a straightforward thing.  If it’s a priority, allocate the resources. If it’s not a priority, don’t allocate the resources. But there’s confusion when a company declares its priorities but those words contradict how resources are allocated.  Here are two rules to help navigate the confusion:

Rule 1. When there is a difference between how people spend their time and what the company says is a priority, company priorities are defined by how people spend their time.

Rule 2. When there is a difference between how the company spends its money (projects, investments, equipment, other) and what the company says is a priority, company priorities are defined by how the money is spent.

We’re all pretty clear on what the company says are the priorities, but how do you tell if the words are aligned with the actual priorities?  Well, measure how the resources are allocated – measure how you spend your time.

Open your calendar and move forward in time by one month and you will see a collection of standing meetings.  These are the meetings that are on the schedule and are the meetings that WILL happen.  Sure, there will be other meetings that come up, but the standing meetings, the regularly recurring meetings, are a good indicator of how you’ll spend your time.  For each meeting in week five, determine if the meeting is a defend, extend, or transcend meeting.  If the meeting agenda defines work that protects things as they are, that’s a Defend meeting.  If the meeting agenda defines work that modifies or adapts success, that’s an Extend meeting.  If the agenda defines work that obsoletes what’s been successful, that is a Transend meeting.  Categorize the meetings of week five and tally the hours.  Then, repeat for weeks six through eight.  You now have a good measure of your resource allocation and the company’s priorities.

If all the meetings are Defend meetings, the company’s priority is to defend what’s been successful.  This indicates the company’s priorities have a short-term bias.  If this is the case, I hope you have an unfair monopoly.  If not, you might consider adding some medium-term work to adapt and extend your success. If half the meetings are Defend meetings and the other half are Extend meetings, that’s a better balance between short-term and medium-term priorities.  But I hope there are no startups in your space because, without some Transcend work, one of them might soon eat your lunch.  If almost half are Defend, another almost half is Extend, and some are Transcend congratulations.  You have a reasonable balance of short and medium priorities and a splash of long-term priorities.  I’m not sure the balance is exactly right, but it’s at least a great start.

A similar characterization/quantification can be done for how the company spends its money.

Take a look at the open job requisitions on the company website.  Do those positions do work that defends, extends, or transcends?  Count them.  What does the data say?

Review and tally last year’s capital equipment purchases.  Did they defend, extend, or transcend? Do the same for this year’s capital budget.  How do you feel about all that?

Count the people who do projects to keep the production line running (defend), count the people who do new product development projects with the same DVP as last time (defend), who do new product development projects that adapt the DVP (extend) and who do technology development that builds on the DVP (extend) or decimates your best product (transcend).  What does the tally say?

Review this year’s training budget.  What are the relative fractions of extend, defend, and transcend?  Do you feel good about that?

There is no best ratio for defend, extend, and transcend.  What’s important, I think, is to be objective and clear about how the resources are allocated and to be open and honest about how all that aligns (or not) with the stated priorities.  And most important of all is what you do when there’s a mismatch between resource allocation and the stated priorities.

Image credit — Tommy Wong

It’s difficult to describe what an innovative company looks like, and there’s no singular recipe or direction that is right for all companies.  Here are some From: To: pairings that I hope will help you in your migration toward innovation.  You’re heading in the right direction as your company generates Tos and fewer Froms.

From:  No one is asking for that technology.

To:       What does this new technology stand for?

From:  How will the company benefit?

To:       How will the customer benefit?

From:  What’s the smallest improvement that will make a difference?

To:       How can we make the most significant difference?

From:  When will you be done?

To:       What will you learn?

From:  This might not work.

To:       How might this work?

From:  Start, Start, Continue.

To:       Stop, Start, Continue.

From: We’ve tried that before and it didn’t work.

To:      What’s changed since last time?

From:  What does perfect look like?

To:       How is the work done today and which elements can we improve?

From:  Defend and Defend the core.

To:       Extend and Defend the core.

From:  Define the idealized future state.

To:       Start with the work.

From:  That won’t work!

To:       Hey, watch this!

It’s easy to say yes to a project, and it’s difficult to say no.

When I say no to a great project, it preserves the opportunity to say yes to a magical one.

When in doubt, I say no to a project.

When I say no to a project, people notice.

When I say no to a project, I can give you a good reason.  And that reason shapes the selection of the next candidate projects.

When I say no to a project, but I can’t give you a good reason, I’m not doing my job.

When I say no to a project, it’s usually because there’s nothing in it for the customer.

When a project solves a problem for the company, it brings no top-line growth.  Just say no.

If the company benefits from the project, that benefit comes at the expense of the customer. Just say no.

If the customer doesn’t benefit, I say no to the project.

When I say no to a project, people know it’s because I care about the customer.

If there’s disagreement around how the customer will benefit, it’s because the customer benefit is insignificant. I say no and choose a project where the customer benefit is massive.

If you want to judge me, judge me on the projects I say no to.

If you want to help someone grow, use the work.  Put them on mission-critical work that gives them the opportunity to demonstrate next-level skills.  And the work must fit the person – it can’t be too difficult or too easy.  It must be just right.   And don’t create new work. Instead, for the company’s most important projects, identify the critical path work that is vital to the projects’ success and assign them to the work.

Rule 1: A personal development plan must be made from real work.

People don’t develop skills when they talk about the work, they develop skills when they do the work.  But if the work isn’t new, they don’t develop new skills.  And if the work is too difficult, they don’t develop new skills.  The role of the leader is to define work that stretches the individual without pulling them apart.  To do this, the leader must select the work appropriately and pay attention as the work proceeds.  When the going gets rough, the leader shows them how it’s done and then lets them do the work in a supervised way.  The leader does it right when it can be done independently after the work is done with supervision.

Rule 2: A personal development plan is only as good as the leader’s involvement.

There’s great pressure to create personal development plans for everyone.  It’s a good idea in principle, but in practice, it’s not effective.  Good personal development plans are resource intensive.  Even before the work starts, the planning and coordination require significant resources.  And once the plan is up and running, the company’s best talent is applied to the best (and most important) work and the best leaders must stay close to the work for the duration.  The level of commitment is significant to design and manage a good personal development plan and this limits the number of development plans that can be done well.

Rule 3: Fewer personal development plans create more personal development.

Just before it’s possible, it’s impossible.

An instant before you know how to do it, you don’t.

After searching for the answer for a year, you may find it in the next instant.

If you stop searching, that’s the only way to guarantee you won’t find it.

When people say it won’t work, their opinion is valid only if nothing has changed since the last time, including the people and their approach.

If you know it won’t work, change the approach, the specification, or the scope.

If you think it won’t work, that’s another way of saying “it might work “.

If you think it might work, that’s another way of saying “it might not work”.

When there’s a difference of opinion, that’s objective evidence the work is new.

If everyone sees it the same way, you’re not trying hard enough.

When you can’t predict the project’s completion date, that’s objective evidence that the work is new.

If you know when the project will be done, the novelty has been wrestled out of the project or there was none at the start.

When you don’t start with the most challenging element of the project, you cause your company to spend a lot of money on a potentially nonviable project.

Until the novel elements of a project are demonstrated, there is no real progress.

“Jumping Backwards – Cape Verde, Sal Rei” by Espen Faugstad is licensed under CC BY 2.0.