Shipulski On Design

Posts Tagged ‘Product Development Engine’

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

Choose the right project. When you say yes to a new project, all the focus is on the incremental revenue the project will generate and none of the focus is on unrealized incremental revenue from the projects you said no to. Next time there’s a proposal to start a new project, ask the team to describe the two or three most compelling projects that they are asking the company to say no to.  Grounding the go/no-go decision within the context of the most compelling projects will help you avoid the real backbreaker where you consume all your product development resources on something that scratches the wrong itch while you prevent those resources from creating something magical.

Choose what to improve. Give your customers more of what you gave them last time unless what you gave them last time is good enough. Once goodness is good enough, giving customers more is bad business because your costs increase but their willingness to pay does not.  Once your offering meets the customers’ needs in one area, lock it down and improve a different area.

Choose how to staff the projects.  There is a strong temptation to run many projects in parallel.  It’s almost like our objective is to maximize the number of active projects at the expense of completing them.  Here’s the thing about projects – there is no partial credit for partially completed projects.  Eight active projects that are eight (or eighty) percent complete generate zero revenue and have zero commercial value.  For your most important project, staff it fully.  Add resources until adding more resources would slow the project.  Then, for your next most important project, repeat the process with your remaining resources.  And once a project is completed, add those resources to the pool and start another project.  This approach is especially powerful because it prioritizes finishing projects over starting them.

“Three Cows” by Sunfox is licensed under CC BY-SA 2.0.

Whatever your initiative, start with customer value. Whatever your project, base it on customer value. And whatever your new technology, you guessed it, customer value should be front and center.

Whenever the discussion turns to customer value, expect confusion, disagreement, and, likely, anger. To help things move forward, here’s an operational definition I’ve found helpful:

When they buy it for more than your cost to make it, you have customer value.

And when there’s no way to pull out of the death spiral of disagreement, use this operational definition to avoid (or stop) bad projects:

When no one will buy it, you don’t have customer value and it’s a bad project.

As two words, customer and value don’t seem all that special. But, when you put them together, they become words to live by.  But, also, when you do put them together, things get complicated.  Here’s why.

To provide customer value, you’ve got to know (and name) the customer.  When you asked “Who is the customer?” the wheels fall off. Here are some wrong answers to that tricky question. The Board of Directors is the customer. The shareholders are the customers. The distributor is the customer. The OEM that integrates your product is the customer. And the people that use the product are the customer. Here’s an operational definition that will set you free:

When someone buys it, they are the customer.

When the discussions get sticky, hold onto that definition. Others will try to bait you into thinking differently, but don’t bite. It will be difficult to stand your ground.  And if you feel the group is headed in the wrong direction, try to set things right with this operational definition:

When you’ve found the person who opens their wallet, you’ve found the customer.

Now, let’s talk about value. Isn’t value subjective? Yes, it is.  And the only opinion that matters is the customer’s. And here’s an operational definition to help you create customer value:

When you solve an important customer problem, they find it valuable.

And there you have it.  Putting it all together, here’s the recipe for customer value:

1. Understand who will buy it.
2. Understand their work and identify their biggest problem.
3. Solve their problem and embed it in your offering.
4. Sell it for more than it costs you to make it.

Image credit — Caroline

When the fate of your company rests on a single project, who are the three people you’d tap to drag that pivotal project over the finish line? And to sharpen it further, ask yourself “Who do I want to lead the project that will save the company?” You now have a list of the three most important people in your company.  Or, if you answered the second question, you now have the name of the most important person in your company.

The most important person in your company is the person that drags the most important projects over the finish line.  Full stop.

When the project is on the line, the CEO doesn’t matter; the General Manager doesn’t matter; the Business Leader doesn’t matter.  The person that matters most is the Project Manager.  And the second and third most important people are the two people that the Project Manager relies on.

Don’t believe that? Well, take a bite of this. If the project fails, the product doesn’t sell. And if the product doesn’t sell, the revenue doesn’t come. And if the revenue doesn’t come, it’s game over. Regardless of how hard the CEO pulls, the product doesn’t launch, the revenue doesn’t come, and the company dies.  Regardless of how angry the GM gets, without a product launch, there’s no revenue, and it’s lights out.  And regardless of the Business Leader’s cajoling, the project doesn’t cross the finish line unless the Project Manager makes it happen.

The CEO can’t launch the product. The GM can’t launch the product. The Business Leader can’t launch the product.  Stop for a minute and let that sink in.  Now, go back to those three sentences and read them out loud. No, really, read them out loud.  I’ll wait.

When the wheels fall off a project, the CEO can’t put them back on. Only a special Project Manager can do that.

There are tools for project management, there are degrees in project management, and there are certifications for project management.  But all that is meaningless because project management is alchemy.

Degrees don’t matter. What matters is that you’ve taken over a poorly run project, turned it on its head, and dragged it across the line. What matters is you’ve run a project that was poorly defined, poorly staffed, and poorly funded and brought it home kicking and screaming. What matters is you’ve landed a project successfully when two of three engines were on fire. (Belly landings count.) What matters is that you vehemently dismiss the continuous improvement community on the grounds there can be no best practice for a project that creates something that’s new to the world. What matters is that you can feel the critical path in your chest. What matters is that you’ve sprinted toward the scariest projects and people followed you. And what matters most is they’ll follow you again.

Project Managers have won the hearts and minds of the project team.

The Project manager knows what the team needs and provides it before the team needs it. And when an unplanned need arises, like it always does, the project manager begs, borrows, and steals to secure what the team needs.  And when they can’t get what’s needed, they apologize to the team, re-plan the project, reset the completion date, and deliver the bad news to those that don’t want to hear it.

If the General Manager says the project will be done in three months and the Project Manager thinks otherwise, put your money on the Project Manager.

Project Managers aren’t at the top of the org chart, but we punch above our weight. We’ve earned the trust and respect of most everyone. We aren’t liked by everyone, but we’re trusted by all. And we’re not always understood, but everyone knows our intentions are good. And when we ask for help, people drop what they’re doing and pitch in. In fact, they line up to help. They line up because we’ve gone out of our way to help them over the last decade. And they line up to help because we’ve put it on the table.

Whether it’s IoT, Digital Strategy, Industry 4.0, top-line growth, recurring revenue, new business models, or happier customers, it’s all about the projects. None of this is possible without projects. And the keystone of successful projects?  You guessed it.  Project Managers.

Image credit – Bernard Spragg .NZ

All-or-nothing thinking is exciting – we’ll launch a whole new product family all at once and take the market by storm! But it’s also dangerous – if we have one small hiccup, “all” turns into “nothing” in a heartbeat. When you take an all-or-nothing approach, it’s likely you’ll have far too little “all” and far too much “nothing”.

Instead of trying to realize the perfection of “all”, it’s far better to turn nothing into something.  Here’s the math for an all-or-nothing launch of product family launch consisting of four products, where each product will create $1 million in revenue and the probability of launching each product is 0.5 (or 50%).

1 product x $1 million x 0.5 = $500K

2 products x $1 million x 0.5 x 0.5 = $500K

3 products x $1 million x 0.5 x 0.5 x 0.5 = $375K

4 products x $1 million x 0.5 x 0.5 x 0.5 x 0.5 = $250K

In the all-or-nothing scheme, the launch of each product is contingent on all the others.  And if the probability of each launch is 0.5, the launch of the whole product family is like a chain of four links, where each link has a 50% chance of breaking.  When a single link of a chain breaks, there’s no chain. And it’s the same with an all-or-nothing launch – if a single product isn’t ready for launch, there are no product launches.

But the math is worse than that. Assume there’s new technology in all the products and there are five new failure modes that must be overcome.  With all-or-nothing, if a single failure mode of a single product is a problem, there are no launches.

But the math is even more deadly than that. If there are four use models (customer segments that use the product differently) and only one of those use models creates a problem with one of the twenty failure modes (five failure modes times four products) there can be no launches. In that way, if 25% of the customers have one problem with a single failure mode, there are can be no launches.  Taken to an extreme, if one customer has one problem with one product, there can be no launches.

The problem with all-or-nothing is there’s no partial credit – you either launch four products or you launch none. Instead of all-or-nothing, think “secure the launch”. What must we do to secure the launch of a single product? And once that one’s launched, the money starts to flow.  And once we launch the first one, what must we do to secure the launch the second? (More money flows.) And, once we launch the third one…. you get the picture. Don’t try to launch four at once, launch a single product four times in a row. Instead of all-or-nothing, think one-in-a-row, where revenue is achieved after each launch of a single launch.

And there’s another benefit to launching one at a time. The second launch is informed by learning from the first launch.  And the third is informed by the first two. With one-in-a-row, the team gets smarter and each launch gets better.

Where all-or-nothing is glamorous, one-in-a-row is achievable. Where all-or-nothing is exciting, one-in-row is achievable. And where all-or-nothing is highly improbable, one-in-a-row is highly profitable.

Image credit – Mel

Wanting things to be different is a good start, but it’s not enough. To create conditions for things to move in a new direction, you’ve got to change your behavior. But with systems that involve people, this is not a straightforward process.

To create conditions for the system to change, you must understand the system”s disposition – the lines along which it prefers to change.. And to do that, you’ve got to push on the system and watch its response. With people systems, the response is not knowable before the experiment.

If you expect to be able to predict how the system will respond, working with people systems can be frustrating.  I offer some guidance here. With this work, you are not responsible for the system’s response, you are only responsible for how you respond to the system’s response.

If the system responds in a way you like, turn that experiment into a project to amplify the change.  If the system responds in a way you dislike, unwind the experiment.  Here’s a simple mantra – do more of what works and less of what doesn’t. (Thanks to Dave Snowden for this.)

If you don’t like how things are going, you have only one lever to pull.  You can only change.your response to what you see and experience. You can respond by pushing on the system and responding to what you see or you can respond by changing what you think and feel about the system.

But keep in mind that you are part of the system. And maybe the system is running an experiment on you. Either way, your only choice is to choose how to respond.

The primary impediment to innovation is fear, and the prime directive of any innovation system should be to drive out fear.

A culture of accountability, implemented poorly, can inject fear and deter innovation.  When the team is accountable to deliver on a project but are constrained to a fixed scope, a fixed launch date and resources, they will be afraid.  Because they know that innovation requires new work and new work is inherently unpredictable, they rightly recognize the triple accountability – time, scope and resources – cannot be met.  From the very first day of the project, they know they cannot be successful and are afraid of the consequences.

A culture of accountability can be adapted to innovation to reduce fear.  Here’s one way. Keep the team small and keep them dedicated to a single innovation project. No resource sharing, no swapping and no double counting. Create tight time blocks with clear work objectives, where the team reports back on a fixed pitch (weekly, monthly). But make it clear that they can flex on scope and level of completeness.  They should try to do all the work within the time constraints but they must know that it’s expected the scope will narrow or shift and the level of completeness will be governed by the time constraint.  Tell them you believe in them and you trust them to do their best, then praise their good judgement at the review meeting at the end of the time block.

Innovation is about solving new problems, yet fear blocks teams from trying new things. Teams like to solve problems that are familiar because they have seen previous teams judged negatively for missing deadlines. Here’s the logic – we’d rather add too little novelty than be late.  The team would love to solve new problems but their afraid, based on past projects, that they’ll be chastised for missing a completion date that’s disrespectful of the work content and level of novelty.  If you want the team to solve new problems, give them the tools, time, training and a teacher so they can select different problems and solve them differently. Simply put – create the causes and conditions for fear to quietly slink away so innovation will flow.

Fear is the most powerful inhibitor. But before we can lessen the team’s fear we’ve got to recognize the causes and conditions that create it. Fear’s job is to keep us safe, to keep us away from situations that have been risky or dangerous.  To do this, our bodies create deep memories of those dangerous or scary situations and creates fear when it recognizes similarities between the current situation and past dangerous situations.  In that way, less fear is created if the current situation feels differently from situations of the past where people were judged negatively.

To understand the causes and conditions that create fear, look back at previous projects.  Make a list of the projects where project members were judged negatively for things outside their control such as: arbitrary launch dates not bound by the work content, high risk levels driven by unjustifiable specifications, insufficient resources, inadequate tools, poor training and no teacher.  And make a list of projects where team members were praised.  For the projects that praised, write down attributes of those projects (e.g., high reuse, low technical risk) and their outcomes (e.g., on time, on cost).  To reduce fear, the project team will bend new projects toward those attributes and outcomes. Do the same for projects that judged negatively for things outside the project teams’ control. To reduce fear, the future project teams will bend away from those attributes and outcomes.

Now the difficult parts.  As a leader, it’s time to look inside.  Make a list of your behaviors that set (or contributed to) causes and conditions that made it easy for the project team to be judged negatively for the wrong reasons.  And then make a list of your new behaviors that will create future causes and conditions where people aren’t afraid to solve new problems in new ways.

Image credit — andrea floris

There are four ways to run projects.

One – 80% Right, 100% Done, 100% On Time, 100% On Budget

• Fix time
• Fix resources
• Flex scope and certainty

Set a tight timeline and use the people and budget you have.  You’ll be done on time, but you must accept a reduced scope (fewer bells and whistles) and less certainty of how the product/service will perform and how well it will be received by customers. This is a good way to go when you’re starting a new adventure or investigating new space.

Two – 100% Right, 100% Done, 0% On Time, 0% On Budget

• Fix resources
• Fix scope and certainty
• Flex time

Use the team and budget you have and tightly define the scope (features) and define the level of certainty required by your customers. Because you can’t predict when the project will be done, you’ll be late and over budget, but your offering will be right and customers will like it. Use this method when your brand is known for predictability and stability. But, be weary of business implications of being late to market.

Three – 100% Right, 100% Done, 100% On Time, 0% On Budget

• Fix scope and certainty
• Fix time
• Flex resources

Tightly define the scope and level of certainty. Your customers will get what they expect and they’ll get it on time.  However, this method will be costly. If you hire contract resources, they will be expensive.  And if you use internal resources, you’ll have to stop one project to start this one. The benefits from the stopped project won’t be realized and will increase the effective cost to the company.  And even though time is fixed, this approach will likely be late.  It will take longer than planned to move resources from one project to another and will take longer than planned to hire contract resources and get them up and running.  Use this method if you’ve already established good working relationships with contract resources.  Avoid this method if you have difficulty stopping existing projects to start new ones.

Four – Not Right, Not Done, Not On Time, Not On Budget

• Fix time
• Fix resources
• Fix scope and certainty

Though almost every project plan is based on this approach, it never works.  Sure, it would be great if it worked, but it doesn’t, it hasn’t and it won’t. There’s not enough time to do the right work, not enough money to get the work done on time and no one is willing to flex on scope and certainty.  Everyone knows it won’t work and we do it anyway.  The result – a stressful project that doesn’t deliver and no one feels good about.

Image credit – Cees Schipper