The IT field can learn a great deal about new product development from other industries. This time we’re going to learn from the big drug firms – they make excellent teachers. If you think about it, we’ve got a lot in common: both industries have to make big bets on unproven projects with the hopes that they will help make the company lots of money. Sometimes it works, more often than not it doesn’t.

The pharmaceutical business views all projects as belonging to one of two different groups: a truth-seeking group and a success-seeking group. The truth-seeking group of projects is focused on evaluating novel new product possibilities and weeding out the bad bets. The success-seeking group of projects is focused on making those products that have been cleared for development as profitable as possible. Hmm, can anyone think of an IT project that wasn’t automatically thrown into the success-seeking group without first spending some time in the truth-seeking group?

Eli Lilly has used this two-step approach to manage their new product development since 2001. What they’ve discovered is that it has been able to deliver products at 2x the speed and for about 1/3 of the cost. However, you never get anything for free. There are some side effects to using this two-step strategy:

• It will postpone the start up of successful projects.

• However, at the same time it will reduce the risk of failure in an IT environment in which the cost of development is high and the impact of a failure would also be high. If you work in an IT department that has had a lot of project failures, then this is an approach that can help you to absorb a great deal of risk early on in the project.

The sole purpose of an IT project in the truth-seeking group is to reduce the uncertainty about an IT project’s ability to deliver what the company is looking for as quickly and effectively as possible. Two types of IT errors can happen to a project that is in this group:

• Managers can ignore evidence that is telling them that the IT project won’t be able to deliver what it was designed to.

• The project is killed early before it has a chance to prove that it can deliver what the customer is looking for.

What this means is that for a product management team that is supposed to successfully launch new profitable products, they must avoid making both of these errors. Good luck killing bad products early while not killing good products too early! Using the two-group method allows a new way of thinking to be used to evaluate IT products. The teams can perform experiments on the products in the truth-seeking group in order to determine if they will be able to solve the end user’s problems. The teams need to be rewarded when an IT project in this group fails — they’ve just saved the company a great deal of money and frustration .

The problem with putting all IT projects automatically into the success-seeking group lies with us product mangers. Once we are assigned a product, we will use every trick in our book to gather whatever materials, facts, or figures are needed to show that we are still on track at each and every status review. Until it’s too late, nobody will ever know that our product is doomed for failure.

Using a two group approach to IT products will allow an IT department to implement a new metric: “speed to failure”. If a product is going to fail, then you’d like it to do so a quickly as possible. This type of approach to IT product development is not just another type of process reengineering. Rather it’s a whole new way of thinking that can reduce the risk associated with IT products while at the same time improving an entire IT department’s productivity.

Tags: IT product development, IT products, risk reduction, product failure

No related posts.

© Dr. Jim Anderson for The Accidental Product Manager, 2008. | Permalink | No comment | Add to del.icio.us
Post tags:

As an IT product is being developed, one of the big questions that a product manager has to continually answer is if the product is on track or if somehow things have gotten mixed up and it’s heading off into the weeds, so to speak. Although this sounds like a simple question to answer, in truth it’s quite tricky. The challenge comes from the simple fact that it is never possible to see the entire product creation process at one time. The best that you can do is to get snapshots of part of it. From these you have to determine if all is good or if it’s time to throw up a red flag.

We’ve already talked about the tools that you can use to track your product’s development, now it’s time to talk about exactly what you should be tracking. In tracking my products in the past, I have tried out countless metrics. Some were on the money and some were way off base. However, over time I believe that I’ve hit upon the six main metrics of an IT program that need to be continuously tracked by a product manager. Take a look and see if you agree with me:

1. Hardware: any IT product development process requires hardware to develop, test, integrate, etc. on. Initially obtaining and then making sure that everything is working correctly could be a full time job. I’m used to four different sets of hardware: development boxes, unit testing boxes, systems testing boxes, and production boxes. Each is owned and managed by a different team and you truly do need to constantly check with them to get status updates.

2. Staffing: In today’s modern IT environments, staff can be added and removed as needed by a project. As books have taught us, a product development process that falls behind cannot be magically saved by just throwing more people at it. Tracking who is currently working on your product and who isn’t is key to understanding if your are going to be able to meet your delivery dates.
3. Security: We all know that it’s a very bad idea to leave security features and tests until the end of an IT product development process. That’s why checking on the status of both product security features as well as the status of external security checks of the product and the boxes that it’s being developed on are critical.
4. Support: How an IT product is going to be supported is a critical question that can’t be left until the product is ready to launch. A so-so product that has great support can go on to be a winner (and likewise a great product can go down in flames with poor support). Involving the support teams in the product development and allowing them to make suggestions is the key to good long term support.
5. Testing: The testing team often inhabits the lonely no-man’s land between the developers and the software quality folks. Showing them respect and allowing them to understand what the product is really supposed to do is the key to ensuring that they do a complete job of testing.
6. Requirements: Last, but by no means least comes the product requirements team. I’ve seen all too many IT products start off with a great set of requirements only to have them fall down later on when features got slipped in by the developers and in the end nobody could say for sure what the final product actually did. Constant care and feeding of the requirements team will result in an excellent set of product documents showing up at the same time that the final product hits the street.

Sounds like a challenge doesn’t it? Take heart, if you can set up monitoring processes that keep track of these six metrics, you can rest assured that you’ll always know what’s going on in the development of your IT product.

Tags: hardware, IT product development, metrics, requirements, schedules, security, staffing

Related posts:

1. Product Manager Why Aren’t You Doing A Better Job Of Managing Your Sales Team? I don’t care if your product turns lead into gold,...