"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

Monday, June 30, 2008

Tracking Your Product Development: What Works, What Doesn't

Product Managers Need To Track Their Products in Development

The job of product management often takes on a program management flavor when it comes to keeping track of how the development of a new product is coming along. It's probably important that I come right out and say that product management is a completely different job than program management; however, the two worlds do intersect when it comes to tracking product development. How an IT product development project is tracked is one of the ways that you can distinguish between a good product manager and a bad one.

So what's a product manager to do? More often than not, I've found myself having to create a means to track the status of a project that is creating my product. Often this project will include external firms, internal development, marketing, sales training, etc. As anyone with an IT background can tell you, there are countless ways to track a project like this; however, too many of them are cumbersome, awkward to use for IT products, and don't really do a good job of answering the questions that you (and your management) will be asking.

Physical File Folder w/ Sticky Notes: In all honesty, I have several IT product management friends who successfully use this system. They are all females and I'm not sure if this has something to do with why it seems to work for them. What I do know is that when I've tried to use it, it's been a complete disaster. This systems only requires you to put all pertinent information into a single file folder and then carry it around with you at all times. Critical information such as dates and contact info can be written on Post-IT notes and stuck on the inside of the file folder. Forget PDAs and laptops, if you know where your info is, you can answer just about any question quicker than your competition. The downside of this system (for me) is that it's not visual -- you can't tell where things are by looking at a summary of the information. Additionally, you need to occasionally spend time and resort/organize your folder in order to make sure that you have up-to-date copies of everything. I always run out of time to do this and then the whole thing just falls down.

Microsoft Project: everyone in IT likes this tool (at least deep down). We like it because it's complicated enough that we feel like if we feed it enough information it will tell us what to do. I have seen some very detailed Project plans; however, I've never really seen an IT project successfully use this tool. Much of the tool's functionality does not pertain to an IT project. One of the big problems is that very few people seem to have copies of Project and so you end up sending out PDF versions of the plan. Then you get busy, the plan doesn't get updated, and things fall apart.

Microsoft Excel: This is my weapon of choice. Everyone seems to have a copy of this application so you can share files and folks can make changes to it if needed. There really is no learning required in order to be able to use it. As a committed visual learner, I use Excel to make lots of colored progress charts. More often than not, I color in cell by cell to show the status of a given set of tasks. When the colored rows are stacked on top of each other, then you can quickly see the overall project status. Oh, and this can easily be copied into PowerPoint presentations to be used at the next mandatory product status meeting.

So there you have it, three different ways to track the status of an IT development project. There is no one perfect answer and what works for one may be different from what works for others. In the end, it's just important that you have a system that allows you to quickly answer the questions that you know are going to be coming your way.


Tags: , , , ,

No comments: