PD Clarity

The most important PD activity you're not formalizing

noreply@blogger.com (Jim Nelson) — Mon, 17 May 2010 16:15:00 +0000

To produce a winning product you need 3 things:

Understanding of stakeholders wants, environment, assumptions, priorities and what is feasible
Sharing the vision
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:

Define the scope - identify Needs, Goals and Objectives
Create operational concepts
Involve all stakeholders in writing requirements at system, assembly and component levels
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?

noreply@blogger.com (Greg Burneske) — Wed, 21 Apr 2010 18:32:00 +0000

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

noreply@blogger.com (Greg Burneske) — Fri, 09 Apr 2010 21:30:00 +0000

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

noreply@blogger.com (Jim Nelson) — Thu, 25 Mar 2010 16:38:00 +0000

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:

Leadership
Strategic Planning
Customer Focus
Measurement, Analysis, and Knowledge Management
Workforce Focus
Process Management
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 fourth category is Measurement, Analysis, and Knowledge Management. Metrics help you keep a microscope on your projects, products and organization. Ensuring that you are measuring and analyzing the appropriate metrics is critical to long term success. This also helps keep your engineers and design personnel sharp and focused on continuous improvement. Capturing, managing and sharing knowledge is becoming increasingly critical to flexibility in product design and project execution. We no longer have time to repeat the mistakes of yesterday or redo something within our project's time frame. Knowledge is the new "Gold Mine" of success.

Workforce Focus, the fifth category, is comprised of workforce engagement and environment. Your engineers, designers and technicians should be engaged at many levels to achieve organizational and personal success. Assessment of these personnel is important to keep individuals performing at high levels. As leaders it is also important to assess your workforce capabilities and capacities to complete projects and action items. You need to create an environment where your employees are safe and supported in their work climate.

Process Management is the sixth category and the one we see with the opportunity. How you organize, plan and proceed through Product Development is critical to the three R's: Right product, Right price, Right time. A stage-gate product development process with cross-functional/departmental involvement is key to helping everyone being on the same page at the same time. Again, continuous improvement, is critical to keeping the process relevant and fresh with changes in the market, competition, customers and your own organization.

The seventh and final category is Results. Summarize your product development performance results from internal and external perspective, including segmenting as necessary. Using data to drive customer-focused results is paramount to driving decisions and fixing what is wrong. There are many areas to review in this area of product development, including Financial, Timing, Workforce, Processes and Leadership. A balanced blend will help to keep the burden reasonable and the information valuable.

The Baldrige criteria are a great way to look at product development from a slightly different angle and apply proven assessment to drive improvements and success. Using the categories in simple analysis and through leadership focus can help drive incremental improvements for results in people, processes and projects. We will look at individual categories in the future and dive in on how details can be gleaned to hone the assessment for product development success.

The Myth of Multitasking

noreply@blogger.com (Greg Burneske) — Fri, 19 Mar 2010 18:30:00 +0000

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

noreply@blogger.com (Greg Burneske) — Mon, 15 Mar 2010 20:46:00 +0000

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

noreply@blogger.com (Greg Burneske) — Sat, 13 Mar 2010 20:53:00 +0000

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

noreply@blogger.com (Greg Burneske) — Mon, 08 Mar 2010 12:15:00 +0000

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

noreply@blogger.com (Greg Burneske) — Thu, 25 Feb 2010 15:10:00 +0000

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

noreply@blogger.com (Greg Burneske) — Sat, 20 Feb 2010 22:25:00 +0000

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

noreply@blogger.com (Greg Burneske) — Thu, 11 Feb 2010 13:54:00 +0000

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

noreply@blogger.com (Jim Nelson) — Sat, 06 Feb 2010 22:36:00 +0000

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.

The most effective companies, that are quick to market and thought of as innovative, share knowledge with structure and as a process. Knowledge is only powerful if it is used by the right people at the right time. Many companies repeat the same mistakes because there isn’t a formal way of documenting and sharing knowledge with those that need it. Developing a system for documenting critical know-how can reduce these ineffective repeats. It can be something as simple as a shared folder with appropriate documentation and all the way up to a PLM tools with forms, templates and steps aligned within the product development process.

Many companies today have fewer resources and more pressure to meet customer needs. Adding some structure to your product development process will help engage your resources and reduce frustration from not knowing what to do next. Engaging cross-functional resources throughout the process can accelerate the transitions that take place down the line. Sharing knowledge and documenting lessons learned increases the effectiveness of your resources by eliminating repetition and increasing awareness to opportunities.

Giving Performance Feedback the Blue Angels Way

noreply@blogger.com (Greg Burneske) — Thu, 04 Feb 2010 05:50:00 +0000

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.

I am sure you have seen the Blue Angels in action. Wingtip to wingtip formation flying. Head on passes at 400 mph. It is some of the most spectacular flying you will see (aside from the equally amazing Air Force Thunderbirds) and it is all choreographed with split second precision. There is little margin for error. If a pilot rejoins the formation a little late or one airplane is a little out of position the consequences can be fatal.

To the average spectator, every Blue Angel’s show looks perfect. But, Blue Angel performance standards are very high and the pilots will tell you every flight has more than a few mistakes. And, just as in any other endeavor, each of those mistakes is an opportunity for the pilots to learn something.

To make sure the learning occurs, immediately after each and every show or practice flight, the team sits around a table and critiques their performance. The discussion is led by the Flight Leader. The critique is objective and sometimes blunt. This is no time for Minnesota Nice. No one benefits from holding their tongue or sugar coating the facts. Each and every little detail that was not spot on is identified and discussed. The Blue Angels call these opportunities for improvements “safeties” (for safety violations).

“Number 4, you were a little late on the power coming out of that last turn. You need to clean that up next time.”

It is remarkable enough that the post flight critique is so comprehensive. But what is truly amazing is there are no “yeah, buts” or excuses made. After receiving feedback from their teammate, each pilot responds the same way. They look their teammate square in the eyes and say, “Thank you. I will fix my safeties. I am glad to be here!”

Can you and your product development team display that kind of professionalism when given a little performance feedback after your next design review, project status meeting or customer presentation?

Feel free to leave a comment about how you and your team deal with the need for immediate performance feedback.

Improving Your Product Development Process

noreply@blogger.com (Greg Burneske) — Mon, 25 Jan 2010 12:26:00 +0000

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?

Notice that in the first few stages, we are trying to answer the fundamental question: Should we fund this project?

But in the later phases we start to see differences in the process from one company to the next. These process differences are driven by differences in markets served, technology, organizational structure and how much development work is out-sourced. Consider the myriad of questions that may be found in later stage reviews.

Are we ready to start market launch activity? Have we successfully completed validation testing? Are we ready for the pilot manufacturing run? Have our key customers approved the prototypes? Have we filed patent applications and/or developed our IP strategy for dealing with competitors patents? Are we ready to start clinical trials (medical device firms)?

The questions will be different from company to company. There is no “one size fits all” development process -- especially when it comes to the later stages of the process. So, how do you go about creating, or improving your gate process?

Here are a few tips for creating an effective process.

Key Questions: Identify the fundamental questions that need to be answered in order to know the program is on track. Formulate questions around recurring problems and risks that need to be managed. Group the questions on a timeline for a typical development project. Place the questions on the latest possible point on the timeline in order to avoid forcing premature decisions. Look for clusters of questions. These clusters tell you where your gate reviews should be.

Alignment to the Critical Path: Put gates at the end of critical path tasks that are common to your programs. If the release of tooling dollars is typically a big deal in your company, then consider incorporating a “tooling release” decision into one of your gates. If validation testing is critical, make it part of a gate review. Your gates should reflect the critical decisions unique to your business and products.

Permeability: Gates should not stop the team from working ahead. You don’t want your development team to sit idly waiting for the gate review to happen. Sure, working ahead means there is a chance they might have to rework something after the gate review has happened. But, usually the benefits of progress outweigh the risk of a little rework.

Parallelism: Use gates to make things happen in parallel. One gate can be used to assess the results of verification testing, the status of marketing plans and manufacturing readiness. Don’t let the stage names fool you here. Just because Manufacturing / Deployment is the last stage in the PD-Trak™ process doesn’t mean manufacturing engineering is not involved at earlier stage reviews.

Fewer Gates: This one goes hand in hand with creating parallelism. Reducing the number of gates forces you to put things in parallel and vice-versa. If you have more than 5 gates, you should look for opportunities to lean your process out.

Remember the 5 Elements: Awhile ago I wrote an article listing the five elements of a good PD process. Review that article and make sure your process measures up.

Sun Tzu's Art of Waging War Against Patent Trolls

noreply@blogger.com (Craige Thompson, JD, EE, PE) — Thu, 21 Jan 2010 16:23:00 +0000

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.

Do You "Own" Your IP? Understanding the "Work Made for Hire" Doctrine

noreply@blogger.com (Craige Thompson, JD, EE, PE) — Mon, 18 Jan 2010 13:38:00 +0000

How much of the value of your company is in its IP (intellectual property)? Depending on what business you are in, the answer can range from “a little value” to “the most critical asset”, or somewhere in between.

If you tend toward the “most critical asset” end of the spectrum, then the first IP protection issue for you to address is: Do you own your IP?

To resolve this fundamental question of ownership, many business are unaware that they should pay special attention to the "work made for hire" issue in their dealings with independent contractors. In general, your company will be able to secure patents and copyrights in any inventions and creative works developed by your employees. You might be surprised to find out that an independent contractor who develops something for you automatically owns the rights to any patent or copyright-- unless the contract specifies otherwise.

The president of a small medical records software company believes he lost at least two million in business for lack of simple IP protection. He hired a software developer to develop a key product, but the contract failed to address the “work made for hire” doctrine.

The contract should have provided that all copyright to the software belonged to the medical records company. Absent this simple provision, ownership of the software copyright defaults to the software developer.

This unfortunate scenario came as a shock to the president of the medical records company, which paid over $600,000 to develop the software. The unscrupulous developer who owned the copyright turned around and sold the software to several of the medical records company’s competitors for only $50,000. If the medical records company had received the copyright via some simple language in the contract, then the software would have been owned exclusively by the company, instead of being offered at a substantial discount to its competitors.

The president of that medical records company is now keenly aware of the “work made for hire” trap that arises when you use an independent contractor to develop software. This same trap arises very frequently for small businesses that hire someone to create a website, which has copyright issues, or to develop a prototype that yields a patentable invention or two.

Bottom line: You can protect yourself by seeking advice before using an independent contractor to develop a key asset for your business. A brief meeting with an IP attorney may help you identify and protect your valuable IP, and avoid traps like “work made for hire.”

Disclaimer: This post is for informational purposes, is not being offered as legal advice, and does not form a basis for an attorney-client relationship.

Leveraging Suppliers in the Product Development Process

noreply@blogger.com (Jim Nelson) — Fri, 15 Jan 2010 13:56:00 +0000

Following up with the event I moderated for the Manufacturers Alliance, here is some more information and guidance on the topic of using outside resources in the product development process.

Many businesses outsource non-core product development tasks to suppliers. The most common supplier outsourcing opportunities are found in areas where the OEM does not have expertise or the risk of outsourcing is low. The most significant factors for the success of these relationships are communication, alignment and knowledge sharing. The suppliers have their own culture, methods and experiences that can inhibit or enhance the process. Up-front in the relationship, it is important to have requirements developed at a relevant level for meeting expectations between the partners. There is a time commitment to developing this understanding and increasing the depth of knowledge.

Communication is ultimately the most significant success factor for leveraging resources outside of your organization. The OEM – supplier relationship benefits from continuous and open communication. Decision will be made more quickly and there will be fewer unstated assumptions if a good communication plan is established and followed.

Alignment of goals, culture and processes is important to success of an outsourcing effort. Misalignment of expectations and lack of understanding of the complexity of the task at hand can cause delays. Alignment can be especially tricky when dealing with off-shore suppliers. Having a local representative or coordinator that understands the both organizations can significantly increase the effectiveness of an outsourcing relationship.

Knowledge sharing relates directly to communication and success of the relationship. Immersing your supplier partner in the background information, goals and analysis of issues significantly decreases the learning curve and accelerates the alignment of project goals. This is especially important for complex products where only parts of the design are forwarded outside the OEM organization for development.

As time- to-market pressures increase, leveraging external product development resources on your project is becoming common-place and necessary. Successfully using outside resources is dependent on your ability to instill knowledge sharing, alignment and good communications into the relationship.

Time and Time Again

noreply@blogger.com (Greg Burneske) — Tue, 12 Jan 2010 19:39:00 +0000

I spend a fair amount of time talking with engineering managers from OEM companies about how to achieve better project outcomes. A common theme in many of these conversations is some projects simply take too long. Inevitably someone will ask, “How much more time is being spent on your projects than was budgeted?” Often the answer is, “I don’t know, we don’t collect time from our engineers."

It surprises me that so many OEM companies don’t require their product development engineers to log time and fewer still use project cost accounting methods to track their projects. How do you expect your organization to improve product development efficiency if you don’t measure actual project costs today?

By contrast, in the contract product development world time is like inventory. Every billable and non-billable hour is accounted for. Actual project costs are tracked and compared to budgets in real-time in order to identify budget problems (and by extension, schedule problems) proactively. You don’t want to surprise the customer with unforeseen costs at the end of the project, so you use the project cost accounting system to manage exceptions to the budget. This is where earned value management techniques can be really helpful.

A close cousin to project cost accounting is resource allocation planning. Meaningful resource allocation occurs when functional managers and project managers play nicely to forecast their resource needs for some extended period of time (usually 8 to 26 weeks depending on your typical project schedules). The process of resource allocation forces hard choices and commitments to be made.

Meaningful resource allocation is hard to do well if you don’t have a project cost feedback mechanism. If, at the end of the month, no one really knows where all the time was spent, don’t expect your team to feel particularly committed to the resource allocation plan. No one is behaving badly here – we’re just dealing with human nature.

It usually happens like this. Marketing Mary asks Engineer Bob to help with an urgent, but unscheduled task. This task will jeopardize the current resource allocation plan, but Engineer Bob does not want to say “no” to Marketing Mary. Bob helps Mary, so right then and there his project is just a little bit off track. And since there is no feedback mechanism to verify that everyone followed the resource allocation plan, no one is going to be held accountable for not following the plan.

On the other hand, if project time is tracked and periodically checked against the resource allocation plan, new behaviors will sprout up. Knowing their managers are held accountable for the resource allocation plan, Engineer Bob and Marketing Mary might talk to their respective project managers to get agreement on priorities before Bob gets diverted from the plan. In the end, everyone might agree to put Mary’s task ahead of everything else and Bob's project may still take the hit. But, now everyone will know why, and expectations can be managed accordingly.

There are other benefits to tracking actual project costs which I can’t fit into a short article on the topic – accountability, visibility, better estimates and RD&E tax credits to name a few. But the bottom line is you can’t improve what you can’t measure. Start measuring actual project costs today if you want to make meaningful improvements in project outcomes in the future.

Should Start-ups Use a Gate Review Process?

noreply@blogger.com (Greg Burneske) — Fri, 08 Jan 2010 04:25:00 +0000

I was talking with the founder of a technology start-up company recently who told me that his company could not possibly use a gate process because his team needed to be flexible – product requirements were constantly changing and new markets were being identified. Start-ups simply don’t have the time to spend managing a gate process.

Having performed my share of contract product development work for technology start-up companies in my past life, I knew exactly what he was talking about and at some level had to agree. Still, I walked away feeling like I had missed an opportunity to help him and his company improve the odds of success. Research by Cooper, and others, clearly shows that gate processes help established companies achieve higher rates of product development success. Why would that not be the case for start-ups – specifically, technology start-ups?

If you have ever been involved in a technology start-up, you know there is incredible time pressure from investors to get a product to market. On the surface, it seems that there really is no time to “waste” running projects through a gate process.

But the goal for a tech start-up is not just to get any product to market, but to get the right product to market. This is true for any company, but it is critical for start-ups since they usually don’t get a second chance if the first product out of the chute isn’t successful.

A number of years ago, I helped a tech start-up develop proof-of-concept prototypes for a wireless technology they had developed. The founders knew that they were on to something big and their technology was superior to what other companies had to offer at the time. There was no shortage of good product ideas. But lacking a disciplined gate process, and market strategy, they struggled to parlay their technology into successful products and the once promising technology failed to produce significant success for the company.

Technology start-up companies face a dizzying array of decisions when it comes to product development. For example, most technology can be deployed in different market segments. The latest video compression technology can be deployed in high-end, broadcast quality, video equipment or low-cost, consumer grade, Wi-Fi video cameras. Even within a given market segment, there are choices about product features and functions that can make or break a product. Compare the success of the iPod to previous generations of MP3 players.

So, how does a tech start-up make critical decisions in a way that maximizes the probability of success?

When used properly, a gate process can help the tech start-up distill the myriad of options down to the essential product strategy that will increase the chances of product development success. A gate process serves as a funnel that turns ideas into good product specifications, good product specifications into business plans, and business plans into successful product launches. Each successive gate in the process challenges the team to provide objective evidence that they are on track to launching a winning product. If the team has done their homework, we can move the project to the next stage. If not, risks are identified, hard choices are made, and alternative plans are developed.

The more I think about it, a tech start-up probably needs a disciplined gate process even more than an established company does. I think it is time to reconnect with the founder of a tech startup I met a few weeks ago.

Practical Project Management

noreply@blogger.com (Greg Burneske) — Mon, 04 Jan 2010 19:13:00 +0000

I will be leading a three day workshop on practical project managment, January 19 - 21, at Anoka-Ramsey Community College. Although Project Management fundamentals are the same for almost any size business, the tools, techniques, and communication requirements that work best for large businesses may not be practical, or useful, for small business. Project managers at smaller organizations usually wear a variety of hats and the success of their projects hinges on their ability to balance their project managment responsiblities with other management duties. In this workshop we will cover essential PM concepts as well as strategies the part-time project manager can use to achieve full-time project manager results.

Anoka-Ramsey Community College
Coon Rapids, Minnesota
January 19 - 21, 2010
8:30 AM to 4:00 PM

Register at Anoka-Ramsey

Elements of a good product development process

noreply@blogger.com (Greg Burneske) — Thu, 17 Dec 2009 22:40:00 +0000

Robert Cooper (author of “Winning at New Products” and “Portfolio Management for New Products”) has researched hundreds of companies and finds there are three cornerstones of product development commonly found in successful companies. First, successful companies have a high quality product development process. Second, they have a clearly defined business strategy which is linked to the product development strategy. Third, they have adequate resources for the new product development effort they plan to undertake.

Today I’m going to take a closer look at the first of Cooper’s cornerstones – process. What makes a good product development process? How do you know if your process makes the grade? I think there are five essential elements in a good product development process.

Up front homework is done well

This means you have a well defined product specification early in the process and you understand the market you are trying to penetrate. This is easy to do if you have been successful in the target market. But what if you are going into unfamiliar territory, then you will have to spend more time and energy up front before you commit to development. There are plenty of well documented tools for doing up-front homework. We will document many of them in upcoming posts to this blog.

Your process calls out well defined requirements at each stage

Everyone knows what is required for successful completion of each stage of the project. If the process calls for risk analysis at Gate 2, you have a template for the work to be done so it can be done well every time. If your process calls for market research, you have a clear definition of what constitutes adequate research. You may have different levels of detail required for different types of projects, but expectations should be defined well enough that the team knows if the requirements of the process have been met.

The process must allow for flexibility

A good development process should allow the team to make conscious decisions to skip steps when it makes sense to do so. With a well defined process, you can be very explicit about what is being skipped, why it’s being skipped, and what the potential consequences are.

Some people will tell you they don’t use a gate process because they think gate processes are restrictive and their business requires flexibility. Well, I don’t see the contradiction between a well defined gate process and flexibility. There is a big difference between making a conscious decision to skip a few steps in a flexible process because they are not relevant to a particular project, and shooting from the hip without a process. The first approach is being flexible. As for the second approach, if you can’t say something nice…

The process is well executed

The best laid plans are useless without execution. Besides having the right people in the right seats on bus, there are two keys to good product development process execution. First and foremost, the executive team must be committed to the process. The old adage, “what interests my boss, fascinates me” holds true.

Secondly, people who are expected to use the process should be given proper training. The previous two elements (well defined requirements and flexibility) are prerequisites for establishing a good training program. You can't expect your star studded team to execute the play correctly if you don’t give them a playbook in the first place.

The process is used to make tough decisions

Finally, we have to use the process to make tough choices. If a project isn’t really ready to proceed because the market research is not complete, put it on hold. Even with a good process and good up-front homework, you may occasionally approve the wrong projects. If market realities have changed since the project was approved, it may be better to kill the project at the midway point than to keep putting resources into it. Bad projects tend to get a life of their own especially in companies that lack clear criteria for what a good project should look like. If a project isn’t meeting the requirements of the business, kill it.

In my next article I am going to look at some of the reasons small and startup companies give for not using gate processes. Reasons such as, our company is too small to use a gate process, or we’re a startup developing one product so we don’t have time to use a gate process.

Using the Right Tools in Product Development: What, When, Where, How?

noreply@blogger.com (Jim Nelson) — Mon, 14 Dec 2009 19:35:00 +0000

How do you choose what tool to use for the issue you're dealing with in a specific stage of product development? There are hundreds of tools available and many of them are duplicates that do the same thing in a different way. There is a need for a matrixed list of tools with PD Stages and the relevant category that the tool is used for. I have developed such a list and will present it this Friday at the Breakthrough Forum discussion called “Tool Time”. Attendees will receive a comprehensive list of tools including a brief summary of what the tools are used for and when to use them.

Breakthrough Forum
December 18th, 2009 7:30 - 11:00 am

U of M, Dorsey-Ewald Conference Center
1000 Westgate Drive
St. Paul, Minnesota

Hope to see you there.

Leveraging Product Development Resources

noreply@blogger.com (Greg Burneske) — Fri, 11 Dec 2009 22:51:00 +0000

Jim Nelson (Clarosys) will be moderating a discussion on creative ways to leverage product development resources. This panel discussion is sponsored by the Manufacturer’s Alliance.

January 14th 2010 07:30 AM to 9:30 AM

Hennepin Tech College - Brooklyn Park, MN

How and where can you find the best talent to accelerate time-to-market for new products? Our local colleges have labs to help with prototyping and interns for market surveys. Suppliers often can be your partners for developing the next best thing. There are also many outsourcing, internet and global alternatives. Hear from our presenters on how they are leveraging both internal and external resources to their competitive advantage.

Panelists include:

ACIST Medical Systems, Inc. - Karen Kensok, Vice President, Product Development
Shock Doctor - Jay Turkbas, Vice President of Product Development
Tennant - Evan Graham, Senior Engineering Manager

We hope to see you there!

PD-Trak™ New Product Development Software

noreply@blogger.com (Greg Burneske) — Thu, 10 Dec 2009 02:53:00 +0000

PD-Trak™ is an integrated project management, portfolio management, and resource management software solution. It can be used for development of discrete and process-oriented manufactured products, software development, and service development. It provides project management, gate review, and product development tools and a common document repository to support product teams as well as portfolio management software functions, multi-project resource management and performance measurement tools for executive management.

For more information about PD-Trak™ or to schedule a demo contact Clarosys.

The One-Page Project Manager

noreply@blogger.com (Greg Burneske) — Thu, 10 Dec 2009 02:37:00 +0000

One of the most difficult tasks facing a project manager is presenting project status in a simple, clear and accurate manner. It is the job of the project manager to show executive management, and team members alike, where the project stands in terms of schedule, budget and risk. But, it can be painfully difficult to collect all the pertinent information to put all of this information into one, easy to read, report.

Some managers advocate various forms of "project dashboards". Followers of Toyota TPS religion sing the praises of A3 status reports. I've seen a lot of attempts, but I've never seen a silver bullet solution to the problem of project status reporting.

I just read a nifty little book by Clark Campbell called The One-Page Project Manager published by John Wiley and Sons. In it, Campbell describes a simple Excel based template for reducing any project into a simple, one-page, document designed to communicate status details to management and team members.

What I really like about Campbell's approach is how he maps objectives, tasks and responsibility on the same easy to read report. Major project objectives are mapped to a high level Gantt chart. Individual team members who are responsible for completing the work are identified. You see, not only the status of tasks, but the status of the project objectives (which are the real essence of the project).

By using straight forward symbology it easy easy to see what's on track and what's not. Information is kept at a fairly high level so the approach lends itself to high-level reports to C-level and board of director types who don't have the time or inclination for deep dives into MS-Project.

The templates Campbell shows in the book are a little weak on project financials. I am partial to earned value methods when it comes to project budget reviews for big projects. You could easily drop an EV curve, or your favorite view of the project budget, into Campbell's schedule status template.

At 140 pages (including index and table of contents) the book is an extremely quick read. Free templates can be downloaded from Campbell's website. In Campbell's words...

This uncommonly practical guide shows you how to reduce any project into a simple, one-page document that can be used to communicate all essential details to upper management, other departments, suppliers, and audiences. Developed at O.C. Tanner, the world's leading employee recognition company, this one page system shows readers how to identify the five essential parts of a project, construct a one-page "OPPM," use the document as an effective management and communication tool, and adapt this tool for use in other projects and organizations.The One-Page Project Manager is the ultimate tool for beleaguered project managers who understand the value of simplicity.

If you need a better way to convey project status to your team or your boss, The One-Page Project Manager is worth your time.