The most important PD activity you're not formalizing

To produce a winning product you need 3 things:

1. Understanding of stakeholders wants, environment, assumptions, priorities and what is feasible
2. Sharing the vision
3. Staying on course

Change of direction is probably the single largest factor in cost and schedule overruns. Typically, 80% of all defects are inserted in the planning and requirements phase. The beginning is most important. As you move down the sequence of events in PD, the leverage of activities for success becomes more difficult and adds increasing complexity. Leveraging good requirements up-front is the single most effective activity for successful product launch. Spending time in design, development, testing and pilot is relevant and necessary, but leveraging the time spent in requirments definition will pay off many times more than hastily rushing into design and on.

The Requirement process is a fairly easy process to formalize and structure in your overall PD process. The steps in the Requirement process are:

1. Define the scope - identify Needs, Goals and Objectives
2. Create operational concepts
3. Involve all stakeholders in writing requirements at system, assembly and component levels
4. Define test and verification methods

Bad requirments cause cost overruns, schedule slips, frustrated employees, unhappy customers and lost profitability. Bad requirements come from incorrect information, omissions, poorly written and ambiguities. They occur because most people don't know how to write requirments, too little time is spent defining the project before requirments are written and too many assumptions are made without verifying with stakeholders. Little time is allocated for writing and reviewing requirments. There is no incentive to write good requirements because engineers want to design what they think stakeholders want.

Essentials for good quality requirements include:

• Clear vision
• Necessary resources dedicated to generating and reviewing requirements
• Well-defined processes
• Educated personnel
• Accountability

Good quality requirements will reduce PD and project time, reduce paperwork, reduce ambiguity, detail a clear vision, motivate resources and produce a winning product.

Sudden Rise in American Car Quality?

Did you see the AP story today showing that Americans now believe Ford, GM and Chrysler produce higher quality cars than Asian car companies? An excerpt…

Slightly more Americans now say the United States makes better-quality vehicles than Asia does, with 38 percent saying U.S. cars are best and 33 percent naming autos made by Asian countries, according to an Associated Press-GfK Poll. When the same question was asked in a December 2006 AP-AOL poll, 46 percent said Asian countries made superior cars, while just 29 percent preferred American vehicles, reflecting a perception of U.S. automotive inferiority that began taking hold about three decades ago.

Do you believe that American car companies have made massive improvements in quality since 2006 – in the midst of the worst recession in decades – that warrant such a dramatic change in public perception? I don’t.

On the other hand, I have never completely accepted the notion that there was a huge gap in quality between American and Asian cars in the first place. I have long been suspicious of so called “reliability ratings” made by Consumer Reports and the oft cited JD Powers “initial quality ratings”.

The majority of cars built today are really quite good. When all the products in the sample are really good, it is difficult to detect meaningful differences in quality – especially if your measurement tool is a customer satisfaction survey. Besides, it is hard for me to put much faith in these surveys when the vast majority of people being surveyed don’t know the difference between a spark plug and a dip stick!

In addition to lack of technical knowledge, many people carry brand loyalty biases that defy logic. This loyalty bias seems to run deeper with foreign brands than domestic brands. Have you ever tried to talk cars with a loyal VW owner?

Setting my concerns about the survey methods aside, let’s look at the actual numbers from the JD Powers initial quality ratings. Taken at face value, you will see there is little difference between brands in the top half of the survey.

JD Powers measures things in terms of defects per 100 vehicles in the first ninety days of ownership. In the last survey, American car companies averaged about 112 defects per 100 vehicles. Imports averaged about 106 defects per 100 vehicles. That’s a difference of 6 defects per 100 vehicles between the American and Asian fleet.

Do you seriously believe that the average person, whom we have already established doesn’t know the difference between a spark plug and a dip stick, can detect the quality difference represented by 6 defects per 100 vehicles? Probably not.

It is exactly this kind of hair splitting that has been used by the media to claim that American brands are inferior to Asian brands. To some extent -- and this AP story helps make this point -- the media’s message sharpens consumer bias. That consumer bias feeds back into the results of the JD Powers and Consumer Reports surveys.

Now that the American car buying public suddenly has a better view of the American car industry, even if for no objective reason, it will be interesting to see if this new attitude shows up in as better ratings for Detroit in the next round of Consumer Reports and JD Powers surveys.

For the record I drive a 2007 Mazda6 and my wife drives a 2007 Dodge Grand Caravan.

When it’s Time to Kill a Project – Part 3

Previously, we created a hypothetical project portfolio to examine that very question. Let’s review…

Project Alpha was approved because it looked like a winner (part 1). But midway through the project, financial metrics took a turn southward. Even though project Alpha’s financial metrics are headed in the wrong direction, Alpha still looks like a decent bet compared to other projects in the portfolio based on a remaining cost basis (the correct way to compare alternative projects – part 2). And Alpha’s strategic score is still the highest of all the projects in the portfolio.

Strategic scoring is a way to evaluate your project portfolio on qualitative factors which are known to be drivers of new PD success for your company. Projects are scored by the team responsible for managing your gate process. Strategic scoring factors usually fall into categories such as:

• The product’s strategic fit and importance to the business strategy.

• The product’s competitive advantage in the eyes of the customer and relative to the competitive landscape.

• The attractiveness of the market in terms of size, growth potential and profitability.

• Your company’s core competency in terms of technology, operations, marketing and distribution.

• Program risks including technical feasibility and relative certainty of schedules and financial models.

Research by Cooper and Edgett show that strategic scoring, although not as popular as financial metrics, yields better results – i.e. project portfolios with higher valuation -- than financial metrics.

If you made a scatter plot of your projects using financial metrics versus strategic value, it is clear that projects with high financial value and high strategic value will get a green light. But, projects with high strategic value and low (or declining) financial scores need more consideration.

I had my own project Alpha once once. Without getting into the grisly details, we were under pressure to get this new product to market by a certain (perhaps arbitrary) date. The only way we could meet that date was to design a product with less functionality. For better or worse, that’s what we did.

The functionality we removed happened to be software interface features. To use an analogy, we decided to develop an iPod without iTunes. Now, would Apple’s iPod sales be lower without iTunes? Probably. The same was true for our product without the software interface features.

Our decision to proceed without the software interface features was not necessarily a bad one. Dropping the software features did shorten the schedule. Besides, we needed the new hardware platform with or without the software interface. This product brought new benefits to our customers and gave us an opportunity to introduce several high margin accessory products too. And, we could always add the software interface later if we wanted to make that investment.

The downside of our decision to proceed without the software interface was we had to temporarily scale back our sales expectations. Just like in the project Alpha example, sales and gross profit forecasts ended up being lower at later gate reviews than at the first gate review when the project was approved. But, just like Alpha, the strategic importance of our product warranted moving forward in the face of declining financial metrics.

We have not discussed how to handle risk and uncertainty in your portfolio management process. How do you make Go/Kill decisions when you are dealing with risk or uncertainty? Simply killing all projects that have high degrees of risk or uncertainty on the front-end will prevent you from making big mistakes. But, that approach means you will not have many big wins either.

You can use your gate process to manage risk by proceeding incrementally. Think of this incremental approach as buying options on the project. I’ll cover how to use your gate process to make incremental or “options” based decisions in part 4.

Using the Baldrige Framework in Product Development

Recently, I became an evaluator for the Minnesota Council on Quality’s Minnesota Quality Award. Established in 1991, the Minnesota Quality Award is given to organizations that successfully complete a full assessment based on the Baldrige National Quality Program criteria. The Baldrige criteria used for the Minnesota Quality Award is updated every two years to incorporate new and improved ways that businesses are succeeding.

There are seven categories of requirements for Performance Excellence and they are all linked in a framework or "System". Use of the system, analysis and categories can be applied to Product Development for a good starting point for a continuous improvement plan.

The seven categories of the Baldrige criteria are:

1. Leadership
2. Strategic Planning
3. Customer Focus
4. Measurement, Analysis, and Knowledge Management
5. Workforce Focus
6. Process Management
7. Results

The overarching context of these seven categories is your Organizational Profile, including Environment, Relationships, and Challenges. In your Organizational profile for Product Development, you will look at your operating environment and your key relationships with customers, suppliers, partners, and stakeholders. What are your core competencies and where do you look to others to complement your organization? How does your workforce engage internally and externally? These questions may provide insight to the effectiveness of your Business Management System that resides over all other processes.

The first category in Baldrige is Leadership. How do your leaders guide the Product Development organization, projects and strategies within the department? Describe how leaders communicate with your teams and to other departments. Also, look at how leaders encourage others and high performance overall.

The second category is Strategic Planning. This category examines how your organization develops strategic objectives and action plans. Analyzing your existing products and gaining feedback from customers should give you a good view at where you are at and where to go. You will be reviewing your core competencies to match future goals with organization needs/areas of development. Multi-generational Product Plans are one way to provide a visual portrait of product strategy. The strategy needs to be deployed once it is developed. Action plans and future projects should be outcomes of this. All of this requires continuous review to react to changes in your business, technical and organizational environments.

Customer Engagement is the third category. This is especially critical in Product Development to ensure you are getting the right product to the right customer at the right time. Serving the customer's needs and building relationships from engagement is critical to your product's success. Everyone in the organization should be focused on the customer and meeting their needs. Voice of Customer is a commonly used term that has lost relevant meaning due to the lack of engagement. Scope and Requirements need to be honed until an appropriate level of information is gathered to not only meet, but exceed customer expectations to stay ahead of the competition.

The Myth of Multitasking

Lots of studies have come out in the last few years showing that multitasking isn’t all it is cracked up to be. But now, here is a study that shows people who multitask the most are worse at it than people who multitask the least.

Do you expect your teams to multitask effectively – even in the face of evidence that suggests it can’t be done? Can you do anything to minimize multitasking?

Ron Mascitelli, author of the Lean Product Development Guidebook, suggests setting up “project time” wherein your team can’t read email, schedule meetings, or entertain other disruptions. This focused time might be one morning per week, or it might be a specified block of time every day.

Would your product development team be more productive with just four more hours of uninterrupted time each week? Probably.

Maybe dedicated project time is not possible in your organization. Still, you can minimize the negative impact of multitasking just by setting clear priorities for your team.

Let’s say engineer Eric comes in to your office and says he is overloaded. He tells you project manager Bob needs him to prepare a test report for project A and project manager Mary needs him to finish a prototype design for project B. They both need to have their work done in four weeks.

You ask Eric if it is possible to get both tasks done in four weeks. Eric says, “Yeah, but it is going to be tight and I still have some problems to work out with the prototype design.”

You know both projects are important. So, you tell Eric to dedicate his mornings to Project A and the afternoons to Project B. You promise to protect him from further interruptions. You remind him that both projects are important and we just have to get them both done on time.

Bob now has uninterrupted time in the morning for Project A and uninterrupted time in the afternoon for Project B. You are a clever manager!

Let's multitask and hope for the best!

But, I’m not going to let you off the hook that easy. You are still asking Bob to multitask. And by stretching both projects out right up to the deadline, now you have introduced the possibility that both projects will be late!

Sure splitting the work between morning and afternoon is better than just telling Eric to go back to his desk and stop complaining. But, Eric has already told you there is risk lurking in the prototype for Project B. And what if Project A takes longer than he expects?

Let’s say instead of relying on the myth of multitasking, you consult with Bob and Mary and are able to make a consensus decision that Project A is higher priority. If Eric’s original time estimates are correct, he will still have time to get Project B done on time. If not, at least the highest priority project is served on time.

Prioritize and get something done!

Multitasking doesn’t work as well as we’d like to believe. Give your team the best chance of success by setting up project time and by prioritizing their work. You will get more done and have a better shot at hitting your market launch date too.

When it’s Time to Kill a Project – Part 2

Selecting the right projects, and allocating appropriate resources to those projects, is critical to NPD success. Project portfolio management is the process of periodically prioritizing your projects to maximize your new product development investments. A good portfolio management system serves to put everyone on the same page as to why we have selected this set of projects, and (just as important) why we rejected others.

Even with the best portfolio management system in place, once in awhile you will pick the wrong project, or a good project will get off track. How do you know when it is time to pull the plug?

In part 1, we created a hypothetical project portfolio to examine this question. In the first project portfolio review (we called it Q1), Project Alpha was approved because it looked like a winner. However, in the Q2 review we discovered project Alpha was off track from the original plan. Marketing reported that five-year gross profit is expected to be half what we thought when the project was approved in Q1. Engineering expects development costs will total $1.2M (original estimate of $800K).

In the next table we see what our project portfolio looks like at the Q2 review. We see that project Alpha has fallen to fourth place when the list is sorted by five year gross profit divided by development cost (5GP / DC). Maybe we should dump project Alpha in favor of Beta.

There is a problem with the above table because it includes project Alpha’s sunk costs – the money already spent on the project. That money is gone and isn’t coming back. We have to make today’s decision based on the options available to us today, not what happened in the past. (See what others have to say about using sunk costs vs. remaining costs in my question on the subject posted to the LinkedIn Questions and Answers page.)

Let’s redo the table assuming that we are halfway through the Alpha project – i.e. we have already spent $600K of the current $1.2M total cost estimate. That means our five year gross profit divided by development cost metric becomes 4.2 (not 2.1). This of course is still a setback from the original value (6.3), but this keeps project Alpha closer to the top of the list than if you used total development costs in the calculation.

Remember, project Alpha’s 5GP / DC ratio would be 12.5 if it was on budget and 50% complete. By using remaining costs instead of total costs a good project should look progressively better the closer it gets to completion. That only makes sense doesn’t it?

Ignoring sunk costs, Alpha’s gross profit to development cost ratio is still relatively good and its strategic score still tops the chart. So, unless you have a corporate mandate such as all products must have a 5 year gross profit of at least $4M, it is not clear that you should cancel Alpha just on financial metrics alone.

Now, it’s time to examine why we dropped our 5 year gross profit estimate by from $5M to $2.5M. Is it because we just learned we are designing a product that is missing key features that our customers are looking for? Is it because a new competitive threat has emerged? Did we simply overestimate the available market to begin with? And most importantly, can we make a midcourse correction to get some of that gross profit back?

I’ll look at those questions, and share a real life example, in Part 3.

It is Rocket Science

I am reading Rocket Men, The Epic Story of the First Men on The Moon by Craig Nelson. It is a fascinating account of the Apollo moon program and the Cold War politics that motivated the space race.

On April 14, 1961, two days after Soviet cosmonaut Yuri Gagarin became the first man to orbit earth, NASA chief Jim Webb told President Kennedy putting a man on the moon would cost $40 billion and had a 50% chance of success. Six weeks later on May 25th, Kennedy would make his famous speech declaring that America should, “commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to earth.”

By any measure the Apollo program was a smashing success. Just putting a man on the moon, at any price, would have been considered a technological triumph. But, from an engineering management perspective Apollo is nothing less than stunning. It was a $40 billion dollar (that’s $250 billion in 2010 dollars) nine year project that was completed on time and under budget. And that 50% chance of success? Well, with 6 of 7 flights actually landing on the moon, they nailed the risk management part of the project too.

One of the keys to the success of Apollo was a managerial decision made in 1963 to abandon incremental testing for “all-up” testing. Previously, engineers would only put the whole rocket stack together after the first stage was successfully flight tested, then the second, and so forth. Using this incremental approach, NASA estimated there was only a 10% chance of getting to the moon by 1970.

Using “all up” testing, the entire rocket would be assembled and flight tested as quickly as possible. Subsystem testing, quality, and risk management were all pushed back upstream. Subcontractors now had to pay more attention to the interfaces and to getting bugs worked out before their subsystems were delivered for “all up” flight testing.

Every single mission had some failures. But by failing early and often, overall development progressed faster than it would have with the incremental approach.

I see parallels to Lean Product Development here. Don’t you?

Some of this “all up” testing stuff seems to run contrary to what I hear coming out of the Agile software development community. At some level, Agile software development methods seem like an incremental approach taken to extreme.

Why is it possible to save time using “all-up” testing to build rockets, but software development somehow benefits from a more incremental approach? I guess when it comes to rocket science -- it’s not software development!

If you are a software developer or manager with Agile development experience, please leave a comment to tell me what I’m missing.

When it’s Time to Kill a Project – Part 1

I have a friend who took a director of engineering job with a company that was struggling to launch new products. He rolled his eyes when he told me he inherited a situation where there were more active projects than engineers working on them. This particular company never saw a project it didn’t like and the end result was a lot a great ideas in the pipeline, but not much coming out the pipe.

Project portfolio management is really about prioritizing your projects so you can allocate your limited resources on the right projects. In a perfect world, you would never start “the wrong” project and no project would ever run into trouble midway through. But, in the real world we sometimes have to admit we are on the wrong track and a project should be killed.

We have a hard time admitting failure. In a sense, pulling the plug on a project requires us to admit we made a mistake. Either we let the project get off track or we shouldn’t have approved it in the first place.

Economists refer to the money you have already spent as “sunk costs”. Once you’ve paid the price of admission for a lousy movie, that $10 becomes a sunk cost. The sunk costs are not coming back to you no matter how much longer you sit in the theater. Jason Cohen posted a great article on his Smart Bear blog recently about sunk costs.

Ok, so we get it. Sunk costs are not coming back and it is really bad to keep putting good money into bad projects. But, how do we know when a good project has gone bad? I mean, every project was once viewed as important and worthy of your company’s limited time and money at some point early in its life – right? What changed, and how do you recognize it?

Let’s look at a simple example of portfolio management and a project heading south. In this example, we are measuring projects on four dimensions: 1) five year gross profit; 2) development cost; 3) the ratio of gross profit divided by development cost; and a strategic score (0 – 100 scale) that captures more subjective things like the strategic importance of the project, the product's alignment with our sales channel, etc.

In our first review (we'll call it Q1) we decide project Alpha looks like a winner. It will give us $5M in gross profit over 5 years and development costs are $800K. Furthermore, it tops out in our strategic scorecard with a score of 85. We only have resources to do one new product development project at a time, so project Alpha is approved and we schedule our next portfolio management review for Q2.

In Q2 it is evident things are a bit off track for project Alpha. Marketing reports that their original estimates of the market were too optimistic and R&D reports the project is going to cost more than they originally planned. Five year gross profit estimates are down 50% and development costs are up 50% from when the project Alpha was approved. Project Alpha drops to 4th place on the project list.

Had we known in Q1 what we know now, we would have approved project Beta instead of Alpha. So, should we kill project Alpha at the Q2 review? There are no simple answers. I am going to take the next couple of posts to explore this question.

Startups Need First Product Success

It should come as no surprise that the survival rate of new technology ventures is fairly low. But new research by Lisa Song, Anthony Di Benedetto, and Michael Song published in the journal IEEE Transactions on Engineering Management (February 2010) attempts to explain why.

The research shows that a new venture’s success is heavily dependent on the success of the venture’s first product. Furthermore, new venture success is highly correlated to technical knowledge, technical skills, and market knowledge.

The research looked at the five year success rate of 694 Chinese tech companies. Overall, the five year success rate for this group of companies was a sobering 36%. Only 14% of new ventures were successful if their first product was a failure. The five year success rate jumped to 70% for company’s that successfully launched their first product.

The research also shows a positive correlation between first product success and technical resources and skills, market knowledge, technical knowledge, and supplier involvement. Surprisingly, it also found a negative correlation between success and marketing resources and skills. That’s right… market knowledge is important early in a tech startup’s lifecycle, but marketing resources and skills are not as important -- and as indicated by the negative correlation can even be detrimental.

Now before all my marketing friends send me nasty emails, let’s think about this for a moment. First, the research makes a distinction between market knowledge (what you know about your customer’s needs and the channel) and marketing skill and resources (the people you hire). There is no doubt that marketing skill is important for a mature company. Research referenced in the Song, Di Benedetto and Song paper is very clear about that. But the kind of marketing skill required in a mature company may not be as important early on in a tech startup.

By definition, a tech startup begins life with a new idea that is targeted at a specific market or problem. Almost always, the founders of tech startups have tremendous market specific knowledge. They usually have a wide and deep network of professional contacts in the target industry too. The founder’s unique knowledge of the market may in fact be a useful substitute for hiring marketing specialists early on. So the negative correlation found in this study might indicate that hiring marketing specialists too early is not the best way for a new venture to use its limited resources.

Earned Value Management for Product Development Projects

Earned value management (EVM) techniques might seem a bit intimidating to the uninitiated. Maybe it’s the fact that EVM has its roots in massive government contract projects (think NASA and DoD). Maybe it’s the alphabet soup of acronyms. The truth is EVM is really not that complicated and it can be useful on smaller product development projects too.

The basic idea of earned value consists of establishing a baseline plan for the project and then periodically plotting some measure of progress against that baseline. The terminology used can vary from system to system. For the simple examples presented here, let’s go with Planned Value, Actual Cost and Earned Value.

• Planned Value (PV) is the cumulative planned cost of the project over time. This will be embodied in your project Gantt chart and work breakdown structure.
• Actual Cost (AC) is the actual cumulative cost of the project. This is a number you should be able to get from your project cost accounting system if your team is logging time for work performed.
• Earned Value (EV) is a cumulative measure of progress. Getting an accurate measure of progress can be the trickiest part of doing EVM well.

EVM provides a slew of project performance indices, all of which are straightforward once you have the basics of PV, AC and EV in place. Perhaps the most compelling reason to use EVM is that it gives you a great way to see project status in a visual manner. Let’s take a look at a couple of examples.

In the example below, you can see that actual costs exceed planned costs and earned value (progress) is less than planned. This is project is over budget and late.

In the next example, you again see actual costs exceed planned costs. But on this project, earned value is pretty close to planned value line. This project is over budget but is on schedule.

Measuring earned value (progress) is the real trick to making EVM work. It is important to establish objective measures of progress. Intermediate milestones can be helpful for measuring progress on longer tasks.

In the absence of intermediate milestones, focus your measurements on how much work is left to complete a milestone instead of percent complete. You will find your estimates of work remaining tend to be more accurate than estimates of percent complete and you can compute percent complete if you know how much work is left.

If you want to learn more, there is a good Wikipedia article that covers the technical aspects of EVM pretty well. If you want to take a more hands-on approach, I am teaching a ½ day workshop on EVM in the Twin Cities on April 1, 2010. This workshop will address practical issues such as how to make accurate measurements of earned value and how you can apply EVM to product development projects, large and small.

Speed is Good – Especially When You Know Where You Are Going

Market knowledge is more important to product development success than time to market. That, according to research published last year in the journal IEEE Transactions on Engineering Management.

Heresy, you say? Let’s take a closer look.

The heretics -- two academics from the US and Italy and one employee of Caterpillar also in Italy -- surveyed 250 companies in the US, Germany and Japan. Most of the companies in the survey were mid-size firms with 90% having fewer than 3,000 employees and only 2.5% employing fewer than 40 people. The median company had 275 employees. All of the companies in the survey had launched at least 5 new products in the last 3 years.

The researchers found that if you double your schedule performance, product success goes up by 70%. If you double market knowledge competence, product success goes up by 94%. Doubling both schedule and market knowledge performance will improve product success by 140%.

Yes, time-to-market is important. And yes, you can pay a price in lost revenue and (possibly) market share if you are late. But, unless you are in the consumer electronics business, or some other market where product life spans are measured in months not years, the importance of time-to-market is easily blown out of proportion.

Launching a product that does not meet customer expectations is a surefire way to lose ground to your competition. In the long run, a good product launched late will provide a better return than a product that no one buys. And let’s not forget, many times schedule slips are the direct result of poor market knowledge in the first place.

So before you tie your team’s bonus plan to time-to-market metrics in a vain attempt to achieve product success, ask yourself does your PD process deliver products that meet or exceed customer expectations? Make sure you are doing all you can to capture the voice of the customer before pushing hard on time-to-market goals.

Focusing on Product Development for Your Economic Recovery

In these challenging and turbulent economic times it is becoming increasingly important to be efficient and effective in Product Development to sustain manufacturing business viability. Customers are demanding higher performance, more features and more benefits from new products. Quality is not just about reducing defects anymore. It is about meeting customer needs in an ever changing environment. Best practice companies do Product Development well by focusing on three key areas; structure, cross-functional engagement, and knowledge sharing. Emphasizing and improving in these areas can help reduce cost, time-to-market, and frustrations commonly encountered in Product Development projects.

Companies that successfully take new product ideas and launch them into the market have well defined product development processes. These structured processes define the steps, activities and gates a team goes through to filter, select, define, develop, verify and transition products into production. The structure and process documentation is a guideline to set expectations and commonality across organizational resources for clarity. One misconception about developing a common product development process is that they are rigid. This is only that, a misconception by many that have never worked with a formal structured process.

Getting cross-functional and cross-departmental resources engaged in the process up front eliminates fire-fighting towards the end of the process. The first step is for management to make everyone aware that cross-functional cooperation is expected. Cross-functional engagement should extend to your supply chain, internally and externally, in order to set expectations and capture knowledge from experts outside the core team. Involving cross-functional resources in the Scope and Requirements development will ensure a smoother transition down the line as other departments become tactically involved.

Giving Performance Feedback the Blue Angels Way

I was talking with a colleague awhile ago about how to do effective performance appraisals. We talked about the usual stuff: performance management isn’t an event, it is a continuous process; it is a cycle that begins with setting goals; throughout the year you observe, coach and document; and the cycle restarts with an annual performance review.

And we both acknowledged how important it is to give feedback right away – not just at the annual review. Not at the monthly program review. But today, when the memory of what happened is still fresh.

Important stuff. But since you’ve probably heard it all before, I am not going to go there today. Instead, I am going to tell you about the best example of on the spot performance feedback I have ever seen.I am talking about the Navy’s Blue Angel flight demonstration team and their post flight briefings.

Improving Your Product Development Process

Phase gate development processes are used in some form or another by almost half of companies developing new products. Well implemented gate processes can actually speed development by assuring the program is on-track, has adequate resources and hasn’t overlooked a critical task.

Poorly implemented gate processes can cause schedule delays. For example, a process that lacks flexibility can cause delays if a team must wait for a gate review to be executed before starting work for the next phase. And if gates are put into the process arbitrarily, the team will be burdened with “make work” tasks that serve as window dressing for an upcoming gate review.

How can you make sure your gate process is creating value at every step?

Let’s start by taking a look at a prototypical development process in the figure. This is the default product development process taken from PD-Trak™. Although, they may go by different names, the first two stages of this process are pretty much the same in every company’s process.

PD-Trak™ product development gate process (click to enlarge image)

The Investigation stage is a filter for all the new product ideas that have been put on the table for consideration. Ideas are usually scored by the executive team on the basis of criteria such as strategic fit, likelihood of successful in this market, the technical know-how required to develop and manufacture the product, and so on.

The Feasibility stage usually introduces more detailed financial metrics used by management to determine which projects should be funded. What is the size of the market? What’s our projected slice of the pie? How much will it cost to develop this product? Do we have the resources required?

Sun Tzu's Art of Waging War Against Patent Trolls

Patent trolls, many believe, lurk around looking for patents so they can sue businesses who actually do their own product development. Patent trolls, or non-manufacturing entities (NMEs), are companies in the business of buying patents to bring lawsuits and participate in YOUR hard-earned revenue.

Now, some people find this objectionable- perhaps even enough to wage (legal) war against patent trolls. If this is your persuasion, or you want to learn more about strategies Sun Tzu might have used to beat a patent troll, then check out this article.

This article is a refreshingly comprehensive menu of options for handling patent trolls. It unlocks some excellent strategic ideas that, until now, could most easily be gained at the cost of an impressive legal bill from a top IP law firm.

The main limitation of the article is that is necessarily superficial. Implementation of many of the ideas calls for experienced legal counsel with expertise in areas such as reexamination and patent litigation strategies - which are deep subjects unto themselves.

Bottom line: If you have any interest in an overview of the patent troll game, and how to win, check with Sun Tzu, and see if your patent lawyer needs a copy.