Who Pulls the Line?

by: stacey - April 3rd, 2012   Filed under: Leadership, Project Management Add Comment

I have always been amused at how far behind the software industry is to the manufacturing industry.  There is no question, of course, that software has by and large replaced manufacturing in America.  There is no question that Americans work more with creating new ideas than with tangible goods.  Still, in manner of thinking and management of process, software lags behind.

Take, for example, the software project in trouble.  In manufacturing, each person involved in the job is responsible for overall success.  When the machines are being set up prior to starting to make something, the setup men are responsible for noting when something is wrong with the tooling and letting people know.  Before the line starts up, the setup men and the line leader are responsible for running a test run and validating that they are building the right thing, that it meets specifications, and that there is nothing wrong with the end result before they waste the company’s money building thousands of wrong widgets.  Once the line starts up, each worker is responsible for stopping the process if they discover something wrong.  Toyota and other manufacturers have been famous since the 80s for the ubiquitous “quality line”, the magic line that any worker can pull and is responsible to pull if they see that the process has gone off the tracks.  Manufacturing knows that the longer you wait to address a problem, the more it costs, and that you are better off to stop and fix things and miss your deadline than you are to deliver the wrong thing.

Not so in the software world. The industry is rife with discussion on the topic.  New articles pop up online.  Depending on who you read, the Project Manager is responsible, the development manager is responsible, the BA is responsible, the list goes on and on.  Some (rightly) declare that, like in Manufacturing, everyone is responsible.

One could debate this all day long, but the reality is, we’re all asking the wrong question.  People want to do good work (unless they’re just worthless employees).  They want to do the right thing.  They don’t like to waste their time.  Everyone is willing to declare that projects are going down the wrong path if it is the right thing to do.  Assuming you believe that about your employees (and if you don’t, you have the wrong staff), why do they not pull the line?  Why is not pulling the line an epidemic in software development and project management?

The answer is because corporate leadership is teaching us all that pulling the line is wrong.  Leadership shoots the messenger 99 times out of 100.  The Death March must continue.  No one wants to tell the customer we’ll be late.  We’re teaching our workers through an almost Pavlovian punishment model that somehow the customer will be happier if we deliver a half-working thing that isn’t what they asked for instead.  This is driven by a lot of things- fear of conflict with the customer (pretending there won’t be conflict when we deliver garbage), fear of telling the stockholders (pretending the stock isn’t affected by delivering garbage), fear of trying to stop the inertia or being called a finger pointer (pretending that if someone has screwed up and not taken responsibility for it, the finger should not be pointed).

Of all the problems in corporate culture today, this, more than any other, needs to change.  In the last fifteen years I have changed companies a half-dozen times.  A number of my friends have changed jobs as many as a dozen.  In almost every case, the root cause has traced back to this.  Company leadership refuses to face their problems and shoots messengers until either the company folds or so many projects fail that there is a significant purge of personnel within the company.  You will never, ever deliver the right thing until you enable your employees to be able to stop delivering the wrong thing.  If you are a corporate leader out there today, ask yourself some questions:

  • Do I have a culture in my company where people can pull the line without fear?
  • Do I even have a line?  Is there a true, properly managed process for raising the red flag on projects with appropriate visibility?
  • Do people know the process for raising red flags?  Is making sure they know how part of project kickoff and project management?
  • Is the process effective?  Are there actual action items can be addressed as a result of the red flag process?  Are they monitored and followed through on?
  • Do I have a REWARD system for raising the flag?  If raising the flag saves me from wasting money, why on earth not?
  • If I am responsible for leading, is it not ultimately my fault if we fail due to flags not raised?  Isn’t my own career ultimately on the line here?

There is a popular saying in the corporate IT world that has always amused me:  ”No one was ever fired for buying IBM.”  We live in a risk-adverse culture where the main risk we avoid is conflict.  I challenge you to address this problem and pound the solution home until you overhear this in meetings in your company instead:  ”No one was ever promoted for covering up problems”.

Engaging the Right Customer, Part 2: Market Value

by: stacey - April 2nd, 2012   Filed under: Customer Relations, Product Management Add Comment

Yesterday, I talked about engaging the right customers on the right features to know you are getting the best feedback.  Products nowadays try more and more to be different things to different market segments.  How well your product meets the needs to many different market segments is important to its long-term growth.

Today I’m going to talk about a less comfortable subject- the value of your various customers.  Or, more specifically, the value of each market segment.  Do you understand the following about the markets you are trying to address:

  • How many customers are there in each market?
  • How much revenue will you gain per customer?  How much profit?
  • What does the acquisition cost per customer look like?  What is the lead time?
  • Does the costs to address the full needs of each market provide enough money to make that market worthwhile?
  • Is the market for new feature X or bug Y important enough to pay for the cost or addressing the feature?

Knowing and understanding these numbers is a critical component of planning and prioritizing your backlog.  You must plan not only to take care of your customers, but to use the company’s resources responsibly.  With limited resources, some of your customers will simply have to wait for certain things.  Working like this will help your product make more money faster, allow it to grow available resources to fix problems and build new features, and get everyone what they want faster.  In some cases, it may lead to a counter-intuitive business decision- accepting that the cost to maintain your product in market X is not worth the value of the market in the foreseeable future.

The Customer is Always Right. Make Sure You Pick the Right Customer.

by: stacey - March 30th, 2012   Filed under: Agile, Business Analysis, Product Management Add Comment
As a member of any software development project, you have a lot of customers.  There is the customer who makes the buy decision.  There is your own executive management that control your own budget.  There is your product manager.  There is your outside customers, both their management and their users.  All of these folks should be engaged in your project, of course, and if you can get any of your customers who do day-to-day use of your product in front of it during your development process, to do usability studies, to comment on what works and what doesn’t, that’s almost always your best bet at arriving at the right product in the end.
But how do you pick which of those users to talk to?
There is, of course, the tried and true method- that is, anyone that will volunteer.  There’s the more tried but less true method, which is engage the customer that makes the most noise, or the customer that is your largest client.  The truth here is, you should choose based on an understanding of your market.
What is your product?  What market segment is it aimed at?  If it is trying to cover broad territory, what market segment is this feature most valuable to?  I have been part of projects in the past where the largest clients were engaged on all aspects of the redesign of a large and significant product.  The feedback was excellent, and they worked well with us.  There was only one problem.  They gave insightful and thoughtful feedback on the features they needed.  They were engaged.  They cared.  On the features that they didn’t need, the features that were for our smaller customers that made up a large segment of our overall population, however, this is where the real problem was.  They were trying to help.  They really were.  But how they tried to help on features they didn’t need was giving feedback based on their guesses of what smaller companies might do, what their workflows might be, or sometimes they just rubber stamped whatever solution they were shown.  The feedback in those areas was useless, and what was worse, they never told us that they didn’t use those features, so we didn’t know it was useless until we rolled the product out later.  We got hammered by our smaller markets.  The shame here isn’t on the folks that tried to help us.  It was on us.  We didn’t know our big clients well enough to know which parts wouldn’t matter to them, and we didn’t vet enough of our system with our smaller markets.
This is why I advocate doing a product analysis of your software and keeping it up to date.  Not only should you be keeping up with what markets your product is for, you should create a matrix that illustrates what markets each feature is meant for.  You should keep up with what markets each client is a part of.  These two tools will help you keep the right customer engaged at the right time to improve your product and keep it strong.