» Why Projects Go Off the Rails

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.

Incomplete vision statements for the project
Inadequate effort by sales and marketing while the product is being developed
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

2019-May-16

Articles