The 8th Word That You Can't Say On Television...

The late George Carlin became famous thanks to a skit that he did titled "The 7 Words That You Can't Say On Television". I'm thinking that he missed a word -- RISK. Why should this be added to the list you say? Simple -- nobody dares to say it out loud!

A couple of university professors, Charalambos Iacovou and Robbie Nakatsu, recently decided to do the unthinkable: look into just how risky pushing IT development projects offshore really is. Although this type of discussion is normally what project managers stay up nights worrying about, at the end of the day if there are problems, then Product Mangers are going to be in trouble also. That means that offshore project risk is everyone's problem.

I know that I've worked for several companies that viewed offshoring as a great new black box: drop a project in one side of the box and magically a completed IT product should pop out the other side. As anyone who has working on an offshore project knows, it never happens that way. The two professors reached out and talked with 15 project managers who had experience with offshore projects. They asked them a bunch of questions and got some interesting answers. The biggest revelation was:

Outsourcing magnifies existing risks and creates new threats.

There's nothing earthshaking there (sorry to readers in southern California); however, the project managers that were surveyed provided some interesting reasons for why this is true. Here are the top 3 reasons that offshored projects run into problems:

• #1: Lack of Top Management Commitment
  I like to call this one "out of sight, out of mind". The immense amount of effort that goes into setting up an offshoring contract often results in senior management viewing the development problem as being "solved" and they move on to other more pressing issues. Without their involvement, the offshore vendor can start to not do what you need done.
  
  
• #2: Original Set Of Requirements Is Miscommunicated
  One of the project managers said it perfectly: ... you will get exactly what you asked for, so you better make sure you are asking for exactly the right thing. Every single product that I have managed has started with only partial requirements that pretty much all changed during the product development process. Even the thought of trying to deliver a complete set of requirements to an offshore team at the start of a project makes me laugh -- it just can't be done.
  
  
• #3: Language Barriers In Project Communications
  We're not talking about whether the offshore team can speak English (or Spanish, or whatever). Rather we are talking about the bigger question of if the two teams can actually understand each other. The professors point out that much of our team communications is based on cultural assumptions. This means that when you think that the other side understands what you just said, they probably don't.

The end result of all of this study is to tell us that offshoring development work will increase the risk in a project and thus make a product even more risky to bring to market. So should we stop offshoring? No way -- the economic benefits are too great for that to happen.

Instead, firms need to realize that by using offshoring as a part of their development process, they are increasing the RISK of the project/product. This means that they need to spend more time training both their project and product managers about the unique risks that offshoring brings and how to deal with them.

Until this is done, I don't think that you should use the word RISK on television...


Tags: risk reduction, offshoring, project management, new products

The Secret To Successful IT Product Management Is ...

... leadership. Sorry in advance for this rant, but I've just about had it with product managers who spent their time whining and complaining that nobody listens to them. Pretty much across the board I've seem organizations where IT Product Managers get less respect than Rodney Dangerfield (on a good day!). In talking with these Product Managers, I think that I've heard just about every excuse that you could imagine: "it's really an engineering company and I'm not an engineer", "they don't work well with women", "most of the team is in India and they think differently", "this is a low priority project", etc. To which I say, just shut up already. The time for Product Mangers to feeling sorry for themselves is over - nobody has time to listen to them anymore.

What's wrong with all of these complaints? The accusing finger of blame is pointing in the wrong direction: it's not everyone else's fault, it's the Product Manager's fault. Yes -- I'm blaming the Product Manager, get over it. We really have done a lousy job of clearly defining who we are, what the qualifications to be Product Manager are, and just exactly what value we bring to the company. Who can blame everyone else for not respecting us?

What's Wrong With Product Managers?
Most (98%) of Product Managers don't understand the #1 rule of being a Product Manager: you are the CEO of your product. I really don't care if anyone told you that you were (normally they don't); however, they sure are going to hold you responsible if it fails so you may as well grab the reigns and start to drive that product wagon because if you don't, then nobody will.

A good 75% of Product Managers then go on to mess up Rule #2 of being a Product Manager: it's all about the people. Do you know what the difference between a project manager and a Product Manager is? Scope. A project manager has a clear start and finish to a project and gets to lose him/herself in tracking the progress of that project. A Product Manager operates on a higher plane and needs to ensure that the world is ready for the product once the project manager is done. Oh, and that the product that was created was the right product with the right features.

What To Do?
So what is a Product Manger to do? Let's keep this nice and simple -- show some leadership. A Product Manger can't "manage" because nobody works for them. Instead, a Product Manger needs to inspire those that he/she works with in order to have them work on those items that the Product Manager needs to have done. IT staff, finance staff, marketing folks, etc. all need to come together and do work at the request of a Product Manager for whom they do not actually work. The only way that this can be done successfully is for the Product Manager to set an example of leadership by showing the team the correct way forward. This means that the Product Manager needs to have great interpersonal skills, lots of time and patience, and the ability to simplify complex product status in order to communicate it to many different parties.

How hard can this be? It turns out that it is very hard. There are lots of different Product Management courses out there; however, there is precious few courses on Product Management leadership. Maybe it's time that Leadership becomes the new focus for all Product Mangers...


Tags: IT Product manager, leadership, project, CEO

Brainstorming: How To Do Them The Right Way!

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: innovation, innovation, program managers, IT products

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

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

Product Manager Alert: Dealing With Hard Core Opposition Within Your Company

We've talked about why IT Product Mangers find it hard to get any respect. Now it's time to talk about the why's and how's of what to do when you run into another department (or person) who acts like a brick wall. Thanks to millions of years of evolution, we are all pretty good at recognizing situations in which we are called on to compete with other departments who are willing to do business with us. We are tuned to allow us to make ourselves heard in these situations and to get our point across. Which is why we all seem to do such a poor job when we are faced with not competition, but rather opposition. Oh, oh. What to do now?

So what is opposition? Opposition is what happens when the group of people that you are trying to communicate with are just dead set against what you have to say. This is not unique to Product Management -- a Project Manager has exactly the same problem. If you show up in a situation where you are going to be telling your team about a great new product that the company has decided to start development on , you will encounter opposition if nobody that you are talking to wants to work on that product in the first place -- it's not that the new product is a bad idea (although it might be), it's just that everyone rejects the idea of working on that product.

What's funny is that although in technical fields we struggle with how to deal with opposition, the folks who work in politics deal with it on a daily basis. Our elected officials are forced to deal with opposition everyday and so they have developed effective ways of dealing with it. We could learn a thing or two from them:

• Co-opt The Other Side's Issue: this is one of my favorite approaches. Don't go head-to-head with the opposition. Instead take a careful look at what's motivating their position: why doesn't the other department want to work on your product? If you show respect for their underlying issue and then go ahead and propose a different way of solving it, you'll basically cut off the opposition at the knees. In our product case, if you show the team that offshore developers do a poor job of creating products when there is minimal documentation and by doing a good job of development their work they will be able to keep more jobs onshore, then you've accomplished your co-opting.
  
  
• Redefine The Issue: Initially an issue may start out as a tug-of-war. In order to solve this problem, if you redefine it in such a way that it is no longer a tug-of-war, then you can win the other side over. In our product example, the issue could start out as a "the company is telling us to do more work". This could be redefined as "Other companies have created products that interface with our product. In order for them (and us) to be successful, we have to extend the interfaces that they are using to connect to our product." All of a sudden, what was something that was being created for the faceless company becomes a tool for specific small business owners.
  
  

If you can become skilled at learning to distinguish opposition from competition, then you will have a hard-to-find skill that you can start to use proactively. Do a little bit of research on the department that you will be communicating with. If there is strong opposition to what you will be discussing with them, it will probably come out quickly. Look for ways to co-opt or redefine the issue and you'll have accomplished half of your job before you even open your mouth.


Tags: passive aggressive, opposition, issues, redefine, co-opt

How To Make The Best IT Product Management Decisions

Warren Bennis is a smart guy (professor of business administration and chairman of the leadership Institute at the University of Southern California). He's cranked out a book called Judgment: How Winning Leaders Make Great Calls and it has a few ideas that really relate to how IT Product Managers can make better decisions.

It turns out that the ability to make good judgment calls when you are a Product Manager is very important (surprise!) because of the impact on others that all of your decisions make. When do these Product Managers get called on to make judgment calls? Warrne identified of the most common three areas: people, strategy, and what to do in a crises. We see the impacts of people judgments around us at work every day. Technically gifted folks who get put into a product team management role for which they are poorly suited, great team leaders who get bumped up and become paper-pushers, etc. The successes in choosing the right people for the right job gets reflected in how successful the product will be. The mistakes can cause lots of damage and are expensive to replace and to repair.

Strategy judgments are the big ones that can make or break a career. In today's hyperactive IT product development environment speed is often prized over accuracy. Warren brings up a great IT product example in his book: Intel. Many folks don't realize this, but Intel got its start in manufacturing and selling memory chips. When the prices in this market started eroding and the Japanese manufacturers started coming on strong, Intel had to make a product judgment call: stay in the memory chip business or move on to something else? Gordon Moore and Andy Grove made the decision to move on (to CPUs) and the rest, as they say, is history. Good judgment call.

Finally, the ability to make good judgment calls in in middle of a crisis. Once again Intel serves as a good IT product example. Back in 1994, as Intel was releasing the latest version of their x86 chip line it was discovered that under certain circumstances it would return the incorrect answer from a math operation. Initially Intel took the IT road in its response: it did some math and stated that the average user would only see an error once every 27,000 years. However, that didn't sit well with most of their customers and eventually Intel had to offer to refund/replace the defective chips. This initial response was a very, very poor judgment call on Intel's part.

So what can product managers do to make better judgment calls? Warren suggests that we work on improving four areas of our knowledge that are critical to making good judgment calls: self-knowledge, social-network knowledge, organizational knowledge, and stakeholder knowledge. Hmm, sure sounds like aligning the product management organization with the rest of the business would go a long way to making this a reality!


Tags: crises, Intel, IT Product Manager, judgment, people, strategy

How Do You Know If Your Product Is On Track Or In The Weeds?

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