"IT Product Management" blog has moved!

You should be automatically redirected in 6 seconds. If not, visit
http://www.theaccidentalpm.com/
and update your bookmarks.
Thank you very much!
- Dr. Jim Anderson

Showing posts with label IT products. Show all posts
Showing posts with label IT products. Show all posts

Thursday, July 24, 2008

Brainstorming: How To Do Them The Right Way!

IT departments need to learn to brainstorm in a group

If you've even come close to a business book in the last 5 years or so, you have probably discovered that "innovation" is what every IT organization is desperately trying to capture, grow, encourage, enhance, etc. Although this sounds like a great idea, and IT product management is one area that would directly benefit from this, it turns out that it's actually quite hard to do consistently over time. What gives?

One of the key skills that an IT organization needs in order to be innovative and to develop better IT products, is the ability to brainstorm as a team well. We all THINK that we know what it means to brainstorm; however, it turns out that more often than not we are wrong. Too often we think of brainstorming as being a solitary task where we go off an think about a problem until an apple drops on our head and the answer emerges. Matt Bowen who is the CEO of Aloft Group spends a lot of time teaching his marketing firm's employees how to brainstorm as a group -- a much more powerful form of brainstorming. Here are his suggestions for how you can learn to use this powerful tool:

  • Creativity Starts With The Hiring Process: When you are inviting people to join your team, you need to make sure that they will be able to contribute to the group's ability to innovate. This means that you need to understand how they think. A great way to do this is to ask them to tell you stories about jobs that they've had. If their storys revolve around creating new solutions than you know that you have a creative type. If instead, they focus on incremental improvements in the way that things are done, then you're probably talking with an operations person.

  • How To Prepare To Brainstorm In A Group: The best way to learn to do this is to jump in and just do it. You will need to have a designated facilitator to lead the process. The first thing that the facilitator needs to help the group do is to very clearly lay out a single sentence that clearly describes what the goal of the brainstorming session is. Distribute this sentence a day or two before the meeting to everyone who will be attending so that they can start to think about it. Also, the facilitator needs to spend some time establishing criteria for how he/she thinks the resulting ideas need to be rated. What's are the most important characteristics of a solution and how should you rank them?

  • Group Brainstorming Rules: Never have the meeting last more than an hour. Limit the size of the meeting to no more than 5-7 people (less if the facilitator is new to this). Try to make sure that the participants come from different departments because this will help to ensure that you get multiple perspectives. Normal brainstorming rules apply: no critiquing, no editing, no such thing as a bad idea, and always try to build on other people's ideas.
The real key to successful brainstorming lies in what you do AFTER the meeting. The facilitator needs to assemble a group of people to rate the ideas generated by the brainstorming based on the criteria that was established before the meeting. This group can be different from the group that created the ideas.

Finally, don't you let the resulting ideas die! In order for brainstorming to catch on in any IT department the staff need to see changes occurring that they can clearly relate back to brainstorming sessions. Do this and you'll have an innovative IT department that will be the envy of the rest of the firm.

Tags: , , ,

Monday, July 21, 2008

Stop The Madness! A Rational Approach To IT New Product Development

IT departments can learn a great deal from Eli Lilly

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: , , ,