Managing Product Development

I use the CMM in my work. The CMM/CMMI is a wonderful collection of key process areas. Every product development environment can use many of the key process areas to improve their work. The keyword in that sentence is *many*, not all.

When companies aim for a particular level of the CMM/CMMI, they do themselves a disservice. By aiming for a level, they say that all the key process areas at one level are equally important. But what’s most important is not the level, but the mastery of the appropriate key process areas.

For example, a key process area in Level 3 is risk management. As you know, risk management is necessary for successful project management. In fact, I could argue that many organizations at Level 1 have mastered a form risk management, albeit in a people- and company-destructive way.

Here’s hypothetical example: A company with great project management processes including risk management whose project managers and technical staff are savvy enough to recognize that their lifecycle and practices need to change on each project. They have an incredible test group. They don’t perform formal QA, their requirements are bullets in email (a step up from napkins), they don’t track anything other than defects. They’re somewhere between level 2 and 3.

Here’s what matters: they work. Their projects work. They ship product on time. The customers, the compay, and the technical staff are happy. Their customers don’t find egregious defects. Their process works. They have mastered the few process areas they need now. As they grow, especially as they bring more people into product development, they will need to reconsider how they define and manage requirements, what they measure, and how the developers review their work. They will increase their mastery of the next process areas that matter.

When you plan and perform process improvement, especially if you don’t have a contractual need to show a certain level, work for mastery. Define which key process areas are strategically important to you *now*, and master those.

Levels are like grades - they show some part of what you know. But what’s most important is how you apply the knowledge behind those grades - the mastery.

I talked to a project manager recently who was so busy fussing with the schedule (WBS) that he didn’t have time to make decisions on the project. He was a project administrator, not a project manager.

If you’re working on a difficult and complex project, spend time on the schedule. You need to review the critical paths (through people and tasks), and look at who’s spending time where. You may even need to do this on a not-so-difficult or complex project. On the other hand, don’t spend all your time on the project schedule.

If you don’t have the time to review the project schedule *and* do all the project management work, hire a project administrator, someone whose job is to manage the schedule. That will free you up to do the project management, the more strategically important project work.

You can’t leave the project schedule alone to wither and die. And, you can’t spend all your time on the schedule with no time left for dealing with people, measuring what you need to measure, and making the inevitable tradeoff decisions.

When the schedule threatens to overwhelm you, obtain a project administrator.

Have one or two open reqs? Want to make the most of them? Follow these steps:

1. Define the job. Don’t create a laundry list of tools and technology. Create a set of requirements for the position:
   • Who will the person interact with, and how
   • What the person needs to know about the product domain
   • What kinds of non-technical skills the person needs
2. Review resumes looking for experience that is relevant to your job. Education is somewhat relevant, as is years of experience. However, if the education is more than 5 or 6 years old, the candidate’s most recent experience is even more relevant.
3. Ask great interview questions.
   • Ask behavior-description questions to hear the person’s story
   • Create and use auditions to see a person at work
4. Don’t forget to check references

There’s more to hiring than this quick list, but start here and you won’t be disappointed.

How much time should your project spend on development vs. time on quality?

I’ve received a bunch of email over the past year asking me how much time a project should allocate to development and how much to quality. To me, that’s a funny question, because I think of quality as integrated with development.

So, let’s reframe the question: “How much time should we spend on making sure our development works during development and at the end of development?” I can answer that question better.

Software projects spend anywhere from 10% to 80% of their time on testing activities. Since that’s such a wide range, I wrote a paper about the ratio of developers to testers.

Cem Kaner disagrees with my paper, and published something different at PNSQC 2001. I can’t seem to find the paper anywhere on line.

Kathy Iberle attempts to describe the dynamics, see and click on the ratio article in whatever form you like.

Here’s what I think: If you’re not spending at least 20% of the project’s activities on preventing, detecting, and fixing problems, you’re not spending enough time on quality, no matter what your market says. Now, there are several ways to do that:

If you’re like me, you work with people all over the world, never mind all over the country. I generally ask, “When is a good time to call?” before I call someone. However, some people don’t remember to ask. Or, they may remember to ask, but then forget to think about the time when they pick up the phone.

This morning, I was abruptly awoken when someone called me at 5am local time. It was 8am their time.

They were right to call. We could not have handled the problem over email. However, they still had to wait until my brain caught up with my voice. Thank goodness we don’t have video phones.

The phone has substantive bandwidth to discuss complex problems. So use it. Just remember to ask what time is good to call

Many companies have automated spam filters. This is a Good Thing. However, they look for certain words that have been co-opted by the pornography industry, such as Xtreme Programming (XP) and a cum laude notation on a degree.

It’s not a bad thing to look for spam and remove it. It is a bad thing to avoid references to extreme programming — we can learn a lot by adapting, if not adopting XP practices. And, it’s stupid to avoid potential hires who have managed to keep their GPA high.

Maybe it’s time to let the knowledge workers remove their own spam. Just a thought.