Managing Product Development

John Cook, wrote a lovely post, Peter Drucker and abandoning projects, explaining how Drucker talks about abandoning projects. (John, thanks, I will definitely be referencing Drucker in the PPM book.)

I haven’t been using the word “abandon” when I describe stopping projects. I’ve been using the word “Kill” and the concepts of permanently stopping projects (killing them) and putting projects on the parking lot (stopping them for now). John actually says the words from a developer’s perspective:

It can be a tremendous relief to abandon a project.

He’s right. It is a huge relief to stop working on a project.

Here’s why I’ve been using the word “kill” instead of abandon. I want people to make a conscious decision that this project is not worth continuing at all. (The three possible decisions are commit to; kill; or transform a project.) Abandoning feels more like we can just stop the project in whatever state it’s in and walk away from it.

But I don’t know people who can do that. Every time I’ve seen managers attempt to abandon projects, the technical staff want to wrap things up, or get them to a state where the project can be shelved and restarted again later. That’s why I separate the ideas of stopping a project for now (and putting the project on the parking lot) and killing the project.

Here’s an example of why I feel so strongly about this. I was working for a small company as a developer many years ago. We were not making enough money. Management stopped a project “for a while” where the duration was indeterminate. Over lunch, I asked my boss when we would start it back up again. He said, “Never, with any luck.”

But that’s not what was communicated to the technical staff. One developer said, “Well, management has abandoned this project. But I’m not. I’m going to save this project.” Ouch, not what management wanted and not what the company needed. The company needed us all on a project that could actually make money, not the money pit. But the other fellow thought that management had abandoned the project, not made a decision to stop it. If our management had considered the killing or parking of projects, maybe my colleague would not have continued working on a project that had no future and was diminishing the ability of the company to make money. We would have been in better shape if we had killed that project.

Maybe kill is too strong a word.  But if we want to stop a project permanently, I do want to kill it. I don’t want people doing skunk work on it. I don’t want more investigation. I do want it killed. For me, abandon isn’t a strong-enough word.

And, if we can’t sufficiently fund this project now, I want to put the project on the parking lot, or somewhere in the unstaffed work list.

I hope you chime in with your reaction about abandon vs. kill.

I had coffee with a friend Saturday night. She said, “Our family has a tradition of starting many projects to see what we can stick with. If you don’t start a project, you can’t finish it.”

She’s right. You certainly can’t finish something you don’t start. But the real question for all of is: Should we start this project at all?

My current todo list is way too long. That’s because we took a couple of days off to visit with Mark’s family, and with the Jewish holidays mid-week both last week and this week, I’m “losing” time to family and personal obligations. (No, I don’t really think of it as losing time, just about the actions I choose when.)

In order to get my list of projects down to a manageable number, I’m choosing which projects I need to finish this week, which ones I need to make progress on, and which ones can be postponed starting until next week. Notice that I listed the projects I can finish first in that list.

I hate having partially finished projects, which is why I’m trying to finish a bunch of things this week, even though it’s a short week. I literally get stuck with all the projects on my list if I have too many projects.

Here’s my general mode of working:

1. Make a list of everything I have to do. Get it out of my head and onto paper. Yes, this is directly from Getting Things Done: The Art of Stress-Free Productivity by David Allen.
2. Look at the list and see when I have to complete what. Make sure I know my interim deliverables.
3. Lay out the deliverables week by week for a few weeks (not more than 4 weeks total, generally only 2).
4. For the deliverables owed this week, I do 2 things:
   • Ask, “Should I do this project at all?” It’s worth making sure this work is still valuable.
   • If yes, finish the deliverable this week. Now, my deliverables may not be done-done-done. I might have to draft an article or something and let it sit for a few days, but it’s a deliverable to me.
5. Of the deliverables this week, see if there is something I have to finish earlier rather than later. Do those.
6. Make sure I ask “Should I do this project at all?” for each project left.
7. Of the rest, do the ones that take the least time (which tends to be the most valuable for me), and get them off my plate. Since I don’t estimate that well, I never know exactly how long things take, but I’m pretty good at relative sizing.
8. Loop forever.

This is the essence of project portfolio management. I happen to be using it for myself, but it works. If you know that the work is valuable, then it’s a matter of slotting it into your week or weeks. And, if you use inch-pebbles the way I do, it’s easy (well, easier) to keep up with the work.

When my friend says she starts lots of projects and then decides if it’s worth finishing, she’s asking the “Should I do this project at all” question repeatedly. I tend to ask that question before starting, but the key is to keep asking. If you don’t, you are throwing good money after bad, wasting time.

If your projects are hobbies, it may be worth starting a bunch of projects to see what you’re interested in. But if you are making decisions on behalf of the organization, timebox each project. Make sure you know what the deliverables are and see if the team can finish those deliverables in a timebox. Now, your starting and finishing makes sense.

I was reading Ralph’s post, Whose Fault Is It?, and I realized that if you don’t know enough about management, you can misunderstand the root cause. Ralph’s example is of defects in an iteration and how they were not detected early enough because the acceptance criteria were missing. The criteria were missing because the testers and the domain expert were not available because they were also on other projects. I was surprised to see the reason for people on multiple projects be “matrix management.” But I can see why technical staff thought that was the reason.

The real reason is that the managers are out to manage *their* efficiencies of staffing all the projects. The managers are not out to optimize the organization’s throughput. (I don’t know this organization, but many of my clients have been in this position.)

Matrix management–itself–is not the evil. Multitasking is the evil. And the root cause is a lack of project portfolio management.

In PPM, you don’t commit to a project unless you can staff it. Fully. Period. No half-staffing. No 1/4 of this person and 1/3 of that person etc to make 1 FTE (full time equivalents). There is no equivalent for one person fully committed to a project.

Remember that, the next time your manager asks you to work on more than one project. “Which project am I fully committed to?” is a reasonable question.

Managers, if you feel the need to assign people to multiple projects, ask your manager which project is most important. Staff that one. Now ask about the next one. Stop staffing projects when you run out of people.

When managers optimize their work at their level, they are (almost never) doing this out of maliciousness. But if the organization rewards them for sub-optimal optimization, how can they not take advantage of it?

I was trying to address the issue of ROI (Return on Investment) in the project portfolio book. I don’t buy project ROI. FIrst, the idea of a project for software is an artifical construct–our consumers buy running tested features, that we happen to package in a project to release as a product. But the idea of ROI means you know how many consumers are going to buy/use the product, and you know how much you’ll charge for it. That means you need a crystal ball. Mine’s not working.

Instead of Producer-ROI, I’ve started thinking about Consumer-ROI. When someone consumes your product, what can they do with it? What kind of waste can they eliminate? What new abilities will they have?

If you think about one consumer at a time, and think about their capabilities and waste, you get a better idea of what the real ROI is. It’s possible to have examples of how the product would reduce waste or increase capabilities for a given consumer. Then you ask this question: which features help solve a particular problem or reduce waste for a specific kind of consumer?

I still don’t know how to predict Producer ROI (Project-based ROI), with any sort of assurance I’m telling the truth, but when I think about the users or potential users, I feel as if I’m more of the right track.

Bob Payne interviewed me at Agile 2008. We spoke about my initial plans for Agile 2009, and my (in-writing) project portfolio book. The link is here: Agile 2009 - Johanna Rothman - Agile Portfolio Management and Agile 2009. I had a blast with Bob.

If you’re wondering why it sounds like I’m chewing my cud (!), it’s because I was shivering. I was wearing a nice shirt and a nice jacket, but it was so cold in the area Bob had set up for the interviews, my teeth were chattering and my mouth was dry because I was so cold. Next year, I will bring my fleece, and possibly a scarf and gloves.

Glen Alleman has a post about program management, Managing Multiple Projects is Called Program Management which got me thinking. (I’ve written about program management in the past also: Program Management: Multiple Projects With Multiple Deliverables.)

But in the portfolio management book, I defined a few ways to think about your projects as programs:

1. You, and two other colleagues are managing projects that have interdependencies. In fact, you don’t have a product unless all three of you release at the same time. That’s a program and you need to treat it as such.
2. You are managing a bunch of checklist projects (you’ve done similar things in the past, and the risk is not in the project, the risk is in just finishing the work), but when you’ve done all of them, the company gains some sort of strategic advantage.
3. You are phasing releases of a product. That is, you’re working on release 3.2, then 3.3, then 3.4, and eventually 4.0. A program manager can manage the interdependencies among the releases, and a project manager would manage each release.

It’s the strategic part of “we don’t have success unless we all have success” that makes these examples programs.

BTW, I disagree with the difference between project and program managers that Glen quotes from the PMI Portfolio Management Guide. The same table (with the addition of portfolio management) is in the PMI’s Standard for Portfolio Management. IMNHO, a useless book.

Great project managers act like program managers in the table Glen quoted. But it’s worth thinking about program management, collecting related projects or project-like activities to fulfill a common strategic goal.

If you’ve never been a victim of Medieval software project management, wow, I’m impressed. You don’t have to read the rest of this post. But if you’ve ever tried to break free of a legacy product/project, and haven’t been able to, you are not alone.

The problem is we can’t create a knowledge management system that can copy everything in a developer’s head. So we attempt to keep the developer chained to that product, only to break free if he or she leaves the company. I left a job, and the company asked me to keep a listing of all of the files for that product. I explained I had a limited short-term memory, once I started with other things. “But what if I need you?” the manager wailed. “How else will I know what’s in the code?”

Uh, read the code. That doesn’t always work–some people like to make complex code. Or maybe, their code needs to be complex and I just don’t get it. In that case, read the tests. Oh, there are no tests? Hmm, maybe pair-write the product before you get into the one-person-one-product conundrum.

Here’s what I did when I was a manager inside organizations, and what I suggest to clients now: make sure a team works on each project. That means no single-person projects, ever. A team to me contains all the people necessary to release a product. Certainly a developer and a tester. Maybe a writer, maybe a release engineer, maybe an analyst. Maybe a DBA. Whatever it takes to release a product, everyone’s on the team. Everyone participates. If they can automate their work and explain it to other people, great. But it’s not a team unless the team can release the product.

When enough other people know about the insides of a product, it doesn’t matter if all the developers leave–the testers can explain what’s going on. Same if all the testers leave, the developers know. If all the writers leave, the testers and developers know what’s going on. Sure, there’s a learning curve, but no one is hamstrung by legacy projects.

There is no such thing anymore as a single-person project. If all you’ve got is one customer, you’ve still got a two-person project.

Managers create legacy projects because they don’t understand productivity and capacity. What managers need to care about is the number of projects a team can complete per unit time, not how busy any one person is. If you can’t complete n project because you’re still fixing legacy project (which was project n - 4), your manager is not being effective and neither are you.

If you have a legacy project, insist on a team to finish it. Or, if you’re like me, you quit after a while because you didn’t get the team and you couldn’t take it anymore.

If you’re a manager, count those legacy projects, and stick them in your portfolio to either finish or kill or park somewhere if you really think you can’t kill them outright. But stop the partial-staffing of legacy projects. That’s nuts. Either staff it or not. Don’t make people leave because you can’t decide what to do with this project.

I’ve posted my “Seeing Your Work” podcast. It’s available on libsyn and through iTunes.

If you’d like me to interview you or you interview me, lemme know.

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 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?