Archive for the ‘Complexity’ Category

Moving from Static to Dynamic

At some point, what worked last time won’t work this time. It’s not if the business model will go belly-up, it’s when. There are two choices. We can bury our heads in the sands of the status quo, or we can proactively observe the world in a forward-looking way and continually reorient ourselves as we analyze and synthesize what we see.

The world is dynamic, but we behave like it’s static. We have massive intellectual inertia around what works today.  In a rearward-looking way, we want to hold onto today’s mental models and we reject the natural dynamism swirling around us.  But the signals are clear. There’s cultural change, political change, climate change and population change. And a lower level, there’s customer change, competition change, technology change, coworker change, family change and personal change. And still, we cling to static mental models and static business models. But how to move from static to dynamic?

Continual observation and scanning is a good place to start. And since things become real when resources are allocated, allocating resources to continually observe and scan sends a strong message. We created this new position because things are changing quickly and we need to be more aware and more open minded to the dynamic nature of our world.  Sure, observation should be focused and there should be a good process to decide on focus areas, but that’s not the point. The point is things are changing and we will continually scan for storms brewing just over the horizon.  And, yes, there should be tools and templates to record and organize the observations, but the important point is we are actively looking for change in our environment.

Observation has no value unless the observed information is used for orientation in the new normal.  For orientation, analysis and synthesis is required across many information sources to develop ways to deal with the unfamiliar and unforeseen. [1] It’s important to have mechanisms to analyze and synthesize, but the value comes when beliefs are revised and mental models are updated. Because the information cuts against history, tradition and culture, to make shift in thinking requires diversity of perspective, empathy and a give-and-take dialog. [1] It’s a nonlinear process that is ironed out as you go.  It’s messy and necessary.

It’s risky to embrace a new perspective, but it’s far riskier to hold onto what worked last time.

 

[1] Osinga, Frans, P.B. Science, Strategy and War, The strategic theory of John Boyd. New York: Routledge, 2007.

image credit – gabe popa

Learn in small batches, rinse and repeat.

When the work is new, it can’t be defined and managed like work that has been done before.

Sometimes there’s a tendency to spend months to define the market, the detailed specification and the project timeline and release the package as a tidal wave that floods the organization with new work.  Instead, start with a high-level description of the market, a rough specification and the major project milestones, all of which will morph, grow and inform each other as the team learns.  Instead of a big batch, think bite-sized installments that build on each other. Think straw-man that gets its flesh as the various organizations define their learning objectives and learn them.

Instead of target customer segments and idealized personas, define how the customers will interact with the new product or service. Use the storyboard format to capture sequence of events (what they do), the questions they ask themselves and how they know they’ve done it right. Make a storyboard for the top three to five most important activities the customers must do.  There’s good learning just trying to decide on the top three to five activities, never mind the deep learning that comes when you try to capture real activities of real customers. [Hint – the best people to capture real customer activities are real customers.]

Instead of a detailed list of inputs and outputs, fill in the details of the storyboards.  Create close-ups of the user interfaces and label the dials, buttons and screens.  When done well, the required inputs and outputs bubble to the surface.  And define the customer’s navigation path, as it defines the sequence of things and where the various inputs come to be and the various outputs need to be.  What’s nice is learning by iteration can be done quickly since its done in the domain of whiteboards and markers.

Instead of defining everything, just define what’s new and declare everything else is the same as last time.

The specification for the first prototypes is to bring the storyboards to life and to show the prototypes to real customers.  Refine and revise based on the learning, and rinse and repeat, as needed.

As the design migrates toward customer value and confidence builds, it’s then time to layer on the details and do a deep dive into the details – specs, test protocols, manufacturing, sales and distribution.

At early stages of innovation work, progress isn’t defined by activity, it’s defined by learning.  And it can look like nothing meaningful is happening as there is a lot of thinking and quiet time mixed in with infrequent bursts active activity.  But that’s what it takes to answer the big questions of the front end.

When in doubt, answer the big questions at the expense of the details.  And to stay on track, revisit and refine the learning objectives. And to improve confidence, show it to real customers.

And rinse and repeat, as needed.

Image credit – Jason Samfield

Before you can make a million, you’ve got to make the first one.

With process improvement, the existing process is refined over time.  With innovation, the work is new. You can’t improve a process that does not yet exist.  Process creation, yes.  Process improvement, no.

Standard work, where the sequence of process steps has proven successful, is a pillar of the manufacturing mindset.  In manufacturing, if you’re not following standard work, you’re not doing it right.  But with innovation, when the work is done for the first time, there can be no standard work. In that way, if you’re following the standard work paradigm, you are not doing innovation.

In a well-established manufacturing process, problems are tightly scoped and constrained. There can be several ways to solve it and one of the ways is usually better than the others. Teams are asked to solve the problem three or four ways and explain the rationale for choosing one solution over the other. With innovation it’s different.  There may not be a solution, never mind three.  With innovation, it’s one-in-a-row solution.  And the real problem is to decide which problem to solve.  If you’re asked to use Fishbone diagrams to solve the problem three or four ways, you’re not doing innovation. Solve it one way, show a potential customer and decide what to do next.

With manufacturing and product development, it’s all about Gantt charts and hitting dates.  The tasks have a natural precedence and all of them have been done before.  There are branches in the plan, but behind them is clear if-then logic.  With innovation, the first task is well-defined.  And the second task – it depends on the outcome of the first.  And completion dates?  No way. If you can predict the completion date, you’re not doing innovation.  And if you’re asked for a fully built-out Gantt chart, you’re in trouble because that’s a misguided request.

Systems in manufacturing can be complicated, with lots of moving parts.  And the problems can be complicated. But given enough time, the experts can methodically figure it out. But with innovation, the systems can be complex, meaning they are not predictable.  Sometimes parts of the system interact strongly with other parts and sometimes they don’t interact at all. And it’s not that they do one or the other, it’s that they do both.  It’s like they have a will of their own, and, sometimes, they have a bad attitude. And if it’s a new system, even the basic rules of engagement are unknown, never mind the changing strength of the interactions.  And if the system is incomplete and you don’t know it, linear thinking of the experts can’t solve it.  If you’re using linear problem solving techniques, you’re not doing innovation.

Manufacturing is about making one thing a million times. Innovation is about choosing among the million possibilities and making one-in-a-row, and then, after the bugs are worked out, making the new thing a million times.  But one-in-a-row must come first.  If you can’t do it once, you can’t do it a million times, even with process improvement, standard work, Gantt charts and Fishbone diagrams.

Image credit jacinta lluch valero

Improving What Is and Creating What Isn’t

There are two domains – what is and what isn’t. We’re most comfortable in what is and we don’t know much about what isn’t. Neither domain is best and you can’t have one without the other. Sometimes it’s best to swim in what is and other times it’s better to splash around in what isn’t.  Though we want them, there are no hard and fast rules when to swim and when to splash.

Improvement lives in the domain of what is. If you’re running a Six Sigma project, a lean project or a continuous improvement program you’re knee deep in what is. Measure, analyze, improve, and control what is. Walk out to the production floor, count the machines, people and defects, measure the cycle time and eliminate the wasteful activities. Define the current state and continually (and incrementally) improve what is. Clear, unambiguous, measurable, analytical, rational.

The close cousins creativity and innovation live in the domain of what isn’t. They don’t see what is, they only see gaps, gulfs and gullies. They are drawn to the black hole of what’s missing. They define things in terms of difference.  They care about the negative, not the image. They live in the Bizarro world where strength is weakness and far less is better than less. Unclear, ambiguous, intuitive, irrational.

What is – productivity, utilization, standard work. What isn’t – imagination, unstructured time, daydreaming. Predictable – what is. Unknowable – what isn’t.

In the world of what is, it’s best to hire for experience.  What worked last time will work this time. The knowledge of the past is all powerful.  In the world of what isn’t, it’s best to hire young people that know more than you do. They know the latest technology you’ve never heard of and they know its limitations.

Improving what is pays the bills while creating what isn’t fumbles to find the future. But when what is runs out of gas, what isn’t rides to the rescue and refuels. Neither domain is better, and neither can survive without the other.

The magic question – what’s the best way to allocate resources between the domains? The unsatisfying answer – it depends. And the sextant to navigate the dependencies – good judgement.

Image credit – JD Hancock

Learning at the expense of predicting.

john_william_waterhouse_-_the_crystal_ballWhen doing new things there is no predictability. There’s speculation, extrapolation and frustration, but no prediction. And the labels don’t matter.  Whether it’s called creativity, innovation, discontinuous improvement or disruption there’s no prediction.

The trick in the domain complexity is to make progress without prediction.

The first step is to try to define the learning objective.  The learning objective is what you want to learn. And its format is – We want to learn that [fill in the learning objective here].  It’s fastest to tackle one learning objective at a time because small learning objectives are achieved quickly with small experiments.  But, it will be a struggle to figure out what to learn.  There will be too many learning objectives and none will be defined narrowly.  At this stage the fastest thing to do is stop and take a step back.

There’s nothing worse than learning about the wrong thing.  And it’s slow. (The fastest learning experiments are the ones that don’t have to be run.) Before learning for the sake of learning, take the necessary time to figure out what to learn. Ask some questions: If it worked could it reinvent your industry? Could it obsolete your best product? Could it cause competitors to throw in the towel?  If the answer is no, stop the project and choose one where the answer is yes. Choose a meaningful project, or don’t bother.

First learning objective – We want to learn that, when customers love the new concept, the company will assign appropriate resources to commercialize it.  If there’s no committment up front, stop.  If you get committment, keep going. (Without upfront buy-in the project relies on speculation, the wicked couple of prediction and wishful thinking.)

Second learning objective – We want to learn that customers love the new concept.  This is not “I think customers will love it.” or “Customers may love it.” In the standard learning objective format – We want to learn that [customers love the new concept].  Next comes the learning plan.

What will you build for customers to help them understand the useful novelty of the revolutionary concept?  For speed’s sake, build a non-functional prototype that stands for the concept.  It’s a thin skin wrapped around an empty box that conveys the essence of the novelty.  No skeleton, just skin.  And for speed’s sake, show it to fewer customers than you think reasonable.  And define the criteria to decide they love it.  There’s no trick here. Ask “Do they love it?” and use your best judgement.  At this early stage, the answer will be no.  But they’ll tell you why they don’t love it, and that’s just the learning you’re looking for.

Use customer input to reformulate the learning objective and build a new prototype and repeat.  The key here is to build fast, test fast, learn fast and repeat fast.  The art becomes defining the simplest learning objectives, building the simplest prototypes and making decisions with data from the fewest customers.

With complexity and newness prediction isn’t possible. But learning is.

And learning doesn’t have to take a lot of time.

Image credit — John William Waterhouse

Established companies must be startups, and vice versa.

oppositesFor established companies, when times are good, it’s not the right time to try something new – the resources are there but the motivation is not; and when times are tough it’s also the wrong time to try something new – the motivation is there but the breathing room is not.  There are an infinite number of scenarios, but for the established company it’s never a good time to try something new.

For startup companies, when times are good, it’s the right time to try something new – the resources are there and so is the motivation; and when times are tough it’s also the right time to try something new – the motivation is there and breathing room is a sign of weakness.  Again, the scenarios are infinite, but for the startup is always a good time to try something new.

But this is not a binary world. To create new markets and new customers, established companies must be a little bit startup, and to scale, startups must ultimately be a little bit established. This ambidextrous company is good on paper, but in the trenches it gets challenging. (Read Ralph Ohr for an expert treatment.)  The establishment regime never wants to do anything new and the startup regime always wants to.  There’s no middle ground – both factions judge each other through jaded lenses of ROI and learning rate and mutual misunderstanding carries the day.  Trouble is, all companies need both – established companies need new markets and startups need to scale. But it’s more complicated than that.

As a company matures the balance of power should move from startup to established.  But this tricky because the one thing power doesn’t like to do is move from one camp to another. This is the reason for the “perpetual startup” and this is why it’s difficult to scale.  As the established company gets long in the tooth the balance of power should move from the establishment to the startup.  But, again, power doesn’t like to change teams, and established companies squelch their fledgling startup work. But it’s more complicated, still.

The competition is ever-improving, the economy is ever-changing and the planet is ever-warming.  New technologies come on-line, and new business models test the waters. Some work, some don’t.  Huge companies buy startups just to snuff them out and established companies go away.  The environment is ever-changing on all fronts.  And the impermanence pushes and pulls on the pendulum of power dynamics.

All companies want predictability, but they’ll never have it.  All growth models are built on rearward-looking fundamentals and forward-looking conjecture.  Companies will always have the comfort of their invalid models, but will never the predictability they so desperately want.  Instead of predictability, companies would be better served by a strong sense of how it wants to go about its business and overpowering genetics of adaptability.

For a strong definition of how to go about business, a simple declaration does nicely. “We want to spend 80% of our resources on established-company work and 20% on startup-company work.” (Or 90-10, or 95-5.)  And each quarter, the company measures itself against its charter, and small changes are made to keep things on track.  Unless, of course, if the environment changes or the business model runs out of gas.  And then the company adapts.  It changes its approach and it’s projects to achieve its declared 80-20 charter, or, changes the charter altogether.

A strong charter and adaptability don’t seem like good partners, but they are.  The charter brings focus and adaptability brings the change necessary to survive in an every-changing environment.  It’s not easy, but it’s effective.  As long as you have the right leaders.

Image credit – Rick Abraham1

When doing new work, you’ll be wrong.

OOPSWhen doing something from the first time you’re going to get it wrong.  There’s no shame in that because that’s how it goes with new work. But more strongly, if you don’t get it wrong you’re not trying hard enough.  And more strongly, embrace the inherent wrongness as a guiding principle.

Take Small Bites. With new work, a small scope is better than a large one.  But it’s exciting to do new work and there’s a desire to deliver as much novel usefulness as possible.  And, without realizing it, the excitement can lead to a project bloated with novelty.  With the best intentions, the project team is underwater with too much work and too little time.  With new work, it’s better to take one bite and swallow than three and choke.

Ratchet Thinking. With new work comes passion and energy.  And though the twins can be helpful and fun to have around, they’re not always well-behaved.  Passion can push a project forward but can also push it off a cliff. Energy creates pace and can quickly accelerate a project though the milestones, but energy can be careless and can just as easily accelerate a project in the wrong direction.  And that’s where ratchet thinking can help.

As an approach, the objective of ratchet thinking is to create small movements in the right direction without the possibility of back-sliding.  Solve a problem and click forward one notch; solve a second problem and click forward another notch.  But, with ratchet thinking, if the third problem isn’t solved, the project holds its ground at the second notch.  It takes a bit more time to choose the right problem and to solve it in a way that cannot unwind progress, but ultimately it’s faster.  Ratchet thinking takes the right small bite, chews, swallows.

Zero Cost of Change. New work is all about adding new functions, enhancing features and fixing what’s broken.  In other words, new work is all about change. And the faster change can happen, the faster the product/service/business model is ready for sale.  But as the cost of change increases the rate of changes slows.  So why not design the project to eliminate the cost of change?

To do that, design the hardware with a bit more capability and headroom so there’s some wiggle room to handle the changes that will come.  Use a modular approach for the software to minimize the interactions of software changes and make sure the software can be updated remotely without customer involvement.  And put in place a good revision control (and tracking) mechanism.

Doing new work is full of contradictions: move quickly, but take the time to think things through; take on as much as you can, but no more; be wrong, but in the right way; and sometimes slower is faster.

But doing new work you must.

image credit – leasqueaky

Diabolically Simple Questions

DiabolicalToday’s work is complicated with electronic and mechanical subsystems wrapped in cocoons of software; coordination of matrixed teams; shared resources serving multiple projects; providing world class services in seventeen languages on four continents. And the complexity isn’t limited to high level elements.  There is a living layer of complexity growing on all branches of the organization right down to the leaf level.

Complexity is real, and it complicates things.  To run projects and survive in the jungle of complexity it’s important to know how to put the right pieces together and provide the right answers.  But as a leader it’s more important to slash through the complexity and see things as they are.  And for that, it’s more important to know how ask diabolically simple questions (DSQ).

Project timelines are tight and project teams like to start as soon as they can.  Too often teams start without clarity on what they’re trying to achieve.  At these early stages the teams make record progress in the wrong direction.  The leader’s job is to point them in the right direction, and here’s the DSQ to set them on their way: What are you trying to achieve?

There will likely be some consternation, arm waiving and hand wringing.  After the dust settles, help the team further tighten down the project with this follow-on DSQ:  How will you know you achieved it?

For previous two questions there are variants that works equally well for work that closer to the fuzzy front end: What are you trying to learn? and How will you know you learned it?

There is no such thing as a clean-sheet project and even the most revolutionary work builds on the existing system.  Though the existing business model, service or product has been around for a long time, the project team doesn’t really know how it works.  They know they should know but they’re afraid to admit it. Let them off the hook with this beauty: How does it work today?

After the existing system is defined with a simple block diagram (which could take a couple weeks) it’s time to help the project team focus their work.  The best DSQ for the job: How is it different from the existing system?  If the list is too long there’s too much newness and if it’s too short there’s not enough novelty.  If they don’t know what’s different, ask them to come back when they know.

After the “what’s different” line of questioning, the team must be able to dive deeper.  For that it’s time one of the most powerful DSQs in the known universe: What problem are you trying to solve? Expect frustration and complicated answers.  Ask them to take some time and for each problem describe it on a single page using less than ten words.  Suggest a block diagram format and ask them to define where and when the problem occurs.  (Hint: a problem is always between two components/elements of the system.)  And the tricky follow-on DSQ: How will you know you solved it? No need to describe the reaction to that one.

Though not an exhaustive list, here are some of my other favorite DSQs:

Who will buy it, how much will they pay, and how do you know?

Have we done this before?

Have you shown it to a real customer?

How much will it cost and how do you know?

Whose help do we need?

If the prototype works, will we actually do anything with it?

Diabolically simple questions have the power to heal the project teams and get them back on track.  And over time, DSQs help the project teams adopt a healthy lifestyle.  In that way, DSQs are like medicine – they taste bad but soon enough you feel better.

Image credit – Daniela Hartmann

Progress is powered by people.

A Little Push

People ask why.

People buy products from people.

The right people turn activity into progress.

People want to make a difference, and they do.

People have biases which bring a richer understanding.

People use judgement – that’s why robots don’t run projects.

People recognize when the rules don’t apply and act accordingly.

Business models are an interconnected collection of people processes.

The simplest processes require judgement, that’s why they’re run by people.

People don’t like good service, they like effective interaction with other people.

People are the power behind the tools.  (I never met a hammer that swung itself.)

Progress is powered by people.

 

Image credit – las – intially

Dissent Without Reprisal – a key to company longevity

all in jestIn strategic planning there’s a strong forcing function that causes the organization to converge on a singular, company-wide approach.  While this convergence can be helpful, when it’s force is absolute it stifles new ideas.  The result is an operating plan that incrementally improves on last year’s work at the expense of work that creates new businesses, sells to new customers and guards against the dark forces of disruptive competition.  In times of change convergence must be tempered to yield a bit of diversity in the approach.  But for diversity to make it into the strategic plan, dissent must be an integral (and accepted) part of the planning process.  And to inject meaningful diversity the dissenting voice must be as load as the voice of convergence.

It’s relatively easy for an organization to come to consensus on an idea that has little uncertainty and marginal upside.  But there can be no consensus, but on an idea with a high degree of uncertainty even if the upside is monumental.  If there’s a choice between minimizing uncertainty and creating something altogether new, the strategic process is fundamentally flawed because the planning group will always minimize uncertainty.  Organizationally we are set up to deliver certainty, to make our metrics and meet our timelines.  We have an organizational aversion to uncertainty, and, therefore, our organizational genetics demand we say no to ideas that create new business models, new markets and new customers.  What’s missing is the organizational forcing function to counterbalance our aversion to uncertainty with a healthy grasping of it.  If the company is to survive over the next 20 years, uncertainty must be injected into our organizational DNA. Organizationally, companies must be restructured to eliminate the choice between work that improves existing products/services and work that creates altogether new markets, customers, products and services.

When Congress or the President wants to push their agenda in a way that is not in the best long term interest of the country, no one within the party wants to be the dissenting voice. Even if the dissenting voice is right and Congress and the President are wrong, the political (career) implications of dissent within the party are too severe.  And, organizationally, that’s why there’s a third branch of government that’s separate from the other two.  More specifically, that’s why Justices of the Supreme Court are appointed for life.  With lifetime appointments their dissenting voice can stand toe-to-toe with the voice of presidential and congressional convergence.  Somehow, for long-term survival, companies must find a way to emulate that separation of power and protect the work with high uncertainty just as the Justices protect the law.

The best way I know to protect work with high uncertainty is to create separate organizations with separate strategic plans, operating plans and budgets.  In that way, it’s never a decision between incremental improvement and discontinuous improvement.  The decision becomes two separate decisions for two separate teams: Of the candidate projects for incremental improvement, which will be part of team A’s plan? And, of the candidate projects for discontinuous improvement, which will become part of team B’s plan?

But this doesn’t solve the whole challenge because at the highest organizational level, the level that sits above Team A and B, the organizational mechanism for dissent is missing. At this highest level there must be healthy dissent by the board of directors.  Meaningful dissent requires deep understanding of the company’s market position, competitive landscape, organizational capability and capacity, the leading technology within the industry (the level, completeness and maturity), the leading technologies in adjacent industries and technologies that transcend industries (i.e., digital).  But the trouble is board members cannot spend the time needed to create deep understanding required to formulate meaningful dissent.  Yes, organizationally the board of directors can dissent without reprisal, but they don’t know the business well enough to dissent in the most meaningful way.

In medieval times the jester was an important player in the organization.  He entertained the court but he also played the role of the dissenter.  Organizationally, because the king and queen expected the jester to demonstrate his sharp wit, he could poke fun at them when their ideas didn’t hang together.  He could facilitate dissent with a humorous play on a deadly serious topic.  It was delicate work, as one step too far and the jester was no more.  To strike the right balance the jester developed deep knowledge of the king, queen and major players in the court.  And he had to know how to recognize when it was time to dissent and when it was time to keep his mouth shut.  The jester had the confidence of the court, knew the history and could see invisible political forces at play.  The jester had the organizational responsibility to dissent and the deep knowledge to do it in a meaningful way.

Companies don’t need a jester, but they do need a T-shaped person with broad experience, deep knowledge and the organizational status to dissent without reprisal.  Maybe this is a full time board member or a hired gun that works for the board (or CEO?), but either way they are incentivized to dissent in a meaningful way.

I don’t know what to call this new role, but I do know it’s an important one.

Image credit – Will Montague

If you don’t know the critical path, you don’t know very much.

ouija queenOnce you have a project to work on, it’s always a challenge to choose the first task.  And once finished with the first task, the next hardest thing is to figure out the next next task.

Two words to live by: Critical Path.

By definition, the next task to work on is the next task on the critical path.  How do you tell if the task is on the critical path?  When you are late by one day on a critical path task, the project, as a whole, will finish a day late.  If you are late by one day and the project won’t be delayed, the task is not on the critical path and you shouldn’t work on it.

Rule 1: If you can’t work the critical path, don’t work on anything.

Working on a non-critical path task is worse than working on nothing.  Working on a non-critical path task is like waiting with perspiration.  It’s worse than activity without progress.  Resources are consumed on unnecessary tasks and the resulting work creates extra constraints on future work, all in the name of leveraging the work you shouldn’t have done in the first place.

How to spot the critical path? If a similar project has been done before, ask the project manager what the critical path was for that project.  Then listen, because that’s the critical path.  If your project is similar to a previous project except with some incremental newness, the newness is on the critical path.

Rule 2: Newness, by definition, is on the critical path.

But as the level of newness increases, it’s more difficult for project managers to tell the critical path from work that should wait.  If you’re the right project manager, even for projects with significant newness, you are able to feel the critical path in your chest.  When you’re the right project manager, you can walk through the cubicles and your body is drawn to the critical path like a divining rod.   When you’re the right project manager and someone in another building is late on their critical path task, you somehow unknowingly end up getting a haircut at the same time and offering them the resources they need to get back on track.  When you’re the right project manager, the universe notifies you when the critical path has gone critical.

Rule 3: The only way to be the right project manager is to run a lot of projects and read a lot.  (I prefer historical fiction and biographies.)

Not all newness is created equal.  If the project won’t launch unless the newness is wrestled to the ground, that’s level 5 newness. Stop everything, clear the decks, and get after it until it succumbs to your diligence.  If the product won’t sell without the newness, that’s level 5 and you should behave accordingly.  If the newness causes the product to cost a bit more than expected, but the project will still sell like nobody’s business, that’s level 2.  Launch it and cost reduce it later.  If no one will notice if the newness doesn’t make it into the product, that’s level 0 newness. (Actually, it’s not newness at all, it’s unneeded complexity.)  Don’t put in the product and don’t bother telling anyone.

Rule 4: The newness you’re afraid of isn’t the newness you should be afraid of.

A good project plan starts with a good understanding of the newness.  Then, the right project work is defined to make sure the newness gets the attention it deserves.  The problem isn’t the newness you know, the problem is the unknown consequence of newness as it ripples through the commercialization engine. New product functionality gets engineering attention until it’s run to ground.  But what if the newness ripples into new materials that can’t be made or new assembly methods that don’t exist?  What if the new materials are banned substances?  What if your multi-million dollar test stations don’t have the capability to accommodate the new functionality?  What if the value proposition is new and your sales team doesn’t know how to sell it?  What if the newness requires a new distribution channel you don’t have? What if your service organization doesn’t have the ability to diagnose a failure of the new newness?

Rule 5: The only way to develop the capability to handle newness is to pair a soon-to-be great project manager with an already great project manager. 

It may sound like an inefficient way to solve the problem, but pairing the two project managers is a lot more efficient than letting a soon-to-be great project manager crash and burn.  After an inexperienced project manager runs a project into the ground, what’s the first thing you do?  You bring in a great project manager to get the project back on track and keep them in the saddle until the product launches.  Why not assume the wheels will fall off unless you put a pro alongside the high potential talent?

Rule 6: When your best project managers tell you they need resources, give them what they ask for.

If you want to deliver new value to new customs there’s no better way than to develop good project managers.  A good project manager instinctively knows the critical path; they know how the work is done; they know to unwind situations that needs to be unwound; they have the personal relationships to get things done when no one else can; because they are trusted, they can get people to bend (and sometimes break) the rules and feel good doing it; and they know what they need to successfully launch the product.

If you don’t know your critical path, you don’t know very much.  And if your project managers don’t know the critical path, you should stop what you’re doing, pull hard on the emergency break with both hands and don’t release it until you know they know.

Image credit – Patrick Emerson

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner