Managing Product Development

Jim, in his comment on Intuition is Not Enough for Knowing About the Project Portfolio, said:

I am having trouble with the definition of the word “value” in this context. Do you mean showing progress, as in earned value, or value to the customer, such as in ROI or payback period? Value has become a loaded word. Please define your terms.

To me, value is some visible form of progress. I prefer working product. I can live with a demo. I can live with a prototype. In some very small number of organizations, I can briefly live with a document. A document ceases to be visible progress after a very small period of time, such as a few days, maybe a week. Demos and prototypes also lose their value over time, if they do not become working product.

Managers can’t make good decisions about the portfolio if they can’t see visible progress, so they can tell if the money they’ve spent is worth the time they’ve invested.

If I really knew how to calculate ROI (and not make it be a number I can just make work), I would use ROI. But that’s a bigger rant for another time.

I’ve been using BackUpWordPress to backup my blogs. I successfully upgraded Hiring Technical People to a newer version of WP and of BackUpWordPress. I upgraded this blog, Managing Product Development, to the newer version of WP, but now my newer version of BackUpWordPress is not working. I’m pretty sure it’s all about file permissions.

If you have experience with this and insight, please email me, jr at jrothman dot com. I can’t figure out what I’m doing wrong and want to keep backing up! Thanks.

Via Jack Vinson, I found this gem: Stop doing half-actions.

All of you who are separating your developers from your testers? You are doing half-actions. Separating the writers from the developers and testers? Half actions there, too. Even when you define architecture and implement across the architecture, instead of by feature, that’s a half-action. A half-action means you have technical debt and will have to get back to that area of the product.

Silos encourage half-actions (or third-actions or sixth-actions). Defining the architecture and implementing across it encourages half-actions. Create a cross-functional product development team. Have them finish one feature at a time. That’s a full action.

I’ve been reading Jeffrey Kaplan’s book Strategic IT Portfolio Management, as part of my research for my project portfolio book. He says something astounding (I’m paraphrasing a sentence on p.73:

Managers intuitively know when their projects are not delivering sufficient value.

Wow, that has not been my experience at all. My experience is that managers don’t know sufficient details about the states of their projects to know which projects are delivering any value at all.

Managers need data. And they don’t need the awful traffic lights (red/green/yellow) to tell them about the state of the project. Any non-agile project can’t be anything other than yellow (if the PM is honest) until some pieces of work are finished. An agile project doesn’t need traffic lights if the team creates a velocity chart and compares it to what was committed for an iteration.

If you’re a manager, ask your PM to create some sort of project dashboard, maybe even using some of the ideas in Manage It!.

It’s fine to have intuition. But unless you know what to measure, your intuition doesn’t have a good chance of being right. Why risk your organization’s success on intuition when you can measure a few things other than dates, and greatly increase your ability to manage?

I ran into Dan North at the Agile conference today, and explained a little about the project portfolio book. I’m writing it because I have a number of clients who are having trouble breaking the multitasking habit (working on more than one project at one time.)

Dan said, “Oh, you want them to commit to serial monogamy project management!” I cracked up.

He said exactly the right thing. No one has to be married to a project forever–just long enough to finish an iteration. (That’s why serial lifecycle projects are so hard. You have to stay married to the darn project forever.) But once you finish an iteration, you’re free to marry another project.

Thanks, Dan!

I’ve been steadily writing the project portfolio management book this summer, and was describing what I do to Steve Freeman someone today. (I’m at the Agile 2008 conference.) I explained that I had a list of things I thought should be in a chapter, but it wasn’t a real outline the way other people outline. He replied, “You have a backlog for each chapter.”

Of course, that makes sense. I write those pieces. Sometimes they stay in the chapter in which I originally thought they went, sometimes they have to move. Sometimes they go to the chapter that’s called “stuff to put somewhere.” (Which might be nowhere for this book.)

I’m not good about outlining. I am good at seeing a bunch of related ideas and sometimes I’m good at weaving them together. But I don’t always see the organizing theme (which is where Daniel, my editor, is a huge help). Without the organizing theme, I don’t always have the backlog in the right place. But I do like thinking about those bullets at the beginning of the chapter as a backlog.

Having a chapter backlog is a useful metaphor for me, because it helps me keep my eye on the theme (iteration goal), and not try to do more than that for a particular chapter.

Now, if I can just remember who said this to me today

One of the big problems in organizations (IT or product-shipping) is how to fund projects. I don’t believe in ROI (Return on Investment). I learned how to lie with ROI back in 1988–I can make the numbers be anything you want. If you don’t have ROI, how do you know what projects to fund?

One set of projects is the set that if you don’t do, you can’t compete. Have a hardware-software solution? Better be thinking darn hard about a software-only solution that runs on several platforms. Or, a Big Gorilla  vendor such as Microsoft or Oracle changes what they support. You have to upgrade to a new platform.

But all the other projects, especially the risky projects, how do you fund those? Incrementally.

I don’t give my kids their allowance yearly. They get their allowance once a week. They get a clothing allowance in two parts, so that they can’t spend all their money on fall clothes and have nothing for the summer. That’s the same idea as funding software projects incrementally.

Of course, that means you have to build software projects incrementally, in some sort of a timebox. (Gotcha!) But here’s why it make sense to do that:

• If you show value to someone, preferably your customer, you are much more likely to get more funding.
• If you’re not showing value early and often, you get feedback early enough to change before you start a death march for something your customers don’t want.
• You can start highly risky projects, because you’re not committing a ton of money and time to that much risk. You’re just committing 2, 3, or 4 weeks.

If you’re having trouble getting your projects funded, stop asking for the whole huge project. Make the project show value first, fund that value first, and see how much it actually cost you to provide that value. Now you have a little information and can decide whether or not to continue. You never have to throw good money after bad.

A reminder: I’m teaching a public project management workshop in Waltham, MA, Sept 22-24, 2008. If you would like to:

• Understand different lifecycles and when (and how) to use them
• Practice pragmatic approaches to organizing and estimating a project
• Learn a variety of ways to steer a project to success
• Learn how to develop and use release criteria
• Design the data you want to use to measure your project
• and practice, practice, practice this and more

You’ll want to join us. Everyone receives a copy of Manage It! Your Guide to Modern, Pragmatic Project Management. (If you have that one, I’m happy to substitute another of my books.)

The more formal syllabus is here. The registration form is here (note the discount for multiple registrations at the same time). If you have questions, email me. I hope you join us.

I was shopping today, taking advantage of the summer sales. One of my favorite retailers offers petite sizes online, but almost nothing in the store. I go to the store to try the clothes on and then decide what to order online.

I had a number of blice (blouses to those of you who are not aware of alternative plurals to order, and the nice salesperson who was trying to type my information into the form got frustrated, “I keep putting the wrong data in the wrong boxes.”

“It’s not your fault,” I explained. “The developers should have sat with someone in a store to see what it’s like to input the data when you’re interrupted and holding onto clothes, and all the things that happen when you’re on the floor and not in a back room.” She then explained that the form was the same whether you were online or in the store. But the problem is the data available online is different from the data available in the store.

I don’t know if the developers were lazy, or pressured, or if it just didn’t occur to them to test the system with a real user. But a salesperson should never have to apologize to me about the lack of user interface keeping me at the store longer than it should have. It wasn’t her fault.

User experience design and implementation is difficult. But why make it more difficult by not getting feedback from the users? I’ll never understand.

I was speaking with a potential client about their approach to knowledge management. They think they need a senior person to organize a top-down appoach, and build a custom tool, so they know what knowledge they want to manage and have a place to put it.

I don’t think that’s going to work. That approach requires they know what kinds of knowledge they need to store and who will need access to it, and when. They don’t know any of that now.

Here’s what I know about knowledge management:

• You can’t create an electronic system until you understand what you’re trying to manage. That’s because the kind of information changes over time, not just the content.
• The Dreyfus model of knowledge acquisition infers that electronic systems are fine for novices, advanced beginners, and maybe the competents. But the people who really make a difference in the organization are the proficient and expert folks. Those people cannot easily put their knowledge into an electronic system, nor can the other people acquire their knowledge that way. Knowledge has to be transferred one-on-one, within a team, inside groups, between groups, and company-wide as the very last step.
• If you put people in competition with each other *in any way*, they will have dis-incentives to share their knowledge.

Given all of that, it’s not clear to me a top-down approach to knowledge management can work at all. What I do see as necessary is to have the managers (or some person):

• See the pockets of knowledge
• Plan some adaptive, people-based, timeboxed systems of knowledge management
• Measure where the knowledge management systems are headed
• And steer the people to do better

To me, agile approaches would work well. You could try something for a short timebox and see if it’s working. If so, keep doing it until it doesn’t work or needs another storage mechanism. Now you’ve got some experience to know what you need.

Starting with a tool is backwards, if you really want the experts who have substantial intuition to impart their knowledge.