Shipulski On Design

Archive for September, 2016

Urgency is important, but it’s not everything. It creates focus, but washes out the radical fringe. It’s easy to measure, but easy to measure doesn’t mean it’s the best thing to work on.

In the heat of the moment urgency is king. Frantic project managers take shortcuts to meet a deadline defined fourteen months ago; Lean Startup-ers ready-fire-aim their way from pivot to pivot; And resources flow to projects that are scheduled to finish soonest.

Urgency is attractive because it’s so clear cut, so objective, so easy to measure.

Due Date – Today’s Date = Urgency.

There’s always consensus on today’s date, everyone knows the due date and subtraction come easily.  There you go. No debate, no discussion.  This project has more urgency than that one.  Just do the math. But where did the due date come from? Did the work content define the due date?  If so, projects with the least work content, with their immanent due date, are the most urgent and resources should flow to the shortest projects.  Did the annual trade show set the due date?  If so, projects with earliest trade shows should get priority.  Did the CEO define the due date for reasons unknown to mere mortals?  If so, projects that finish before the declared date should get priority and projects that finish after the due date should get put on the back burner.

Project scope defines work content and start date plus work content equals due date.  For two projects with equal work content, the project that starts first has more urgency. Should projects start sooner to increase urgency? Should project plans pile on resources to pull in the completion date to increase urgency? Should project managers strip the sizzle out of projects so they finish sooner?

Urgency isn’t important. Importance is important.

The problem with importance is its subjective nature. Because there is no objective measure of importance, judgement is required.  The cold scoring systems to rank projects don’t work.  There are no scoring rubrics, no algorithms, no customized weighting factors that can objectively quantify importance.  It’s either important or it isn’t.  It’s important in the chest, or it’s not. It’s all about judgement.

The context defines what’s important. Market share has dropped five years in a row, some projects are more important than others. Market share has increased five years in a row, a different set of projects is important. Can’t make payroll, urgency-based project selection is best. Technology is long in the tooth, it’s important to fund projects that buy or build new technology. Which projects are most important? It depends.

The best way to sort projects by importance is to ask “Is this project important?” and have a discussion. Some projects will have more upside and others will have more certainty.  Some could create new markets and other will proved two percent growth in a guaranteed way. Which are most important? It depends.

Importance is relative. Use the “Is this project important?” methodology to force rank your projects by importance.  Once complete, take a step back and ask if the ranked list makes sense.  Reshuffle if needed.  Starting from the top, fully staff the most important project. For the next most important project, allocate the remaining resources and repeat the process project-by-project until the resources are gone.  This process ensures the most important projects on the list get the resources. But there’s a hole in the methodology.

What if our innate urgency bias keeps the most important projects off the list?

Image credit – Stephen Depolo

There’s a huge amount of energy required to help an organization do new work.

At every turn the antibodies of the organization reject new ideas.  And it’s no surprise.  The organization was created to do more of what it did last time.  Once there’s success the organization forms structures to make sure it happens again.  Resources migrate to the successful work and walls form around them to prevent doing yet-to-be-successful work. This all makes sense while the top line is growing faster than the artificially set growth goal.  More resources applied to the successful leads to a steeper growth rate.  Plenty of work and plenty of profit.  No need for new ideas.  Everyone’s happy.

When growth rate of the successful company slows below arbitrary goal, the organization is slow to recognize it and slower to acknowledge it and even slower to assign true root cause.  Instead, the organization doubles down on what it knows.  More resources are applied, efficiency improvements are put in place, and clearer metrics are put in place to improve accountability.  Everyone works harder and works more hours and the growth rate increases a bit.  Success.  Except the success was too costly.  Though total success increased (growth), success per dollar actually decreased.  Still no need for new ideas.  Everyone’s happy, but more tired.

And then growth turns to contraction. With no more resources move to the successful work, accountability measures increase to unreasonable levels and people work beyond their level of effectiveness. But this time growth doesn’t come.  And because people are too focused on doing more of what used to work, new ideas are rejected.  When a new idea is proposed, it goes something like this “We don’t need new ideas, we need growth.  Now, get out of my way.  I’m too busy for your heretical ideas.”  There’s no growth and no tolerance for new ideas.  No one is happy.

And then a new idea that had been flying under the radar generates a little growth.  Not a lot, but enough to get noticed.  And when the old antibodies recognize the new ideas and try to reject it, they cannot.  It’s too late.  The new idea has developed a protective layer of growth and has become a resistant strain.  One new idea has been tolerated. Most are unhappy because there’s only one small pocket of growth and a few are happy because there’s one small pocket of growth.

It’s difficult to get the first new idea to become successful, but it’s worth the effort.  Successful new ideas help each other and multiply.  The first one breaks trail for the second one and the second one bolsters the third.  And as these new ideas become more successful something special happens.  Where they were resistant to the antibodies they become stronger than the antibodies and eat them.

Growth starts to grow and success builds on success.  And the cycle begins again.

Image credit – johnmccombs

The past has past, never to come again.  But if you tell yourself old stories the past is still with you.  If you hold onto your past it colors what you see, shapes what you think and silently governs what you do.  Not skillful, not helpful.  Old stories are old because things have changed.  The old plays won’t work. The rules are different, the players are different, the situation is different.  And you are different, unless you hold onto the past.

As a tactic we hold onto the past because of aversion to what’s going on around us. Like an ostrich we bury our head in the sands of the past to protect ourselves from unpleasant weather buffeting us in the now.  But there’s no protection. Grasping tightly to the past does nothing more than stop us in our tracks.

If you grasp too tightly to tired technology it’s game over.  And it’s the same with your tired business model – grasp too tightly and get run through by an upstart.  But for someone who wants to make a meaningful difference, what are the two things that are sacred? The successful technology and successful business model.

It’s difficult for an organization to decide if the successful technology should be reused or replaced.  The easy decision is to reuse it.  New products come faster, fewer resources are needed because the hard engineering work has been done and the technical and execution risks are lower.  The difficult decision is to scrap the old and develop the new.  The smart decision is to do both.  Launch products with the old technology while working feverishly to obsolete it.  These days the half-life of technology is short.  It’s always the right time to develop new technology.

The business model is even more difficult to scrap. It cuts across every team and every function.  It’s how the company did its work.  It’s how the company made its name. It’s how the company made its money.  It’s how families paid their mortgages.  It’s grasping to the past success of the business model that makes it almost impossible to obsolete.

People grasp onto the past for protection and companies are nothing more than a loosely connected network of people systems.  And these people systems have a shared past and a good memory.  It’s no wonder why old technologies and business models stick around longer than they should.

To let go of the past people must see things as they are.  That’s a slow process that starts with a clear-eyed assessment today’s landscapes. Make maps of the worldwide competitive landscape, intellectual property, worldwide regulatory legislation, emergent technologies (search YouTube) and the sea of crazy business models enabled by the cloud.

The best time to start the landscape analyses was two years ago, but the next best time to start is right now.  Don’t wait.

Image credit – John Fife

If the work is new, there is no best practice.

When you read the best books you’ll understand what worked in situations that are different than yours.  When you read the case studies you’ll understand how one company succeeded in a way that won’t work in yours.  The best practices in the literature worked in a different situation, in a different time and a under different cultural framework.  They won’t work best for you.

Just because a practice worked last time doesn’t mean it’s a best practice this time.  More strongly, just because it worked last time doesn’t mean it was best last time. There may have been a better way.

When a problem has high urgency it should be solved in a fast way, but if urgency is low, the problem should be solved in an efficient way. Which way is best? If the consequences of getting it wrong are severe, analyses and parallel solutions are skillful, but if it’s not terribly important to get it right, a lower cost way is better.  But is either the best way?

The best practices found in books are usually described a high level of abstraction using action words, block diagrams and arrows.  And when described at such a high level, they’re not actionable.  You may know all the major steps, but you won’t know how each step should be done.  And if the detail is provided, the context of your situation is different and the prescriptive steps don’t apply.

Instead of best practices, think effective practices.  Effective because the people doing the work can do it effectively.  Effective because it fits with the capability and capacity of the people doing the work.  Effective because it meshes with existing processes and projects.  Effective because it fits with your budget, timeline and risk profile.  Effective because it fits with your company values.

Because all our systems are people systems, there are no best practices.

image credit — johnwayne2006