Managing Product Development

I’m excited to announce that Roy Osherove’s interview with me is now posted on IT Conversations. Here’s the link to the interview. Roy interviewed me about the hiring book, and of course we segued into project management and management issues. Enjoy!

Tweet This Post 

In Greg’s provocative comment, he says, “The idea that contributor initiatives are a drag on an organization speaks more to the insecurity of the management than to its skills.” I’ve been noodling that comment since I received it. I agree with Greg that some managers are insecure enough to insist that they make all the decisions about the work that the organization should do, who should do it, and when. But that’s not where I was going with my general suggestions about not allowing skunkworks projects to continue. Here are two examples of skunkworks projects that hurt the organizations:

In the early ’80s, I worked for a machine vision company. As an organization, we were bad at estimating, managing, and finishing projects. We started having a layoff every quarter. One of the people who’d been laid off kept coming back into work to finish his project. This project had one potential customer (it was a specialized application). The developer wrote the code so no one else could understand it. However, he needed changes to the set of libraries for his application to work. He worked for free, but the work to support his project consumed several people over the course of several weeks, starving other projects of necessary people. Our management wasn’t talented, but they had decided on a strategy, and this project didn’t fit. But this project stole cycles from other projects, preventing them from success. And the potential customer wasn’t willing to pay for it.

A few years ago, a very large client reorganized their product offerings. One of their strategies was to stop supporting old products and migrate customers to a newer product that cost less to support and had more features. The manager could not bring himself to stop supporting the customers for the old products, and attempted to support both old and new products — an impossibility given the number of staff. Here, the first-line manager was the one keeping the skunkworks projects going.

Maybe neither of these is a typical skunkworks project. I’ve certainly worked on skunkworks projects where the technology was new and exciting, and our current management could not see how to exploit it. That’s why I believe every technical person needs some slack time now and then, so they can be thinking of ways to exploit the technology they are working on. As much as I respect the talented marketing guys and senior management strategy (when it really is a strategy), there’s nothing like letting a technical person play around with prototypes, a whiteboard, and a few good buddies to develop/exploit a new technology/product. That’s what happened in the Graphing Calculator story.

But what I mostly see in skunkworks projects is not exploitation of a great idea or new technology. Most of the time, I see people wedded to projects that no longer fit the organization’s strategy — old products that should be put to death. And the more people work on them — even for free — the more those old products cost the company. Greg, I agree with you that managers who feel the need to micromanage everything are insecure and don’t belong in a healthy organization. But I don’t agree with the notion (not that you said it) that all technical-contributor-led projects need to continue. Sometimes technical people are wrong-headed about their product ideas too.

I wish I knew of a recipe to develop a reliable product strategy. I don’t think you can create a real product strategy without input from the technical people (in the form of prototypes, or even partially finished products), nor can you create it without understanding what your known buyers want (product marketing input). The technical people may well create something that breaks you out of your current market — or breaks open your current market to something much bigger. But that comes with hard work on all sides: management for taking the time to think about a strategy and eliminating the dead products; marketing for looking for the needs that exist and the needs no one knows about yet; and the technical people who know how to exploit the technology looking for something new and different. Ignore one of these, and you’ve eliminated at least 1/3 of the potentially great ideas.

A little slack time for technical people goes a long way towards developing a product strategy — and reducing management insecurity.

Tweet This Post 

Read The Graphing Calculator Story. (Thank you to Obie Fernandez for finding this gem.

Some ideas that stood out for me:

• The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.
• …he told his manager that he would start reporting to me. She didn’t ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive.
• we needed professional quality assurance (QA), the difficult and time-consuming testing that would show us the design flaws and implementation bugs we couldn’t see in our own work. [...] One guy had a Ph.D. in mathematics; the other had previously written mathematical software himself.
• … my sanity was saved by the kindness of a stranger (there are several stories of people who helped in various ways)
• Sitting behind a one-way mirror, watching first-time users struggle with our software, reminded me that programmers are the least qualified people to design software for novices.
• Dozens of people collaborated spontaneously, motivated by loyalty, friendship, or the love of craftsmanship.

When I’ve written about canceled projects in the past, I’ve recommended that managers not allow skunkworks projects like this to continue, because there is too much drag on the organization. However, for this project, the drag appears to have been minimal — but I’m not sure. Can you say that your project is composed of people who collaborate, are internally motivated to create something wonderful? If not, do you know what you could do to move the project staff towards that frame of mind?

Tweet This Post 

I’m looking for a reference to something I thought I read but can no longer find.

Technical people can work up to 6 hours a day on technical work.

They may be at work longer, reading email, going to meetings, getting coffee, but they can only effectively do 6 hours of technical work a day. (Yes, for short periods of up to a couple of weeks, people may be able to do more. But once they get tired or they’re not taking care of their personal lives, they can put in as much time as you want, but you won’t get nay more out of them.)

in case you’re wondering, I’ve measured this (number of technical hours of work per day) on some of the assessments I conduct. In several cases, people were only accomplishing about 4 hours of work per day (too many meetings). At the most productive places, the average was just under 6 hours per day.

Let me know if you have a source for this.

Later… I was catching up on blogs and found Ole Eichorn’s Tyranny of Email. In the essay, he talks about working in three-hour chunks. On page 15, he explains:

Here’s another reason for three: it kinds of “fits” into a workday. For example, you get in at 8:30, check email, pick up voicemail, do all that. Then you shut everything off and work for three hours, ’til say 12:30. Now you break for lunch. You get back at 1:30, check email, pick up voicemail, do all that. Then you shut everything off and work for another three hours, ’till say 5:00. Then you check email, pick up voicemail, play foosball, run around and bug everyone, etc. You’ve had two nice periods of time to get work done.

Tweet This Post 

I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do . For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem.

So what happens if there’s a requirements problem that led to a design problem that led to a larger (greater than a couple of days worth of work) development problem? To me, that’s a short project. Once the problem is larger than just coding errors, it’s not maintenance, in the sense that I think about it. If you have to rewrite requirements or fix the design or involve more than just the one or two authors, it’s bigger than “maintenance”. And once it’s a small project, I can manage it with all the other small projects that are part of a release.

This means that when I work on projects, I see the work differently than others seem to. Because I believe everyone has to fix the problems they created, and because I see maintenance as just fixing those problems, I don’t have a problem with maintenance. I do have a problem with scope creep, but not in the sense of new requirements. I have a problem with trying to finish the work the project staff said was already done but isn’t.

That’s why I ask people to plan inch-pebbles, why I use milestone criteria, why I ask developers to implement by slice instead of by architecture, why I request that technical staff completely finish one thing before they go on to another. A by-product is that I don’t normally have to deal with maintenance, unless I’m coming into a project after it’s already started.

What’s your definition of maintenance?

Tweet This Post 

Due to incredible volume of spam comments, I’m moving to a new commenting system. The new one is installed. I’m working on importing the old comments to this system. In the meantime, it’s ok to leave comments here.

Tweet This Post 

In my project management class today, one of the students asked about how to schedule interdependent sub-projects. The scheduling tool he uses doesn’t deal well with pieces of one sub-project having dependencies of other sub-projects. It’s difficult to see the critical path, and to know what’s really going on. (It’s too easy to have circular dependencies in the scheduling tool.) I asked if they scheduled by architecture component or by feature. I’m not sure if I understood the answer (or if the student understood the question), but I think they’re organizing around architecture pieces.

If you have a number of sub-projects and they’re coupled (have dependencies on each other), try rethinking how you organize the work. I bet if you organize the work by feature instead of by architectural component, you’ll be able to schedule easier. My student wasn’t so sure this would work — he has some scarce people resources who need to work on multiple features. I suggested they rank the features by priority (1, 2, 3, 4, …) and have the scarce people work on features in rank order. This requires cross-functional teams and the ability to recreate small feature-driven teams. This would be a huge change for the student’s company.

I’m a bit stuck. I only see program management (treating each feature like a project, managing all the projects, and using cross-functional development teams to perform the work) as a solution when you want to break tightly coupled interdependent sub-projects. Since I can’t think of three alternatives, it’s time to ask for help. Do you know of any alternatives?

Tweet This Post 

Clarke Ching’s Multitasking MAKES YOU STUPID is another great article. But when I teach PMs or coach managers, they say, “I need to multitask to get things done.” Or, they say, “I’m ok with multitasking.”

Even smart people think they can do a couple of things at one time. Maybe they can. But the more things you try to focus on, the less overall you do. Think about that word focus for a few seconds. When you focus on something, you concentrate. If you’re attempting to think or work on several different things, you’re not focusing on anything.

I once worked for a company who decided its mission was to “focus on five.” Even then, I knew five was too big a number. But when I suggested we focus on two, my suggestion was dismissed. Company no longer exists.

Deciding what to do –and what not to do — is not simple. I just created a simulation (Esther reviewed it for me) to hammer home the point that we all have a limited attention span, and when we pay the necessary attention to one thing, we’re not paying attention to something else. In the simulation, people have to make choices about what to do and what not to do. I’m using the simulation for the first time next week. We’ll see how it goes. Maybe I’ll be able to report back.

If you’re faced with multitasking demands, stop for a few seconds. What’s the most strategically important work? Do that first. If you have three or seventeen things you think are all at the same importance and you can’t rank them, ask your boss. You’ll find that a bunch of the things you think you’re supposed to do may not even need to be done. Just don’t think you can do them all at the same time, because you can’t.

Tweet This Post 

I’m teaching a few project management courses in Israel next week at Sela. If you’re in Israel, and would like to have dinner on Dec. 7, let Roy know. He’s arranging a dinner. Thank you, Roy!

Tweet This Post 

Yesterday, I was talking to a colleague about a new job he’s considering. It’s in a regulated industry, and he had some assumptions: that regulated industry auditors assume a waterfall lifecycle and that organizations require process people to improve the process.

Regulated industries do not require a waterfall lifecycle. What they do require is that you show requirements traceability from the beginning of your work through the testing. They want to know you didn’t add anything more than what you said would be in the product, and they want to know you tested what you said was going to be in the product. You can do that with any lifecycle. Some of us would say you can do this better with an agile lifecycle (There’s more that regulated industries want, but requirements traceability is huge piece of their process issues.)

But I found his other question more disconcerting. The more I work with people who try to change things, the more I’m certain that process people who are divorced from the everyday stresses of product development is wrong. The managers have to be responsible for process improvement, or it’s just another management fad.

I’ve seen process people used effectively in organizations when they act as internal auditors, who can explain where the current process isn’t working, and as experts who can explain how to make the process better. But the people who own the process are the people who live and work the process — not the process experts. Assigning some percentage of the product development team as full-time process improvement specialists cheats the team out of the domain expertise these people have — domain expertise that would be helpful in product development. And, if you have full-time process people who don’t have domain expertise, why do you think they could help you in your product development?

I loaned out my copy, but Capers Jones in Software Assessments, Benchmarks, and Best Practices, (page 133), says that reuse, ability to manage, and ability understand the domain are the three most important factors in software product development. The factors are something like 300 for reuse, 85 for management and 75-80 for domain expertise. Process is down around 30-40 as a factor for successful product development.

If you want a process that will meet regulator’s needs, understand how you obtain requirements and how you use them all the way through your projects. Use experts and internal auditors to help you assess how well you do what you say you’re going to do. Measure what you do and see if that’s where you want to be. Make sure each manager has process improvement goals that benefit the entire organization, not local benefits. That’s the way to do real process improvement. Not with an army of process people.

Tweet This Post