It’s February 2009, and you are in some way affected by perhaps the worst economic conditions since the Great Depression. Your company is probably “hunkering down,” “weathering the storm,” or <insert metaphor of choice here> until the financial crisis is over.
Given this situation, businesses can’t afford to waste money. Actually, businesses can never really afford to waste money. But they do. Lots of it. An inconceivable amount of money is wasted every day in businesses around the globe because managers allow unproductive activities to occur. Think of five ways your company wastes money in your opinion. I bet you can do this in less than two minutes.
Why do businesses allow such waste? Because managers don’t know how to measure and improve productivity from more than some narrow perspective they learned along the way. Many don’t know how to do this at all.
Cutting costs is often necessary during tough economic times, but cost-cutting usually has a significant detrimental effect – and cost cutting doesn’t address productivity issues due to inefficient processes, poor communication practices, mismanaged projects, and many other factors.
Before implementing cost-cutting measures that might have damaging long-term effects, managers must be engaged in productivity initiatives with measurable short-term and long-term outcomes.
You might be wondering, “What is a productivity initiative?” A productivity initiative has the goal of sustainable improvements that provide better results (profit, time to market, quality, etc.) at roughly the same fixed costs, or even lower fixed costs if possible. There will always be an initial non-recurring cost to implement sustainable improvements, but the long-term ROI should be significant enough to fund the initiative.
Sustainable improvements might involve eliminating non-value-adding activity; improving communication; enhancing project management methodology and tools; strengthening leadership; or improving relationships with customers and stakeholders.
When businesses have plenty of money and clearly see the benefit of completing projects more quickly, it’s easy to just throw money at certain projects because the ROI is favorable. During a recession this is a tougher decision because funds are more limited and business leaders must spend more cautiously.
Wouldn’t it be nice to get projects completed faster and at a lower cost? This might seem far-fetched but the reality is that most organizations have the potential to achieve faster cycles times while reducing their spending on projects. This was discovered by Preston Smith and Don Reinertsen during the research for their book Developing Products in Half the Time, New Rules, New Tools.
The situation gets worse for many companies during a recession because spending cuts often hinder productivity and increase project cycle times.
The best possible results are achieved by eliminating wasteful activities and implementing rapid development methodology. Outcomes must first be defined in terms of measurable financial gains and the ideal target for completion time. Is the objective to increase the cycle time with reduced spending, the same level of spending, or slightly increased spending? How fast can you afford to go, knowing that the quickest possible cycle time is very expensive?
Other questions must also be answered:
What is the cost of delay?
What are the bottlenecks that affect cycle time?
What deficiencies in the development process impact cycle time and cost?
Are you using the best lifecycle model to achieve rapid completion time?
Who is actively ensuring maximum efficiency for the given cycle time goals?
Do your risk management practices enable your team to achieve best-case results?
If these are not easy questions to answer and resolve, investing in the assessment and solutions for both short-term and long-term results is well worth the money. Do you think your company has potential to improve cycle times AND reduce project costs?
Recently, I met an engineering executive who shared some intriguing thoughts about product development.I couldn’t disagree when he said that hardly any executives and managers who are responsible for product development functions really understand product development.This is my experience as well.
The problem is that managers are overly focused on product design and engineering.In a mature company, managers must make decisions about project funding, priorities, product obsolescence, staffing, resource allocation, product requirements, processes, product architecture, risk mitigation, and many more aspects of product development.
How many people are good at all this?Not very many.Most product companies don’t even have someone in the position of “VP Product Development.”VP of R&D is another position that could be accountable for all this, but typically this is someone with an engineering or scientific background – not an expert with the breadth of skills necessary for product development.
Do you agree that very few managers have the necessary expertise?Any recommendations for improving this situation?
We often ask organizations if they have any “productivity initiatives” underway at their companies.Frequently, they reply, “Well, no.This year we’re focusing instead on better communication.”
As if there’s no connection between communication and productivity.
Ever stop to think about how much time is wasted reading things that are poorly written?Imagine, for example, that someone in your company has written a report describing the outcome, say, of a product evaluation.The outcome of this evaluation has implications for projects, standards, direction-setting for the whole company, so understanding how the evaluation was conducted, as well as who won, is important.
Unfortunately, the report isn’t very concise and, even worse, it’s boring.You’d think something as pivotal to the future of the company would be at least a little compelling, but the author(s) of this report have really managed to strip the topic of all its shine.Still, you and others manage to slog through it because it will be a topic for discussion at several meetings, and you need to be prepared.
Had the report been concise, well-organized and interesting to read, you could probably have read the whole thing in 15 minutes. Instead, it took you 30.Imagine the average salary of the people reading this report was $50,000 a year or $.43 a minute (not including benefits or other overhead costs often factored into employee cost).You, personally, wasted 15 minutes grinding through this awful essay.So did 25 other people who had the same reading assignment.
Think of the financial implications:
(minutes wasted * cost per minute) * number of people = lost productivity
So in our example,(15 wasted minutes * $.43) * 26 people = $167.70.
On just one poorly written report!
Better communication translates directly to better productivity and cost savings, whether it’s in the form of well-edited, well-delivered presentations, or succinct, interesting, effective documents.So, if you have a “communication initiative” at your company, you also have a “productivity initiative” underway.
How to Turn Murphy’s Law in Your Favor to Manage Risks in Product Development
Say you have been given a major assignment, one where your career hangs in the balance or where the future of your organization is at stake. What if you could predict the significant things that could go wrong[1] with your new assignment? ― and be able to prevent them or, at least, be able to manage them so they do not disrupt your objectives.This would put you in a proactive position rather than reacting to unanticipated trouble.
Many of us are faced with deploying or implementing major initiatives for our organizations. Whether it is developing a new product platform, introducing a major new product, or making a new strategic move, these events can carry sizeable risk to both your career and perhaps the future of your company.
The scientific community has been successfully dealing with the issue of risk reduction and mitigation for some time. Over the years, engineers and scientists have developed tools and methods to help them cope with unanticipated “failures.” They have learned successful ways to anticipate what may go wrong in order to prevent it. From risk analyses to FMEA (Failure Model and Effect Analysis) to Design of Experiments, these methods, when well understood and carefully applied, have proven to work (See appendix “B” for a glossary of risk).
Let’s take an example from science. Launching a new satellite into orbit is a major scientific challenge, to say the least. Engineers and scientists use methods to identify, predict, and mitigate those things that can negate the launch and that are likely to happen. Please note the two criteria: first, things that can negate and second, things that are most likely to happen. This second step is critical because the things that can happen are innumerable, but those that are likely to happen are fewer and thus more manageable.
Let’s apply Risk Management to projects in the business world.For example, merger and acquisitions are occurring with increasing frequency, and say you have been assigned the task of executing an acquisition. If you could predict those things that might ruin the project, prioritize them based on “likelihood,” and take steps to prevent them before they even occur, this would greatly improve your chances of success. Or, say you’ve been assigned to purchase and deploy a new CAD software application. Using the methodology, you could list in priority, before you even get started, those things that might interfere to the point of causing a “failure,” i.e., having to spend considerable money or ending up with no deployment. You would list and prioritize issues such as no acceptance by employees, lack of proper training, disruption of service, etc., and then plan how to address them, well in advance of their occurrence.
Now what if you could apply Risk Management methods to your project in a fraction of the time that scientists take and in a friendly and interactive way and without “all that math”? What if you could actually predict those few significant issues that could become the proverbial “career-limiting” ones and take steps to prevent them? Your rate of success would go up, as would your level of confidence.
Looking at “things that can go wrong” is not a trip into discouraging optimism, but rather a chance to tap into a group’s wisdom so as not to repeat the mistakes of the past and anticipate future ones. A wise person once said, “Experience is the best teacher, but the tuition is lower if you are willing to learn from your mistakes.”
Why do companies fail to manage risk?
Our experience shows that most product development professionals are aware of the issue of risks; furthermore, they are also aware of the need to do it, yet they fail to even start.The causes are many, but more salient are the urgency attached to product development, where teams fail to do risk management because they believe there is not time, not enough “bandwidth”.Another reason is the lack of tenacity or proactive risk management, where there is a single meeting to identify risk and then no more is mentioned for the duration of the project, naturally this latter instance yields little benefit consequently the perception of risk management is a negative one; nothing could be farther from the truth, risk management is a powerful weapon to reduce time-to-market, improve customer satisfaction, and improve the probability of business success.
Engineering organizations tend to do FMEA (Failure Mode and Effects Analysis) which is a proven and valuable risk management tool, except that FMEA is generally only applied to the product, and only within the engineering organization.Risk in product development can happen anywhere, from pricing of the new product, to service and repair, to project risks.Risk management must go well beyond the components of the new product; a holistic approach will save time, and considerably improve the probability of introducing a winning product.
[1] Anything that could go wrong with your project is loosely defined as a “risk” or a potential failure.See appendix “B” for a glossary of risk.
Lessons learned from multi-cultural, dispersed product development teams
(In this article the term “dispersed” is used to denote teams who are scattered around the world, but working on a single development program. Other terms used include “virtual teams”, “distributed teams”, and even “global teams”.)
Developing new products in far-away countries is a model that’s here to stay, and it will become a preferred method for new product development in many organizations. The global nature of today’s business requirements it, and there are several compelling reasons for companies to adopt a multi-site approach to product development:
Obtaining cost-effective resources
Establishing a local presence in a particular country or required to by local laws and tax structure in order to tap a new market
Accessing talent, technology or competencies not available in your home country
Acquisition of a foreign company
Outsourcing development to extend your current capabilities
Regrettably, we find that, most organizations today are still using the co-located development approach of old, where engineering, marketing and manufacturing were co-located in the same building or the same industrial park. Specifically, the new product development processes, organizational structures dating back to co-location, leadership models not in tune with multi-culture environments.
We’ve traveled around the world working with companies to solve the challenges of developing new products when the development team is scattered over multiple sites. Over the years we have learned many lessons when working with development teams that are separated by distance, culture and language.
The Challenges
Some companies make the wrong assumption that engineering is the same the world over, while this is true at the technical level, it does not mean that engineers are the same. The approach that engineers take to solve a problem, think about innovation, and communicate with their peers varies around the world and is heavily influenced by two critical factors, their native culture and the engineering schools they attended. In Europe for example, engineers are taught to develop incremental innovation, while in the U.S. the intent is to always strive for the “home run” breakthrough. Both approaches are correct and both deliver value. The problem occurs when the two are combined without the proper effort to create alignment.
Not surprisingly, communication across distance, language and culture is the most frequent challenge we encounter. From the simple e-mails full of typos, poor grammar, slang (see appendix “B” for more on slangs) and seriously cryptic. To an MRD (Marketing Requirements Document) written for a co-located audience where engineering only needs to walk across the hallway to get clarity from marketing. To business plans written from the perspective of a free market, capitalist model. The concept of capitalism varies around the world, so does the thirst for profits, particularly in the product development ranks.
Another challenge is the poor use of technology (see Appendix “A” for more on the use of technology), while it has enabled multi-site product development to an unprecedented scale, it has also created barriers to communication. Let’s not forget that there is still the need for human beings to communicate, add to that different cultural backgrounds and different languages and you have a communication “firewall”.
Some organizations believe that if they purchase a software application for collaboration or enable video conferencing the challenges will disappear, not likely without a parallel effort to improve communication skills, cultural sensitivity
The base line
We always start our engagements by asking our customers to think of all the challenges they face developing products is a co-located framework. For example unclear customer requirements, conflict between engineering and marketing, lack of strategic alignment across the organization, ineffective product pipeline, etc. Then, we encourage our customers to visualize all these problems and add distance, language and culture to the equation. This little exercise always creates a vivid picture of the challenge at hand. For example, if your MRD is insufficient for your local engineering team, why would it be “good enough” for a group of engineers in Shanghai, who attended a Chinese engineering school, speak a very different language and have the values of an ancient culture.
Six Suggestions for Improvement
Multi-site product development represents a sizeable opportunity to grow a company profitably, in many cases is essential to manage the growth of your company. Many corporations have found it profitable to develop products around the world; many more will see the opportunity and wills start tapping these new sources of profits.
Historically, multi-site development is not new; it has been going on since the start of the industrial age. What is different in the 21st century is how prevalent it has become, and how fast it is taking place. Technology and the end of the cold war have enabled unprecedented speed towards a global market place.
Multi-site product development is not daunting nor is it reserved for large multi-national companies. It does take a change in your product development model to account for differences in distance, language and culture. Plus the realization that technology alone cannot bridge this gap.
#1 Assess your current situation
Start by evaluating or reviewing your product development maturity level[1], i.e., the ability of your current organization to deliver new products on time. For example, are your MRD’s clear and sufficient to enable your R&D organization to create innovative products, faster than your competitors? Is your marketing organization capable of obtaining clear customer requirements on a consistent basis? Is your rate of innovation “up to par”; that is, are you creating innovation that your customers value? And are you doing it faster than your competitors. Do you manage your product development projects effectively?
Once your have assess your current product development maturity level, set about fixing the most pressing problems by re-engineering your new product development processes, enabling your marketing organization to obtain and use customer requirements consistently, etc.
#1 Use technology wisely
Do not assume that a new software application on collaboration or a new video conferencing set up will solve all your communication problems. The most important “glue” that holds a team together to deliver measurable results is the interpersonal communication amongst all the team members. Technology can only enable part of this exchange, culture, language and organizational structures make up the rest.
Let’s not forget that in business, a team is a group of people who are committed to a common purpose, and trust each other. Clarity in communication happens when there is trust, respect and the alignment around a single purpose. Plus, the understanding of the differences in language and culture. Technology bridges the “distance” dimension of communication.
#2 Leadership over management
We have a simple contrast we use to address leadership. “You can manage a process, but you must lead people”, in short, we make the assumption that “managing” people is close to impossible. This is even more evident when the definitions of management and leadership vary around the world.
The role of leadership is critical, but the definition of leadership varies around the world. Here is where cultural sensitivity plays a very important role. The manifestations of a leader in the U.S. are different than those in China or Germany.
#3 Outsourcing does not mean “out of mind”
Some companies make the incorrect assumption that once they have hired an outsource organization the need for close interaction and supervision is no longer required, on the contrary it takes considerable energy to work with your vendor to communicate your expectations of quality, speed, and most of all for you to represent your customers to your vendor.
The same can be said for product development programs, companies are indeed outsourcing development to third parties around the world. We advise our customers to create a robust framework to ensure full collaboration with your design vendor. All the rules and challenges about distance, culture and language also apply to outsourced development.
Having someone simply monitor the contract agreement between you and your vendor is not enough. We suggest the formation of a Core Team made up of a senior person from engineering, one from marketing, Quality and Manufacturing. The make up of this Core Team will vary by companies, but it is critical to go beyond managing the contract. The members of the Core Team must have the experience, skills and time to immerse themselves in the challenge. Considerable involvement by the senior Executives of the company is also required, and not just when there is a breakdown.
Another recommendations we often make, is to develop, document and consistently manage a risk plan on your relationship with your vendor. This is about how your company and your vendor work – beyond technical issues. A Risk Management Plan will surface potential failures in your relationship and allow you to prevent a breakdown.
#4 It all starts at the top
The Executives and other leaders of the organization must be the first to adopt the sensitivity to distance, language and culture and become the role models of the new behavior. They also need to set up a simple set of metrics to asses the progress towards multi-site product development, and finally they must reward the right behavior by identifying and recognizing role models.
#5 The critical initiation of your development program
Considerable effort and focus must be placed at the very start of your new development program. In our experience, this is an area often neglected by product development organizations, even when the team is co-located. Imagine the problems when you add distance, culture and language. The start of any development program is critical to building your team and enabling them to develop trust. Thus, spending several days doing a “kick-off” meeting is time well spent, and an investment that will provide a high return later in your project.
The “fuzzy-front-end[2]” of a development program is that phase at the very start of the project where there is much confusion. For example, the development team is not fully identified yet, the objectives are not clear, budget is not set and the schedule is in flux, roles and responsibilities are not even identified let alone communicated – to name a few. Incidentally, every project has a “fuzzy-front-end” no exceptions! It is a natural phase of project management; thus, it is best to take full advantage of it.
One strategy that we have used very effectively is “go slow to go fast”, the idea that the initiation of the project is the most critical phase and consequently much time and effort should be spent. We have found that with a strong foundation through “kick off meetings”, increased communication and team building at the beginning of the development program, considerable velocity is achieved, and “false stars” are avoided.
We always advise our clients to hold a “kick-off” meeting with as many members of the team as possible. This is an area where one cannot afford to be “penny wise, and pound foolish[3]“ by trying to hold the cost of travel and lodging down. Money spend to clear the “fuzzy-front-end” has considerable returns later in the project through increased velocity of development, said another way, the cost of not dealing with the “fuzzy-front-end” will cause delays due to poor communication, friction in the team, and lack of alignment with the technical and business objectives of your development program.
Our recipe of the extended “kick-off” meeting include a complete review of the objectives of the new product, both business and technical with ample time to discussion and dialog amongst the team members, remember a PowerPoint presentation is woefully insufficient to create alignment or even clarity.
Further we spend considerable time in dialog (discussion) on the customer requirements, and understanding what the customers of the new product “value”.
We also add time for the team members to interact at the personal level, for example extended coffee breaks, evening activities and even some “free time” for networking.
#6 Address the common multi-site development maladies
When distance, culture and language are involved, we have identified a series of common maladies, and over time we have helped our customers either prevents them or put in place corrective action.
Breakdown of communication due to language and culture
As the pressures of the development program increase it puts a strain in the ability of the team to communicate with clarity and objectivity. This is aggravated by distance, language and culture.
Conflict between the local management structure and the “head office”
Local sites have their own set of pressures, priorities and in many cases business objectives. Try as they may, corporation constantly face this type of turmoil yet the problem persists. There are development programs where this conflict creates delays and even the risk of failure.
Conclusion
Multi-site product development is indeed not a mystery; it is a mature and proven approach to increase profitability and growth. There are steps that must be taken in order to tap the potential, as with any strategic initiative in your company, this one will take several years to fully implement, will require a change in the way your company develops new products, and will tenacity and commitment on your part.
[1] Maturity Curves have been developed for product development including software. These models look at the level of competency of a particular organization, as opposed to an individual within that organization. The model assigns different levels of “maturity” the higher the competency.
[2] “Fuzzy-front-end” is a term that started in the development of new techniques, over time it has come to represent that start of development programs where there is insufficient information and confusion is prevalent. Every project has a fuzzy-front-end; your task is to exit this phase rapidly without sacrificing clarity, and alignment in your team.
[3] “Penny wise and pound foolish” is a refrain (idiom) used to denote being careful with very small amounts of money but foolish about missing the larger mission.
The Return on Invement (ROI) on training at the end of any workshop or seminar is zero!The ROI only happens if there is measurable improvement in performance after the class.We recognize that some residual value is gained under the category of education; nevertheless, corporations invest in training to achieve gains in productivity.
There is a dark secret in the training industry: That approximately 80% of what people are exposed to in professional training will be forgotten within one week, and most participants will not implement what they learn.Training for thesake of training is not a sound business practice.
Product development environments tend to be tumultuous, imposing serious pressures on professionals who have little time to spend on training; thus the need to ensure full adoption from every training opportunity is paramount — there is no second chance.
Typical Scenario
Visualize the last training session you attended.Chances are that you were asked to attend, but not told why?Once there, the instructor presented a myriad of PowerPoint slides and facilitated hypothetical exercises with little or no relevance to your real situation.Finally, you returned to your desk, still not knowing what to do.
Typical Misconceptions about Training
Unfortunately in the corporate world there is some lack of understanding about the role of training in the improvement of productivity, for example:
ØTraining alone will fix productivity problems
ØThose attending training will know what to do to create sustained performance improvements.
ØManagement can delegate the responsibility of productivity improvement to some training organizations while expecting measurable results
ØThere is such a thing as “instant pudding” when it comes to productivity improvement
ØWithout a framework of support and reinforcement training will result in measurable improvement
What to do about it
What you need to ask trainers and instructors in order to protect your investment.
Focus on practical application.
Ask the instructors to develop their syllabuses, materials, and overall approach to enable the participants to apply the knowledge to their day-to-day jobs.We have seen too many “concept training” without a commensurate reinforcement on application.Specifically, lack of process maps (how to’s), insufficient templates and forms, and too many examples from hypothetical applications.
The development of training materials must be done from the start with focus on application to real-world situations and keeping in mind the obstacles and challenges that participants will encounter after the seminar is over.
Ask the instructors to work with Managers and Executives before, during and after the training to collaborate in developing the necessary framework of support to ensure measurable improvement in productivity.
Require the instructors to understand the business objectives of the training, not just the training objectives.This will help them develop a relevant context for the training, and also reinforce the message from management.
What you can do
First defineand document the business objectives for every training program.Ensure that all managers and supervisors understand the business intent of the training.All training must be part of an overall business need.Remember that a training program must result in a measurable improvement in performance and eventually improvement in the profitability of your organization or company. It is possible to identify the expected role training plays in any productivity improvement initiative, it may take some analysis and creativity, but it can be done.
Inform every participant of their roles and responsibility in every training session.Every employee must know the answer to the following questions, with absolute clarity:
Why am I here? Explains how the training relates to the job of the individual participant, and expressed in the “language” of that individual.
Why are we here?Explains why a particular group or team is participating in the seminar, i.e., the big picture.
What do you expect from me after the class?Specific explanation as to the expected improvement in productivity related to the day-to-day responsibilities of the individual.
What can I expect from you after the class?Details the level of support that participants can expect from management.
Define and use metrics beyond the “smiley face” class evaluation.Strive to develop metrics that connect to the improvement of profitability of your company.
While we recognize that training alone will not improve productivity, it was nonetheless the reason why you decided to provide training.
Productivity improvement can be measured in one of three ways:
1. Reduction of waste, for example the use of a new tool reduces the number of steps employees must complete to complete a task.
2. Reduction in cycle time, for example training in project management reduces time-to-market in a product development organization
3. Improvement in customer satisfaction, where by new training results in an improvement of satisfaction in a specific customer segment.For example training in reliability results in more dependable products thus improving customer satisfaction.
Seek complete information about the training and the instructor.The training should be developed based on a solid understanding of the “real world”, avoid “best-case scenarios” training that makes the assumption of a perfect environment.Ensure that every instructor has the academic and most of all the actual experience in the particular training domain.
Perform a debrief (retrospect) three months after the training was completed.Doing a postmortem on a training program a few months after it took place will provide considerable information about its effectiveness, “lessons learned”, and any new gaps that need to be closed to continue the improvement in productivity.Retrospect on a particular training initiative will also identify the root cause of needed improvements.
Conclusion
Training is a critical ingredient in coping with difficult environments such as product development, it is in the best interest of your company to maximize the productivity of every employee.Taking a few critical steps such as those outlined in this overview will improve the return on your investment and allow you to make a measurable contribution to your organization
Nothing, if you recognize that market research is a toolset that must be used very carefully and with full awareness of your role and responsibilities as product development professional. The basic problem with traditional market research is that in some cases it is misused. Said another way, customer intimacy (Voice of the Customer) cannot be delegated to a third party. More and more, marketing professionals, engineers and executives need to be in intimate conversation with their customers.
What do you mean, misuse of market research?
As with any toolset, it can be used the wrong way or for the wrong reason. Here are four regrettably common examples:
The passive approach
One contributing factor to misusing market research is that it tends to be seen as passive. Generally, when the results of market research are presented there is a surge of energy and excitement. But then everyone goes back to doing much the same as they were. Remember the last time you attended the presentation of the results of a market research study? After the “nudging” and “winking” has subsided, there’s little commitment to action, let alone a documented action plan. There is much good market research that ends up in a filing cabinet or a hard drive, never again to be seen by human eyes. Every piece of market research should cause much dialogue, soul-searching and, most of all, action planning in your organization.
The corporate ritual
Corporate pressures can drive executives to use market research to simply “do something.” In some cases it becomes a corporate ritual, with no particular outcome. It’s an easy way to show action, but with little result. As someone put it, “It’s just to keep the GM out of our hair.”
Denial is not a river in Egypt
Before any research is done, there must be a commitment to accept ideas that may be contrary to the “folklore” that exists in your organization. You must make a commitment to be open-minded – the recognition that maybe, just maybe, there’s another reality that makes more sense; i.e., how your customers perceive their world.
Using the wrong tool for the right job
Sometimes, due to high workloads and over-commitment, marketing professionals see market research as a substitute for clearly understanding their customers. While market research is an indispensable tool, and much needed in developing a solid understanding of your market, it is no substitute for the proverbial face-to-face dialogue with your customers. Furthermore, by delegating this privilege, marketing professionals miss the energy that is generated when talking directly to a customer – a third party should not steal this prerogative. There are several mature and solid methods for understanding customer requirements, such as VOC (Voice of the Customer) and Concept Engineering, but they all require marketing and engineering professionals to spend time interacting with customers.
Solutions
Every market research study should include a documented and measurable action plan – lest you waste your time. Before any research, agree with your team that an action plan will be developed, documented and acted upon. Assign clear roles and responsibilities.
The action plans should be developed immediately after the results of the research are presented, during a three to four-hour session solely focused on action.
We suggest that you think in terms of two meetings, one where the market research firm presents the results (two hours), and then a subsequent one to develop the action plan (four hours).
Develop a binding agreement with your team and peers to be open-minded and receptive to alternative views of reality before any market research is undertaken – especially if the possible alternative views are those of your customers.
This may be best accomplished by retaining an external facilitator who can be more objective and who possesses the skills to lead the team to consensus. Lacking an external facilitator, an internal one might suffice.
There’s no replacement for face-to-face contact with your customers. It is the best form of market research and a privilege that must not be delegated to just anyone.
Make customer focus a true value for your organization, beyond the platitudes and clichés. While most of us profess to be customer-focused, how many of us actually walk the proverbial talk? How many hours did you spend in dialogue with your customers in the last 30 days?
Develop and document a plan to understand your customers and market. Market research is not an isolated, single event. Rather, it should be part of a combination of efforts to understand the requirements and the dynamics of your market. Map all your market research and customer interaction activities on a calendar and proceed to implement this plan.
Engage your engineering and technical organization in any customer interaction activity, such as customer interviews. Marketing alone cannot profile customer requirements optimally; it takes the “stereo vision” of engineering and marketing to achieve the goal.
What if You Want to Go Deep inside the Minds of Your Customers?
If what you’re seeking is something deeper – something that gives you a deep understanding of how your target audience thinks, or why a project succeeded or failed and how to improve your business strategy, or to understand the deep emotions that drive your customer to purchase or not – then you need to make a commitment to an ongoing dialogue with your customers.
It is clear that emotional forces are key drivers in the purchase of your product. The way your customers perceive your company and products is also driven by emotion. Therefore, doesn’t it make sense to also understand your customers at the emotional level?
You can also partner with a new breed of consultants who take market research to new levels.
The new breed of research consultancy is made up of experts in psychology, technology, business and even anthropology. They equip you to talk to your customers in an effective fashion, and even partner with you to interact with them. But always ensure that all due diligence is done before, during and after the dialogue with your customers. Use only highly trained and qualified professionals. And treat the dialogue with your customers as if it represents the future of your business – which it does. Consultants use tools like neurolinguistics, strategic alignment and language processing. All of it is designed to extract every drop of usable insight from your customers, and put it to good use in growing your business.
In conclusion, market research is clearly part of the toolbox of marketing, but it is not the only tool in that box. The field of customer intimacy, commonly referred to as Voice of the Customer (VOC), is the responsibility of marketing and engineering professionals, and should not be delegated to third parties.
Risk is the probability that something could go wrong with your product development project. This includes not only technical risk, but economic, market, manufacturing, outsourcing - in short anything that could happen that would extend the time-to-market or worse yet cause a fatal failure of your project.
Risk Management is the process to identify, prioritize and mitigate risk in a development project.The purpose of risk management is first to ensure that the identified risks do not happen (preventive action), secondly to prepare a clear action plan if a risk does happen (corrective action).Simple concept and simple methodology; however, I fail to understand why so many product development organizations chose to completely bypass risk management.
In product development risk is always there, it makes no sense to ignore it.Yet this is what many organizations do.Consider that many, if not most, of the so called “surprises” are risks that were predictable at the start of the project.Some organizations do not apply risk management because they believe that the project will go smoothly and risk free (fool’s paradise).Others simply do not realize the leverage it has on time to market, improvement in reliability, reduction of waste and improvement in customer satisfaction, a powerful list of benefits indeed!
Many development organizations profess to be committed to “short time-to-market.” Speed is their mantra.While at the same time they perform no risk management.As the old saying goes, what’s wrong with this picture?Imagine if you could predict and prioritize all the things that could go wrong with your development program.Could you not visualize the development of a plan to manage risk, rather than be victimized by it?
Implementing a risk management model is not all that difficult.First, you must understand the benefits, for example the “insurance” to meet your planned schedule.Then you adopt a risk management methodology.Finally you show tenacity to ensure that you obtain the benefits. Gradually risk management will become a habit, simply the way you do things in your organization, no longer a novelty.
For many years, project managers have benefitted from the guidance of the Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK). PMI guidance, the PMBOK, and Project Management Professional (PMP) certifications continue to enhance our ability to achieve successful outcomes, but as the world changes other resources and skills are needed.
Actually, this has been true all along. Industry studies consistently show a very low success rate for projects in terms of meeting stated objectives. Much of this is due to unrealistic expectations, but other than that, the general approach to project management needs to change for results to improve.
The PMBOK focuses on nine knowledge areas: Integration, Scope, Time, Cost, Quality, Risk, Human Resources, Communications, and Procurement. One problem is that “Leadership” is not a focus area. Project success depends more on solid leadership than “management,” but that’s a topic for another discussion. The problem I want to point out here is that the importance of communication is not emphasized nearly enough. I believe that if the PMBOK emphasized only leadership and communication, project success rates would be greatly improved.
Communication is becoming increasingly important as project teams become more globally dispersed. We’re handicapped by time zone differences, language differences, limited opportunities for face-to-face communication, email overload, communication technology limitations, and other factors that hinder communication. Add the challenges related to excessive workloads, limited resources, complex dependencies, etc. and it’s a wonder we can even complete many projects at all. “Successful” projects indeed seem like they should be a rarity with the typical barriers we encounter.
What are your thoughts about the importance of communication for project success, and how to improve communication?
Creating and Developing Winning Products syndicates its weblog posts
and Comments using a technology called
RSS (Real Simple Syndication). You can use a service like Bloglines to get
notified when there are new posts to this weblog.
