Shipulski On Design

Posts Tagged ‘Product Development Engine’

Efficient – How do we do more projects with fewer people?

Effective – Let’s choose the right project.

Would you rather do more projects that miss the mark or fewer that excite the customer?

Efficient – How do we finish the project faster?

Effective – Let’s fully staff the project.

Would you rather burn out the project team or deliver on what the customer wants?

Efficient – How do we reduce product cost by 5%?

Effective – Let’s make customers’ lives easier.

Would you rather reduce the cost or delight the customer?

Efficient – How can we go faster?

Effective – Let’s get it right.

Would you rather go fast and break things or get it right for the customer?

Efficient – How many projects can we run in parallel?

Effective – Let’s fully staff the most important projects.

Would you rather get halfway through four projects or complete two?

Efficient – How do we make progress on as many tasks as possible?

Effective – Let’s work on the critical path.

Would you rather work on things that don’t matter or nail the things that do?

Efficient – How can we complete the most tasks?

Effective – Let’s work on the hardest thing first.

Would you rather learn the whole thing won’t work before or after you waste time on the irrelevant?

If there’s a choice between efficiency and effectiveness, I choose effectiveness.

Image credit — Antarctica Bound

We wait because we don’t have enough information to make a decision.

We wait until the decision makes itself because no one wants to be wrong.

We wait for permission because of the negative consequences of being wrong.

We wait to use our judgment until we have evidence our judgment is right.

We wait for support resources because they are spread over too many projects.

We wait for a decision to be made because no one is sure who makes it.

We wait to reduce risk.

We wait to reduce costs.

We wait to move at the speed of trust.

We wait because too many people must agree.

We wait because disagreement comes too slowly.

We wait for disagreement because we don’t subscribe to “clear is kind.”

We wait when decisions are unmade.

We wait because there is insufficient courage to stop the bad projects.

We wait to stop things slowly.

We use waiting as a slow no.

We wait to reallocate resources because even bad projects have momentum.

We wait when we dislike the impending outcome.

We wait for the critical path.

We wait out of fear.

Image credit — Sylvia Sassen

Do the project right or do the right project – which would you choose?

If you improve time to market, the only thing that improves is time to market.  How do you feel about that?

Customers pay for things that make their lives easier.  Time to market doesn’t do that.

There’s no partial credit with new product development projects.  If the product isn’t 100% ready for sale, it’s 0% ready.

If you made 1/8^th progress on 8 projects, you made zero progress. But you did consume valuable resources.

If you made 100% progress on one project, you made progress.

When you have too many projects, you get too few done.

If you don’t know how many projects your company has, you have too many.

Would you rather choose the right project and run it inefficiently or choose the wrong project and run it efficiently?

When you choose the wrong project but run it efficiently, that’s called efficient ineffectiveness.

You can save several weeks making sure you choose the right project by starting the project too soon and running the wrong one for two years.

If your projects are slow, it’s likely the support functions are too highly utilized.  Add capacity to keep their peak utilization below 85%.

When shared resources are sized appropriately, they’re underutilized most of the time.  Think fire station and firefighters – when there’s a fire they respond quickly, and when there’s no fire they improve their skills so they can fight the next one better than the last.

If your projects are slow, check to see if you have resources on the critical path that work part-time.  Part-time resources support multiple projects and don’t work full-time on your project.  And you can’t control when they work on your project.  There’s no place for that on the critical path.

If you’re thinking about using part-time resources on the critical path, don’t.

Know where the novelty is and work that first.  And before you can work on the novelty you’ve got to know where it is.

You can have too little novelty, meaning the new product is so much like the old one there’s no need to launch it.  Mostly, though, projects have too much novelty.

If you are working on a clean-sheet design, there is no such thing.  There are no green-field projects.  All projects are brown-field projects. It’s just that some are browner than others.

Novelty generates problems and problems take three times longer to solve than anyone thinks.  To reduce the number of problems, declare as many as possible as annoyances.  Unlike problems, annoyances don’t have to be solved by the project.  Remember, it’s okay to save some work for the next project.

Even though you have a product development process, that process is powered by people.  People make it work and people make it not work.  If you get one thing right, get the people part right.

Image credit – claudia gabriela marques

What would happen if the factory had to support demand that increased one percent per week? Without incremental investment, how many weeks could they meet the ever-increasing demand?  That number is a measure of the system’s flexibility.  More weeks, more flexibility.  And the element of the manufacturing system that gives out first is the constraint.  So, now you know how much demand you can support before there’s a problem and you know what the problem will be.  And if you know the lead time to implement the improvement needed to support the increased demand, in a reverse-scheduling way, you know when to implement the improvement so it comes online when you need it.

What would happen if the factory had to support demand that increased one percent in a week?  How about two percent in a week, five percent, or ten percent?  Without incremental investment, what percentage increase could they support in a single week?  More percent increase, more flexibility.  And the element of the manufacturing system that gives out first is the constraint.  So, now you know how much increased demand you can support in a single week and you know the gating item that will block further increases.  You know now where to clip the increased demand and push the extra demand into the next week.  And you know the investment it would take to support a larger increase in a single week.

These two scenarios can be used to assess and quantify a process of any type.  For example, to understand the flexibility of the new product development process, load it (virtually) with more projects to see where it breaks.  Make a note of what it would take to increase the system’s flexibility and ask yourself if that’s a good investment.  If it is, make that investment.  If it isn’t, don’t.

This simple testing method is especially useful when the investment needed to increase flexibility has a long lead time or is expensive.  If your testing says the system can support five percent more demand before it breaks and you know that demand will hit the system in ten weeks, I hope the lead time to implement the needed improvement is less than ten weeks.  If not, you won’t be able to meet the increased demand.  And I hope the money to make the improvement is already budgeted because a budgeting cycle is certainly longer than ten weeks and you can’t buy what you need if the money isn’t in the budget.

The first question to ask yourself is what is the minimum flexibility of the system that will trigger the next investment to improve throughput and increase flexibility? And the follow-on question: What is needed to improve throughput? What is the lead time for that solution? How much will it cost? Is the money budgeted? And do we have the resources (people) that can implement the improvement when it’s time?

When the cost of not meeting demand is high, the value of this testing process is high. When the lead times for the improvements are long, this testing process has a lot of value because it gives you time to put the improvements in place.

Continuous improvement of process utilization is also a continuous reduction of process flexibility.  This simple testing approach can help identify when process flexibility is becoming dangerously low and give you the much-needed time to put improvements in place before it’s too late.

Image credit — Tambako The Jaguar

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

When there are too many projects, all the projects move too slowly.

When there are too many projects, adding resources doesn’t help much and may make things worse.

To speed up the important projects, stop the less important projects. There’s no better way.

When there are too many projects, stopping comes before starting.

All projects are important, it’s just that some are more important than others.  Stop the lesser ones.

When someone says all projects are equally important, they don’t understand projects.

If all projects are equally important, then they are also equally unimportant and it does not matter which projects are stopped.  This twist of thinking can help people choose the right projects to stop.

When there are too many projects, stop two before starting another.

Finishing a project is the best way to stop a project, but that takes too long.  Stop projects in their tracks.

There is no partial credit for a project that is 80% complete and blocking other projects.  It’s okay to stop the project so others can finish.

Queueing theory says wait times increase dramatically when utilization of shared resources reaches 85%.  The math says projects should be stopped well before shared resources are fully booked.

If you want to go faster, stop the lesser projects.

Image credit – Rodrigo Olivera

You can solve problems that reduce the material costs of your products.

You can solve problems that reduce the number of people that work at your company.

You can solve problems that save your company money.

You can solve problems that help your customers make progress.

You can solve problems that make it easier for your customers to buy from you.

You can solve too many small problems and too few big problems.

You can solve problems that ripple profits through your whole organization.

You can solve local problems.

You can solve problems that obsolete your best products.

You can solve problems that extend and defend your existing products.

You can solve problems that spawn new businesses.

You can solve the wrong problems.

You can solve problems before their time or after it is too late.

You can solve problems that change your company or block it from change.

You are defined by the problems you solve.  So, which type of problems do you solve and how do you feel about that?

Image credit – Maureen Barlin

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

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.

X: Of the pool of candidate new product development projects, which project should we do first?

Me: Let’s do the one that makes us the most money.

X: Which project will make the most money?

Me: The one where the most customers buy the new product, pay a reasonable price, and feel good doing it.

X: And which one is that?

Me: The one that solves the most significant problem.

X: Oh, I know our company’s most significant problem.  Let’s solve that one.

Me: No. Customers don’t care about our problems, they only care about their problems.

X: So, you’re saying we should solve the customers’ problem?

Me: Yes.

X: Are you sure?

Me: Yes.

X: We haven’t done that in the past. Why should we do it now?

Me: Have your previous projects generated revenue that met your expectations?

X: No, they’ve delivered less than we hoped.

Me: Well, that’s because there’s no place for hope in this game.

X: What do you mean?

Me: You can’t hope they’ll buy it.  You need to know the customers’ problems and solve them.

X: Are you always like this?

Me: Only when it comes to customers and their problems.

image credit: Kyle Pearce