Archive for the ‘Fundementals’ Category

Projects, Problems and People

The projects you choose define the problems you solve.

The problems you choose to solve define the novel value delivered to the customer.

The people you choose to run the projects set the character of the projects.

The choice of the projects’ character defines how the people feel about working on the projects.

How people choose to feel about working on the projects influences the character of the projects.

The people on the projects choose how the problems are solved.

How people choose to solve problems defines how well the problems are solved.

The choice around how well problems are solved sets the level of goodness delivered to the customer.

The level of goodness you choose to deliver to the customer governs the incremental revenue you create.

It doesn’t seem right that the amount of incremental revenue is a choice.

But, when you choose the right projects and the right people to run them and you choose the right problems and the right people to solve them, incremental revenue becomes your choice.

image credit — officallychaz

When it comes to mismatches, seeing is believing.

When there’s a disagreement between the stated strategy and the active projects, believe the active projects.

When there’s a formal objective to reduce the number of meetings and the number of meetings doesn’t decrease, the desired outcome isn’t really desired.

When there’s a desire to reduce costs and there’s no hiring freeze, there’s no real desire to reduce costs.

When it’s acknowledged that there are too many projects and more projects are added, the doers’ morale tanks while the approvers’ credibility is decimated.

When people don’t talk openly about the mismatch between words and behavior, it does not mean they’re unaware.

When there’s a mismatch between words and behavior, people see it.

The Curse of Too Many Active Projects

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

The Ins and Outs of Problems

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

The Difficulty of Starting New Projects

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

The Mighty Capacity Model

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, Extend, Transcend – A Good Way to Assess Company Priorities

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

Are you making progress?

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.

Four Things That Matter

Health matters. What did you do this year to take care of your physical health? What did you do this year to take care of your mental health? Next year what can you stop doing to make it easier to take care of your physical and mental health? Without your health, what do you have?

Family matters. What did you do this year to connect more deeply with your family? And how do you feel about that?  Next year what can you change to make it easier to deepen your relationships with a couple of family members?  If you’re going to forgive anyone next year, why not forgive a family member? Without family, what do you have?

Friends matter. What did you do this year to reconnect with old friends? What did you do this year to help turn a good friendship into a great one? What did you do this year to make new friends? Next year what will make it easier to reestablish old friendships, deepen the good ones, and create new ones?  Without friends, what do you have?

Fun matters. What did you do this year to have fun for fun’s sake? Why is it so difficult to have fun? Next year what can you change to make it easier for you to have more fun?  Without fun, what do you have?

Friendship” by *~Dawn~* is licensed under CC BY 2.0.

Reducing Time To Market vs. Improving Profits

X: We need to decrease the time to market for our new products.

Me: So, you want to decrease the time it takes to go from an idea to a commercialized product?

X: Yes.

Me: Okay.  That’s pretty easy.  Here’s my idea.  Put some new stickers on the old product and relaunch it.  If we change the stickers every month, we can relaunch the product every month.  That will reduce the time to market to one month.  The metrics will go through the roof and you’ll get promoted.

X: That won’t work.  The customers will see right through that and we won’t sell more products and we won’t make more money.

Me: You never said anything about making more money.  You said you wanted to reduce the time to market.

X: We want to make more money by reducing time to market.

Me: Hmm.  So, you think reducing time to market is the best way to make more money?

X: Yes. Everyone knows that.

Me: Everyone?  That’s a lot of people.

X: Are you going to help us make more money by reducing time to market?

Me: I won’t help you with both.  If you had to choose between making more money and reducing time to market, which would you choose?

X: Making money, of course.

Me: Well, then why did you start this whole thing by asking me for help improving time to market?

X: I thought it was the best way to make more money.

Me: Can we agree that if we focus on making more money, we have a good chance of making more money?

X: Yes.

Me:  Okay.  Good.  Do you agree we make more money when more customers buy more products from us?

X: Everyone knows that.

Me:  Maybe not everyone, but let’s not split hairs because we’re on a roll here.  Do you agree we make more money when customers pay more for our products?

X: Of course.

Me: There you have it.  All we have to do is get more customers to buy more products and pay a higher price.

X: And you think that will work better than reducing time to market?

Me: Yes.

X: And you know how to do it?

Me: Sure do.  We create new products that solve our customers’ most important problems.

X: That’s totally different than reducing time to market.

Me: Thankfully, yes.  And far more profitable.

X: Will that also reduce the time to market?

Me: I thought you said you’d choose to make more money over reducing time to market. Why do you ask?

X: Well, my bonus is contingent on reducing time to market.

Me: Listen, if the previous new product development projects took two years, and you reduce the time to market to one and half years, there’s no way for you to decrease time to market by the end of the year to meet your year-end metrics and get your bonus.

X: So, the metrics for my bonus are wrong?

Me: Right.

X: What should I do?

Me: Let’s work together to launch products that solve important customer problems.

X:  And what about my bonus?

Me: Let’s not worry about the bonus.  Let’s worry about solving important customer problems, and the bonuses will take care of themselves.

Image credit — Quinn Dombrowski

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

Which new product development project should we do first?

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

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives