Managing Product Development

In general, technical people don’t seem to make great managers (unless they’ve been trying to become great). A result of that is what Reifer says in his IEEE Software (May/June 2004) column Catching the Brass Ring: “software professionals aren’t often tapped for top corporate leadership positions.” He goes on to say “executives of my acquaintance say that they (software folks) are ill-equipped to address anything but software or that they might be smart technically, but lack the systems knowledge and business acumen to take charge and make the organization successful.” Reifer suggest changing the graduate level curricula to change things. It’s not clear to me post-graduate education is necessary. Instead, take a look at this list from Peter Drucker’s June 2004 HBR article, What Makes an Effective Executive:

• They asked “What needs to be done?”
• They asked, “What is right for the enterprise?” (JR note: Project managers may have to focus on the project rather than the enterprise)
• They developed action plans.
• They took responsibility for decisions.
• They took responsibility for communicating.
• They were focused on opportunities rather than problems.
• They ran productive meetings.
• They thought and said “we” rather than “I.”

None of this is taught in graduate (or undergraduate) school. This list comes from knowing how your company makes money, how your part of the organization helps the total organization, how to develop tactics from strategy, and operational excellence in implementing those tactics. You don’t have to be an executive to practice these skills. In fact, I argue that successful agile teams work like this now. No matter what kind of a manager you are, if you use this list as a checklist against your skills, and continually improve those skills, you’re on your way to being effective, whether you want to be an executive or not.

I now have a new hard drive. And I’m back from vacation. Thanks to the folks at MacResQ, I didn’t lose any data at all. (Truly amazing with a broken hard drive.

If you need a chuckle, read commute mathematics.

When I travel, I catch up on my magazine and journal reading. A nice side-effect of that is synchronicity in what I notice about what I’m reading.

I’ve been trying to boot my computer for the last 3 hours. It’s not clear when I’ll fix the hard drive. No posts and no emails until I do…

Not all projects should be done. Some projects don’t even rate discussion. But sometimes it’s a lot harder to tell when a project is worthy and should be considered. Here are some questions I ask when trying to evaluate when a project is worthwhile:

• What business need does this project fill? (Does the organization obtain value from this business need)
• Is this project a strategic project for us? What makes it strategic? (Does the strategic reason behind the project change the importance of the project?)
• How does this project fit into all the projects we’d like to do? (Does this project make sense for us to do?)
• Have we done a project like this before? Were we successful? What did it take for us to be successful? Do we have any doubts about our ability to do this project? What are those doubts? (Are we doomed before we start?)
• Do we have the staff or other resources to do the project? (If we can’t adequately fund the project, what should we do differently?)
• What is the effect of finishing this project on time, not finishing this project on time, or not finishing the project at all? What ripple effect does this project have on others?

I supposed if I wanted to make this easier, I could have arranged everything in a table with a yes or no at the top of each column, and you could just mark yes or no. If you have enough yes’s, the project is worthwhile. The problem I have with that approach is that when I ask the first couple of questions with a senior management team, the answers aren’t always yes or no. Sometimes the business need is clear. Sometimes the strategic importance of the project is to have a small project to practice a new set of techniques on. Sometimes the time constraints make the business need clear.

If you use other questions, I hope you post them in a comment. Knowing whether a project is worthwhile is a huge part of management’s necessary decision-making. Because if a project is worthwhile, it’s worth funding, staffing, and moving along. If it’s not worthwhile, it’s worth killing — quickly.

If you haven’t read the comments starting from here from the previous posts, please do. Effern blew the whistle — so very nicely — when he perceived I hadn’t considered enough options.

It’s possible I didn’t consider enough options:-) (Maybe I didn’t develop three or more worthy alternatives.) What Effern did, oh so graciously, was to point out what he perceived as a flaw in my thinking, in a way I could hear it. I received the feedback, and although I’m not sure what else to suggest in that post, I’m still thinking. Which is a wonderful reaction to have. Thank you Effern for your tweet.

Adam, your tweet was also eye-opening. “Making clients earn proposals.” What a great way to discuss the two-way street that has to exist for a successful relationship.

Thank you Effern and Adam for your tweets.

I’m in conversation with a client about a possible project. The Big Guy wanted to meet with me immediately, but had constrained time, so I shifted my schedule and met with him. It was clear from our conversation that he didn’t quite know what he wanted, but he did want a proposal from me. I sent in a proposal and waited … and waited … and waited. (Not an uncommon occurrence

As I’m following up on this proposal, something is crystal clear to me: The Big Guy doesn’t respect the project. I’m not sure he respects me either — because I work on projects like this. So, because he doesn’t respect the project, The Big Guy is delaying any decision-making about the project, including assigning a project manager.

The Big Guy is causing this project to fail. He doesn’t realize the project has already started, and that with his lack of people assignment or decision-making, he’s creating a project no one will want to work on. The Big Guy is a good person, but doesn’t realize what his waffling is doing to the rest of the potential project staff. He’s telling the potential project team that he doesn’t have the hour or two to start the project right, it’s ok for him to delay it. The inference is that the project is useless.

It’s possible the project has no value to the organization — but I strongly doubt it. In my opinion, this project has the ability transform the organization, and I think that’s scaring The Big Guy out of his normal strong decision-making mode.

If you’re ever scared by your projects, or think you’re working on a useless project, or are in some other state where you don’t respect your project, you have several options:

• You can discover reasons to respect your project
• You can ask for help in discovering reasons to respect your project
• You can leave your project and allow the rest of the project staff to succeed with you

It’s not easy to leave a project, especially if you’re The Big Guy in charge of making the project happen. But your lack of respect for your project will cause great harm to your project. You can create a project that’s not worth anything by treating it from the beginning as if it’s not worth anything. If you want to kill the project, great. But if you do think there is value somewhere in the project, but it’s not your cup of tea, then respect your project enough to leave it, so that someone else can make the project happen. Especially if you’re The Big Guy.

One of the questions I ask project teams is how they know what to do when. Most of the time, the developers look at me as if I’ve grown two heads and say, “Well, we look at the requirements. We do the high ones first, the medium ones next, and the low ones if we have a chance.” I then ask the next question, “Do you ever find that some of you implement different high requirements in a different order?”

If you have a system with multiple components to the architecture, such as a front-end, middleware, and a back-end, chances are good the developers are separated into functional teams of front, middle, and back. And, unless the teams talk to each other continuously, the teams will each approach the requirements in a different way, not a coherent effort. What that means is that the UI for data entry is complete, but the middleware isn’t done or the back end database work isn’t complete. Or the watchdog time is done to kick off events, but the event code isn’t complete. When pieces of a product are done, without making sure the entire feature is designed and written from end-to-end, problems ensue:

• The testers can’t test, because they can’t test one piece of the feature without the others in place. Even if you have testers who can write code, they can only perform unit testing, or perhaps module integration testing, not system-level testing.
• The probability of not-enough features being complete at release time is high, higher than I like.
• If you’re dealing with a long defect list, sometimes developers will fix defects they perceive to be easier to fix, rather than ones the customers need first (even if they’re taking defects in priority/severity order).

One of my clients complained about ranking, “We’ll have hundreds of requirements. It’s overwhelming.” If you’re still doing big releases, ranking requirements helps you create smaller releases. (Take the first 10 requirements and make that a smaller release. You don’t have to release to the external world, you can release to the test group.) You don’t have to have iterations if that bothers you. You can use staged delivery as a lifecycle. But people can’t deal with hundreds of things on their to-do lists. It’s too easy to not have a sense of urgency about the task list if it’s hundreds of tasks long. But if you rank requirements, you can then rank tasks. You can use rolling wave scheduling to schedule just the next month’s worth of deliverables, and now everyone has a manageable task list. The PM can work with people to make sure they’re keeping a steady pace, and if someone can’t complete their work when they thought they could, the PM can see the impact of that easily.

If you don’t rank the requirements, the developers will do so when they implement the requirements. I’d rather the project team make a conscious choice about when to implement which feature. Conscious choices lead me to better planning and monitoring of projects I manage.

We’re getting ready for my parents’ 50th wedding anniversary, and my sister decided a scrapbook of family pictures would be a great present. She’s right, it will be wonderful. Mark and I were looking for pictures of us and our children, so we pulled out all of the pictures from the last 20 years. We have great pictures of us before we had children. We have great pictures of the girls with me. We have terrible pictures of Mark and the girls. Why? Because I took them. Some pictures are fuzzy. Some have heads, arms, feet cut off. My favorite is the one of Mark with one child - both people are so fuzzy I can’t tell which child it is and we can only see Mark from his glasses on down. I laughed so hard I cried. We found some pictures of Mark and the girls we can use, so we finished the necessary picture-finding task. But that got me thinking about my picture-taking ability. With film cameras, the feedback I receive on my picture-taking is significantly delayed, so I don’t yet know how to take good pictures. I’m better with an instant-film camera, but I’m hoping a digital camera will teach me to take better pictures. (When I told Mark this, he chortled and told me I was just competing with him for toys.

So what does this amusing anecdote have to do with product development? Everything. The further delayed your feedback is from performing the work, the less you can change about the way you perform your work. If you’re a developer, and you discover problems in your code only once the product is in system test, you don’t have feedback on the design or the implementation early enough to change how you design or code. If you’re a project manager, your decisions at the beginning of the project have a tremendous impact on the end of the project, but unless you set up systems to obtain feedback, you can’t know which decisions had what kind of impact.

No matter what your role is on your project, think about ways you can obtain feedback on your work as quickly as possible.

• Ask for peer review.
• Offer walkthroughs.
• Use the rule of three: what three things can go wrong with this design/test/project plan/whatever it is that you’re working on.
• Look for unanticipated side effects of decisions. (Especially if you’ve started some new measurement to go along with the decisions.)

I’m sure there are more possibilities than these, but the key is to be open to feedback from other people about your work product. The more immediate the feedback, the more likely you are to improve your work product. The more delayed the feedback, the fewer alternatives you see and the more costly the changes are.

Some of my suggestions for people in my classes are simply to buy some good books for some specific information. When I suggest this, I sometimes hear “my manager won’t let me buy books.” As a bibliophile, I can’t understand that :-). Even though I do accept that not everyone is like me, you can convince most managers to buy books.

First, realize that you’re selling the idea of buying books to your manager. If you haven’t taken a selling class or read a sales book, do that first on your own time. I took a Miller-Heiman class a long time ago that talks about different kinds of buyers (economic, coach, technical, user buyers) and ways to work with each of them. For this blog entry, let’s assume your manager has the money to buy the book (is the economic buyer) and can make the final decision.

Next, discover any objections your manager has. “Oh, is there a problem with this book?” If the manager has no problems, you can go on to articulating value. If your manager doesn’t believe in books in general, overcome the objection by showing there is more than just the book: “Oh, the author also writes articles and a blog. Here are some I found useful. And, so-and-so sent email to the author and received a response that helped him figure out his problem.”

Here are common objections to book buying and ways to overcome them:

1. “The book costs too much.” Your manager is talking about value here for the price. You can counter this by saying one of these things:
   • “Well, $30 is worth about half an hour of my time. I’m sure I can recover half an hour by reading this book and applying what it says.”
   • “What wouldn’t be too much? Maybe I can find an alternative book that would cost less.” If you’re considering a $100 book, this is certainly an option.
   • “Hmm, let me explain the value of the book to me.” Explain it. “Do you still think it’s too pricey?”
2. “You’ll take time away from working to read the book.” You can counter this by saying, “First, I’ll read it on my time. Once I’ve read the whole thing, I’ll bring it into work where I can apply it.”
3. “Everyone will want books.” Counter with, “Well, if our budget is tight for books, we could make a library. Then whenever someone buys a book, they can read it and put it in the library when they’re done, so others can read it.” Or, “Make book budgets part of our next raises, so you can have the discussion with each person separately.”

Whatever you do, make sure you have a win-win situation with your manager at the end of the discussion. You’re offering to become more valuable and a better worker for the investment of one book. Make sure your manager sees that. Use your sales skills to help your manager understand the WIIFM (What’s In It For Me), and you’ll know how to overcome objections and convince your managers to buy books.

Some books aren’t worth the paper they’re printed on. But some are invaluable. Determine which ones they are, and buy them.

In the last few weeks, several people have asked me how much rework is normal. Well, if you’re working in a test-driven development environment, you probably have very little rework. My estimates for the few real test-driven projects I’ve seen is that they spend about 10-15% of their time on rework (finding problems and fixing them after the technical staff thought they were done with the particular feature. (This percentage may be this high because the technical staff were learning how to work in an agile way.) They spend lots of time on iterating through the requirements with the customer, which I don’t count as rework.

But in the last few assessments I’ve done, and from other recent emails, my experience is that rework accounts for somewhere between 75% and 80% of a “normal” project’s time. That’s a huge drain from the project. The rework impedes forward progress. I know of these ways to reduce rework:

• See how little you can do, and deliver that much as quickly as possible. The technique I use most often is to break the pieces into groups of requirements/features and then perform iterations within whatever lifecycle the people are used to.
• Use peer reviews, walkthroughs, inspections, anything that forces more than one pair of eyes on the code.
• Pair the testers with developers, or somehow get the testers to test the developers’ code as soon as the product is built. Early feedback from testers can help developers prevent inserting more defects into the code.

All these techniques help developers focus on some small amount of work, and look for problems early in that work.

I wish I could say there was some reasonable amount of rework, but I don’t know how to define that number. Any rework is a problem that you could have caught before. The question you manage is: how much rework should you prevent, and how much rework (time wasted) is ok? (For research-y projects, the answer is lots of rework is ok. For get-the-product-out-the-door projects, any rework is not ok. ) You’re the only one who can answer that question for your project.