Category: Other topics

Why Projects Go Off the Rails

One of the advantages of being a consultant is that it develops great breadth of experience. 

Over the course of more than 30 years of providing consulting services in product development and manufacturing, I have worked on dozens of projects across a broad spectrum of technologies and industries.  I have experienced many corporate cultures and worked closely with all kinds of management teams.  I have seen products become very successful.  And I have seen products fail. 

At the end of every project, I write a summary of what happened.  What went well?  What went awry?  What did I learn?  If I were to do this project again, what would I do differently?

These summaries are personal notes that I have been keeping since I started working in product development.  Over the years some clear patterns have emerged regarding indicators of success or failure of a project.

This article presents a few of the most important lessons learned in my years of consulting.

What Are We Trying To Do?

It’s surprising how many companies launch new – and usually expensive – projects without a clear vision of why the project is being launched and what the ultimate objectives are and how they plan to achieve the objectives. 

Granted, nearly every project starts with a vision statement – a statement of “This is what we are going to achieve.”  Quite often these vision statements include glowing descriptions of all the benefits that will accrue from successful completion of the project.  But most project vision statements are woefully inadequate, which is usually the first indicator that the project is not going to go well.

Preparation of a vision statement is a mini-project unto itself, requiring a fair amount of research, consideration, discussion and debate.  The specific areas of research, evaluation and discussion that go into preparing a vision statement will vary depending on the nature of the project.  A few considerations that should be included in every vision statement are:

• Why are we doing this?  How will this benefit the company?
• What risks are associated with this undertaking?  How will the company be affected if this project fails?
• What resources (money, personnel, outside services) will be needed to perform this project?
• Are all of these resources available in sufficient quantity to complete the project?
• What are the criteria for success?  How will we determine if this project succeeds or fails?
• Who has ultimate responsibility for management of this project?  Who will make sure it stays on track, and will take action if it drifts off track?

These are the first and most fundamental questions that should be addressed when preparing a vision statement for any project.  When developing a new product, a number of questions specific to the product being developed should be asked and answered.  Preparing a vision statement for new products will be the topic of a future article.

When I am preparing a vision statement, the question I continually ask myself as I am writing is:  If I were being asked to invest my personal savings in this project, will this vision statement give me all the information I need to be able to make that decision? 

The next time you are wrapping up a vision statement for a new project, try doing the following before presenting the vision statement to the rest of your team:  

Ask yourself the same question.  “Does this vision statement give me all of the information I would need to decide whether I would invest in this project?” 

With that question in mind, re-read the vision statement from start to finish.  After that re-read, I suspect that you’ll want to add some information and make some revisions.  Don’t submit the vision statement to the rest of the team until you can honestly answer yes to that question.

What is the Marketing Team Doing?

What is the single most reliable indicator of the success or failure of a product development project?

In my experience, the actions of the sales/marketing team during product development is the number one indicator of a project’s ultimate success or failure.

If I’m managing development of a new product and I hear little or nothing from the sales/marketing team during product development, that’s a nearly certain death knell for the product. 

However, if members of the sales/marketing team are peppering me with questions such as…

• “When can you give me working prototypes?  Three different distributors want to see the product.”
• “I’m drafting MOU’s with several companies who want to retail this product.  What date can I commit to the product being delivered to them?”
• “I need to get together with you to make sure we’re in sync on the feature set of this product.  I need to put that into some marketing literature that is going out to 20 prospective new accounts.”

…then this product has a very high probability of success.

When expressed this way, this lesson seems about as subtle as a bucket of cold water poured over your head.  But it’s surprising how often sales and marketing teams do very little marketing and pre-selling while a new product is under development. 

If you’re developing a new product, assign at least one person – and preferably a small group – from your sales/marketing team to have dedicated responsibility for pre-selling the product while it’s being developed.  If they are getting letters of intent and MOU’s and pre-orders before the product has entered mass-production that will put a lot of pressure on the product development team.  But it’s a good kind of pressure to have.  On the flip side of that coin, if they are having trouble generating interest in the new product, it’s a sign that the product needs to be re-evaluated.

Did I Just Miss Something?

Virtually every project will experience at least a few “surprises” that delay the project and add to its cost.  On many projects, such surprises occur frequently and sometimes they are very expensive.  And these delays and cost increases will accumulate over the course of the project.  Sometimes the delays and cost overruns grow to the point where the project has to be canceled. 

It’s impossible to completely eliminate snags and delays in a project, but you can do a lot to keep them to a minimum.

Far and away, the most common cause of these “surprises” is poor communication.  Something changes or there is new information that is pertinent to the project, and not everyone gets the message.  Why does this happen?

Even projects that have a small development team have a surprisingly large number of communication channels.  As an example, let’s look at a typical product development team in a small company. 

• Senior management (usually the CEO) is responsible for top level strategy and decision making
• There might be two people in Sales & Marketing who must determine the market requirements for the product, make sure the product meets the marketing requirements, and develop sales channels.
• The product development team will have a few engineers – electrical, mechanical, software, industrial design, etc.
• Typically, there will be a handful of 3^rd parties who provide specialty services such as prototyping, reliability testing, regulatory approval and manufacturing.
• There will be suppliers who must provide components and materials that meet your requirements and specifications.

Even the smallest of projects can easily have 15-20 parties who have various levels of responsibility for completion and success of the project.

Now consider the possible channels of communication between the parties.  You might have weekly team meetings.  You might have frequent conference calls with the 3^rd party service providers.  People can communicate with each other by email, text message, Skype, WhatsApp and WeChat.  Documents can go flying back and forth as attachments to any digital messaging medium.  And finally, there are the informal channels of communication.  A mechanical engineer can bump into an electronic engineer in a hallway and say. “By the way, I just saw something that you should probably know about.”

If you tally up all the possible channels of communication for a small development team like this, the number climbs well into the thousands.  And the number of messages that pass through all these channels over the course of the project will quickly climb into the hundreds of thousands. 

What kinds of information might not get to people who need to know? 

• A supplier sends a message that a key component in the product will no longer be available in three months, and the message gets buried in an email inbox.
• There is a significant change in the financial situation of the company and the CEO is hesitant to share the news. 
• A competitor just launched a product that makes your new product obsolete before it’s launched. 
• Prototypes of the product work fine when made by hand in the engineering lab, but it will be a nightmare to put into mass-production. 
• An engineer made a design change, and the updated documentation didn’t get put into the master design file. 

This is just a small sample of things I have seen.  This list could easily be as long as an encyclopedia.

Consider this spiderweb of communication channels and all of the bits of information that must travel through that web and get to all of the right parties.  When a project is in high gear, there can be 10 to 100 pieces of information generated each day that must be relayed to someone.  That’s 200 to 2000 key developments per month.  If you can keep the rate of communication failures down to 1%, between 2 and 20 key messages will get lost each month.  That illustrates how and why miscommunication is the number one cause of delays and cost overruns in projects.

The next question is:  How do you manage this?

Whole books have been written about managing communications in the organization.  In my experience the most effective means of managing communications – and mitigating miscommunication – is to have a dedicated project manager who has obsessive attention to detail. 

A good project manager will:

• Be included on all communications related to the project
• Read all communications and make sure s/he understands the implications of all new information
• Have a brief meeting at least once a week with each member of the product development team – from the CEO on down – to check on progress and inquire about anything new that has occurred
• Convert verbal communications to writing, and share the written information with team members as necessary
• Make sure that affected parties know about and understand the implications of all new information
• Assiduously and meticulously maintain all project documentation and make sure the engineering team does the same for all product specifications

These are the six golden rules for managing communications on a project. 

Of course, there is a lot more to good project management than communications management.  A future article will deal at length with project management.

This is a summary of what I call the “Big Three” causes of projects running into problems. 

1. Incomplete vision statements for the project
2. Inadequate effort by sales and marketing while the product is being developed
3. Miscommunications

But the list doesn’t stop at three…

What Else Can Go Wrong?

Future articles will cover other common causes of projects going awry and will offer suggestions for how to avoid those problems.  Some of the topics will be:

• How Gantt charts can make your project go well (and how they can destroy a project)
• Shortcuts that ultimately make the project cost more and take longer
• Equity stakes – a leading cause of blindness and insanity in start-ups

Do patents pay off?

Is it worthwhile to incur the effort and expense to get patents?

The answer (squishy but true) is: It depends on how good the underlying idea is. This case study is an example of a very good underlying idea and how it made money for the inventor. It is an example of what to look for when trying to decide whether to pursue a patent.

A former work colleague of Clint was an inveterate inventor. He would spend hours on end thinking about products and technology, trying to come up with new ideas and inventions. The guy was prolific – he generated a lot of ideas in a lot of different fields. He formed a small business, Positive Technologies, as a vehicle for commercializing some of his new ideas.

One day he started talking to Clint about how images are rendered (or drawn) on LCDs. This was back when CRTs were everywhere and LCD display panels were relatively rare. The inventor used words like “inefficient” and “dumb” and “stone age” to describe the state-of-the-art display rendering algorithms. Then he started talking about a better way to render images on LCDs. It entailed a completely new approach that was intelligent and efficient and would improve display quality; would allow displays to be updated at a higher rate; and would prolong the life of the LCD.

They continued to discuss this new idea over the coming days. The discussion eventually became fairly technical, getting into details of cumulating DC bias voltages and liquid crystal relaxation rates and differential image mapping. It took awhile to absorb the concept, but eventually it became clear that every display in the world (at that time) really did use a “stone age” algorithm to render images, and that this new method was indeed superior. Clint pointed out that no microprocessor in the world had sufficient processing power to deploy this new algorithm. The inventor’s response was, “So what! Remember Moore’s Law! In three years, chips will be fast enough.”

This better algorithm was groundbreaking new technology that had the ability to change the way displays work — an idea that definitely merited a patent application. The inventor asked Clint to write the disclosure. (The disclosure is the main body of the patent, in which the invention is disclosed, or described in detail.) He asked Clint to do this because (paraphrasing his words), “You understand the technology. You write better than the average lawyer. And you cost less than a patent attorney.”

Clint wrote the first draft of the patent disclosure for this invention. The patent next passed through the hands of patent attorneys and patent examiners and then through the patent approval process and was finally issued. It has become a landmark patent in the display world.

As technology gradually caught up with this new idea, display manufacturers around the world began adopting the new algorithm, and the inventor pursued licensing arrangements with all of the major display manufacturers. This algorithm is now used in virtually every video display made today and the inventor has reaped handsome rewards from the better technology that he invented.

The lessons in this case study: Patents can be valuable – very valuable – but to become valuable, there are a couple of requirements. The underlying idea must be very strong and must enable new technology that improves significantly on existing technology. And you must pursue the patent diligently. It’s not enough to just get a patent. You must develop and sell the technology, or you must sign up licensees (or both).

A patent doesn’t make money; enforcing the patent makes money.

This is an example of a role Clint can fill in product development. He can help identify and define patentable new ideas, and can assist with the patent preparation process.

If you would like an unbiased assessment of a new idea, if you would like help refining the idea and identifying patentable inventions, if you would like help with patent preparation, please contact Clint.

Two guys in a condo in La Jolla build some rockets

In the mid-80s Clint teamed up with another technology lover (Bob Hotto) to form a two-man tech company working from a condo in La Jolla. They were developing products – some on contract for other companies and some speculative product development on their own.

The General Dynamics (GD) facility that made Atlas and Titan-Centaur rockets was just a few exits down the freeway. A friend of a friend heard that GD was going to award a big engineering project – a project that entailed complete overhauls of the motors and motor control systems that are used to weld the rocket bodies. This sounded like an interesting project.

With some finagling and bit of luck, they managed to get their name added to the bid list for the project. About a month later General Dynamics invited Bob and Clint to a project preview meeting to go over the requirements of the project and the criteria for submitting proposals. The other companies who were bidding on the project were also at that meeting. This consisted of teams from every major aerospace engineering firm in America (along with Bob and Clint).

Each company had sent a team of between 6 and 10 people to the meeting. Each company had a total staff of between 5000 and 25,000 employees. All of the companies had long histories of doing contract work for GD, and it seemed like everybody in the group knew each other from past projects. This was a meeting of the professional rocket builders club. In their eyes, the rockets being assembled out on the factory floor were about as exciting as oversized tin cans. The closest Clint had been to a rocket prior to that meeting was watching launches from Cape Canaveral on TV. Comparing Clint and Bob to the other project bidders made David v. Goliath seem like a close match.

Everybody at the meeting treated Clint and Bob politely, not unlike the way in which a kindergarten teacher is polite to her not-so-bright pupils.

At the conclusion of the pre-proposal meeting everybody was given the RFP package – a stack of notebooks about three feet high. Each notebook was filled with pages of project requirements, quality standards, safety criteria, government regulations, and other insomnia-curing minutiae. Everybody had ten days to review all the documents, prepare a proposal, and then return to GD to present their proposals.

“We didn’t have a snowball’s chance in…”

Clint and Bob didn’t have a snowball’s chance in a pizza oven to win that contract. They could have offered to do the job for free and wouldn’t have been awarded the contract because the perceived risk was too high. It was impossible for them to read and digest the entire RFP package in ten days, much less write a proposal that addressed every point in the package. They had three options:

1. Go through the motions; write and submit a proposal; and get promptly dismissed.
2. Tell GD that they didn’t want to waste anybody’s time, and request to be removed from the bid list.
3. Ignore the rules, do what they do best, and try to win the project.

I’m sure you already know which option we chose. We found the five key pages buried in the RFP – the pages that listed the technical requirements for the project. We made copies of those pages then set the whole pile of notebooks in the back of a closet. Then we got to work designing and assembling a fully functional prototype of the system that we proposed to deliver to GD. We ordered components for rush delivery; we had some custom parts fabricated at a local machine shop; and we pulled a few all-nighters designing, assembling and testing.

Ten days passed very quickly and it was time to present proposals. Clint and Bob were the last of the bidders scheduled to present to GD. When we entered the meeting room, all of the GD engineers looked at their watches, wondering if they could usher us out of the room in time for lunch.

The kabuki dance

The other engineering firms had followed the rules perfectly – they knew the kabuki dance of aerospace contracts. They brought in teams of five or six senior managers. The 3-foot tall stacks of notebooks had morphed into stacks of proposals that were equally tall and that regurgitated every point in the RFP and added a few more points of their own. They presented slide shows (in the glorious days before PowerPoint) full of org charts and flow charts and man-hour allocations and project phases and schedules for the coming year. Clint and Bob didn’t have any of that.

Clint and Bob started their presentation by laying their proposal on the table – a paper binder containing five pages typed double-spaced (because if it were single-spaced, it would have only been two and a half pages). Everybody looked at their watches again and squirmed in their chairs and scowled. Then Clint and Bob said that they didn’t want to go over the proposal because that wouldn’t be a good use of everybody’s time. The scowls around the table deepened. Clint and Bob said that they would prefer to show GD what they intended to deliver. The scowls were now mixed with looks of confusion. Clint and Bob weren’t doing the kabuki dance properly!

We set a box on the table. We pulled our prototype system out of the box, plugged it into the wall, and told the GD engineers, “If we are awarded the project, this is what we will deliver, and this first unit can be installed and up and running within a week.” The prototype had a complete operator control panel and functional motors with enough torque to rotate the rocket bodies. It met or exceeded all requirements for accuracy, repeatability and reliability.

The scowls around the table turned to smiles, and then to grins that they couldn’t suppress. Every GD employee in the room took turns pushing buttons and rotating knobs on the control panel and watching the motors turn. After about 10 minutes of testing the prototype, they said, “Officially, we have to go through a series of internal approval procedures, but unofficially, you’re getting this project. Your bid has the lowest price and there is almost zero risk associated with it because a complete functional system is sitting on the table at our facility.”

That prototype was the first of six controllers to be installed at GD, and it started a three-year stream of nearly continuous projects at General Dynamics for the little two-man company.

To this day, every Atlas and Titan-Centaur rocket that is launched is made using equipment that Clint and Bob designed, assembled and installed at General Dynamics. And that 3-foot-tall stack of notebooks is probably still collecting dust in a closet in a condo in La Jolla.

Lessons

There are three important lessons in this case study:

• Don’t be intimidated by bigger, more experienced competitors. Your small size makes you more nimble and responsive.
• Recognize your strengths and have faith in them. If you think you can do it and if the big boys tell you that you can’t do it, believe in yourself and ignore the big boys.
• When something looks impossible, often it’s because the “impossible” things are blocking your view. Shove the pile of impossible things into a dark corner and clear your desk. Then try to understand the real goals and figure out how you can achieve them.

If you could benefit from some “outside the box” thinking to help you compete – against the big boys or against your peers – please call or email Clint to see if he can help you.