Managing Product Development

I’m developing a syllabus at the graduate level to teach high tech (if that matters) project management to people without a lot of PM experience. I’m supposed to teach MS Project as the tool project managers schedule the work.

I’ve been rejecting the idea that a scheduling tool can teach a new PM how to schedule. Normally, when I teach PM, I use yellow stickies and explain how to block out a schedule top-down or bottom-up. Inevitably, someone thinks from the inside out, and that person explains inside-out scheduling — all using stickies.

Stickies are great for scheduling because you can stand back and look at the picture of the project. Do you have enough in parallel? Is there too much in parallel? How long is the longest serial chain? Is there a way to make that shorter? What happens under these circumstances? I find that teaching scheduling using stickies is a way to help people understand how to create useful WBS (Work Breakdown Structures).

If I don’t teach a scheduling tool, am I cheating the students? To be honest, I prefer a different tool to MS Project (Fast Track Scheduler) when scheduling smaller projects. However, I know MS has improved Project since the last time I used it, so I’m open to suggestion. My goal is to teach people how to look at a schedule to see if it has a prayer of working, and then to see where the schedule is risky. It’s difficult to teach that with a tool, because you can only see one screen’s worth of schedule. With my technique, you get a wall-full of schedule.

If you were a new project manager, what would you like to learn? Please comment…

Tweet This Post 

Laurent’s post, The team building lunch prompted a bunch of (hopefully now organized) thoughts about the role of food in high tech projects.

One of the things I notice when I perform assessments is whether there is some sort of cafeteria or other food-eating place. Projects that have a physical place large enough for a project team (or two or three) to eat lunch together have multiple opportunities for learning and problem-solving.

• We know that defects cluster within modules. I also believe that defects cluster across a project. If the interfaces aren’t well-defined, and if the lifecycle or practices don’t help people determine how to resolve the interface issues, more defects arise at the (logical) interface. Informal conversations over lunch help people detect those problems and fix them.
• Testers can talk to developers, writers can talk to developers and testers, support staff can talk to everyone. Even though many people recognize that the org chart isn’t supposed to prevent them from talking to one another, sometimes it does. Or the geographical separation of people (on different floors, in different areas) prevents them from easily speaking with each other. Lunch (temporarily) removes the separation, whether by organization or geography.
• Discussion over lunch can become an informal peer review, not necessarily just by the other people in a single product area. When I was a tester at Symbolics, I regularly ate lunch with the developers. I learned about the product internals, and asked lots of questions, especially when I didn’t understand the design or the progress the developers claimed they’d made.
• As a project or program manager, I used lunch as a technique to hear the project status in a different way. People will discuss what they’re having trouble with over lunch, or if they’ve succeeded at solving a particularly thorny problem.

Now, when I work with a project team where the testers don’t know a lot about the product, I usually suggest the testers and developers have lunch together. Or, when I teach workshops or consult with an organization, I eat lunch with the people I’m working with.

I don’t know of a good substitution for a lunch place, where people can sit and eat and discuss their work informally. (The little kitchen areas many companies have are good for brief informal conversations, but there’s no place to sit.) The quality of the conversation over lunch tends to be richer, especially when people take a full hour for lunch. The introverts finally have their chance to talk (one of Laurent’s points). If you’re a manager and you think you can’t afford the space for lunch, think again. Lunch is free peer consulting across the organization and offers the possibility for technical problem-solving at its finest.

Tweet This Post 

Rick commented on my last post that some engineers think that status checking slows them down. Mark said that engineers push back on demos and pointless measurements and then said in another comment, “progress metrics can always be free.” Here’s how and what I look for, to determine status.

If I’m managing a traditionally-planned project, I have weekly status meetings with everyone on the project. (For large projects, each project lead has these meetings and I meet with the leads individually.) I ask people to explain the status of their work and what they’ll do next week, and how they’ll track status. I request that people think of their tasks as to-do lists with inch-pebble level work. I won’t put their inch-pebbles into the project schedule; that’s just too complex and I’m not about to track each person’s work. I ask people to monitor when they are stuck and to tell me if they need help in some way. Asking for help is fine. Floundering is not. I request that people peer review each other’s work product (unless we have more formal reviews in practice), so that they get peer feedback about the quality of their work. If someone’s working on a big work product, I ask them to consider what they want to show me: interim designs with chicken scratches, performance measurements of algorithms, number of scripts they threw away, something that shows me progress. Since the engineers determine their tasks, deliverables, and when they need help, I don’t usually come across as micromanaging them. I hear them describe their work products, when they’ve had problems or needed help, and I have a fairly good handle on the project state.

Every so often, I run across an engineer who thinks his work requires privacy to complete. When that happens, I explain that I don’t know how to manage the project adequately with his need for privacy, and what is he willing to show me or give me so I can see his progress. That doesn’t always work, so I ask him when his deliverables will be complete. If he gives me a date of more than two weeks, I explain that’s too long. In many projects, we can afford for one person to be off by two weeks, but I’ve never worked on a project where any one person could slip a deliverable by more than two weeks without affecting the entire project. I’m willing to give the engineer the benefit of the doubt, if he can come up with deliverables that are fewer than two weeks in duration, and maybe I can wait to see the status at the end of those two weeks. If an engineer can successfully deliver work every two weeks, I’m still nervous, but I can manage my nervousness. Once an engineer misses a deadline, we negotiate a different way to track tasks and status. So far, this has worked well. I’ve run into people who hated this, but we figured out a way to deal with my need for information. (I meet with the engineer whenever the engineer wants it, as long as it’s sometime within the normal work day.)

On traditionally planned projects, I send out an email every week explaining the state of the project. Project team meetings are optional. Problem-solving meetings for the project are not optional. (They are two different meetings.) I keep people focused on the end goal and aware of interim milestones.

On agile projects, status is much more obvious to everyone on the project. Since there’s a standup meeting every day, everyone explains what they’ve completed, obstacles they’ve run into, and what they’re going to do. Since I still have to prepare a report to management on project state, I send that by email to the project team also.

When I look for tangible work products, I look for: checkins, designs, how many designs were rejected and why, data about performance or reliability (depending on the product), algorithm development and debugging, people working together on pieces of the product, people working alone, how many people are actually working on this project, number of pizza cartons or other food containers, how long people seem to be at work. If I think there’s too much overtime, I ask people what’s happening and what we should do about it. I really want to prevent people from making stupid mistakes.

When I explain why I need information and the level at which I need the information, most engineers are willing to work with me and I obtain visible progress about the project state.

Tweet This Post 

At Boston SPIN last night, Tim Lister of “Waltzing with Bears” fame gave a talk about recognizing and managing risk. It was great. If you ever have a chance to see Tim speak in person, do so (Yes, Tom DeMarco is also an excellent speaker, but he wasn’t there last night .

When I manage risk in a project, I ask myself “What’s the worst thing that could happen?” For the schedule, it’s the choice of lifecycle and practices that could help or hurt the schedule. For the planning it’s not knowing enough and building a bad plan. For the people, it’s hiring or assigning people who can’t start on time, or don’t know how to work on the product.

What I see most often when I perform assessments is that the people don’t know how to develop or test the product. There is so much learning the project staff requires that the time estimate is off — sometimes by orders of magnitude. So when I manage a project, I think about all the other risks, but the one that usually hits the top of my list is: “How can I manage the risk that the project staff will be unable to develop the product?”

Here are some ways I’ve managed that risk in the past:

• Ask the project staff what they can show the entire project team early: designs, models, simulations, early runs of just the algorithms, early plans, etc. Once they show something at one stage, I ask the question about the next stage. (First I might see a high level design. Then I could see an algorithm. Then a prototype of just the algorithm. That’s what I mean about the stages.)
• Ask people to show me visible progress. Telling me they’ve completed something is not the same as showing me output or someone else’s review of a work product or performance measurements. Visible progress is necessary.
• Ask the project team to view the work as a problem solving exercise. What three alternatives (minimum) have they considered? What three things can go wrong with each alternative? If they can accomplish the design, is there some other problem I don’t know about — so we can go about solving those problems?

If you’re working on a risky project — probably the only projects worth doing — then a huge risk is not knowing whether you can accomplish the work. Apply the ideas of small deliverables, visible progress, and problem-solving, and you’ll manage the risk. You may not eliminate the risk, but you’ll manage it. As Tim said last night, “Bad things might still happen. But disasters won’t happen.”

Tweet This Post 

In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s no such thing as a requirement”, says “A misfit occurs when some aspect of the form clashes with some aspect of the context.”

I like the idea that the form of what we’re trying to design and the context, how we’ll use the design, are in tension. Good design involves describing the tradeoffs and how those tradeoffs affect each other. This is why the agile techniques, where the index cards carrying the stories are more of a promise to discuss the requirements and the tradeoffs are so successful.

I get frustrated when I’m brought in to “save” a project, and I see reams of paper describing the requirements. Too often, the functional requirements (the description of what the system will do) are described in mind-numbing detail, with no attention paid to the non-functional requirements (system attributes, possibly Alexander’s notion of context). I can be sure when I see huge requirements docs that the project team thinks they’ve completed the requirements, but they haven’t had enough of the conversations to finish describing the requirements.

There are people who have successfully used huge requirements docs to make their project successful. In the cases I know of, they have used some sort of fit criteria (a la Robertson) and/or use cases in addition to the big functional requirements document. But if they don’t have some sort of context, or fit criteria, or use cases, I haven’t seen big requirements documents succeed.

I don’t really care how a project team describes the requirements, as long as the team thinks about more than just functional requirements. With requirements, it’s the thinking and discussing tradeoffs that is so important. With informed discussions, the requirements documentation is easy. As always, more to think about…

Tweet This Post 

I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation.

IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months) it might even be possible to fully know and define the requirements at the beginning of the project. But I contend it’s not possible for users to fully know their requirements early for any substantive effort.

The nature of software — ephemeral and malleable and not well understood by users until the users see the artifacts — guarantees that as soon as a user sees the system, the user will see the next step in the evolution of the requirements. (If any of you want to help me rewrite that sentence, please do.)

Here’s an example. Fifteen years ago, I bought a light timer for the lights outside the front door. We want the lights to come on when the sun goes down and go off when we’re all in for the evening. It was an electro-mechanical clock timer switch and worked for about ten years. About five years ago it started losing time and the ring around the outside was harder and harder to use, to set the time properly. Finally, I took Mark to Home Depot a couple of weekends ago and said, “Honey, it’s time for a new switch.” I used the don’t-argue-with-the-wife voice, and Mark decided to give in. He picked up a timer with an LCD display and put it in the cart. I picked it up and said, “Oh, no, this has software in it. We don’t need something this complicated.” We discussed it, and he used the don’t-argue-with-the-husband-who’s-going-to-install-it-for-you voice, and I acceded. Well, when he’s right, he’s right. I love the timer. It knows when sunset is, so the lights always come on at sunset. We don’t have to reprogram it every week, or risk the kids coming home to a dark entryway.

I didn’t think I needed the extra features. In fact I was sure I didn’t need them. It wasn’t until I saw how well the timer worked that I realized the extra features were exactly what I wanted. I don’t want to have to reprogram the timer every week during the winter. I don’t want to mess with it at all. But I was sure no product could do what this timer did. But the “extra” features are now part of what I require in a light timer.

I could have taken my own advice about requirements, and asked myself “What attributes of the timer are important to me, as a user?” I would have answered: ease of programming, fewer times of programming, programming override for those gray days. The first two in my list are system attributes, not functionality. Users are notoriously ambiguous about system attributes — not because they want to be, but because they literally don’t know how they want the system to work. The override is partly functionality, and partly an attribute of the system.

System attributes are the most important part of the requirements (some people call these non-functional requirements), and they are the hardest to determine in advance. One of the reasons agile methods work so well is that the user/customer sits with the team and discusses the system attributes constantly. If you’re not using agile methods, plan on iterating on requirements anyway. Especially plan on iterating through the system attributes, and the product cost for those attributes. You won’t know your requirements early, but you’ll learn them as you develop the system. And you’ll develop a product people want to buy.

Tweet This Post 

In this issue of Better Software, I have the featured article, No More Second Class Testers! and Frank Patrick has a great article, “Promises and Prescriptions, How the Theory of Constraints can help cure common project ailments.” I can’t give you a URL to Frank’s article, but maybe in a month or so he’ll post the article on his web site, and you can see it then. Here are some gems (all quoted from the article):

• “Get rid of task due dates. The only dates that count are those promised outside the project.”
• “At the project task level, don’t allow yourself to be bullied into multi-tasking behaviors.”
• “Plan for the need to plan along the way.”

It’s a great article. I hope you read it.

Tweet This Post 

I’ve been thinking a lot about the comments people made on the Best Practices… post. (Thank you for your comments.) Here’s my experience.

Great people, people with sufficient functional skills and domain expertise can trump process, good or bad. Good process, process appropriate for the context, will help those people. But great people can overcome bad process to deliver a good product.

Bad management, management incapable of understanding how to remove obstacles or how to see the project state, can trump good people and good process. Management that doesn’t help is better than management that actually hurts a project. (I once worked for a manager who insisted on calling my customer. Every time he did, he created a crisis I had to resolve. I ended up spending about 50% of my time managing my manager, with the rest left over for the customer and the project. Luckily, the project staff were great, so I didn’t have to pay too much attention to them. That manager’s actions cost us months in extra project time. But we finally delivered — less than we could have and much longer than it should have taken.)

Good process helps even out the differences in capability among developers. In “Peopleware,” DeMarco and Lister show that in their Coding War Games, there was a a huge range in capability. Quoting from page 46, “The best performance was 2.1 times better than the average. The half about the median outperformed the half below the median by 1.9 to 1.” When you define and use a good process (reasonable lifecycle and practice for your particular project and context), you can reduce the variation in developer capability, bringing the people originally below the median up closer to the performance of those above the median. But if people don’t have the functional skills and domain expertise, they can’t use the process the perform well. And, bad management can trump a reasonable process anytime.

So when I predict project success, I don’t assume people, process, or management is the one key to success. I look to make sure the project hasn’t already shot itself with inadequately-trained people, bad management, or bad process. Then I look for an adaptable project. Here are some things I look for:

• Before the project, does the project manager have the ability to select the people for the project with appropriate functional skills and domain expertise? If the project manager doesn’t know enough to select the people, does someone? Are people available when they are needed?
• Once the project starts, are people added to the project as needed? Delays in adding people delay the project.
• Is the planning iterative? Any project worth doing has risk associated with it. Planning the entire project in detail is a waste of time and does the project a disservice. Preplanning in detail (especially with an electronic tool) suggests to management that the project will unfold in the planned way. Nope. The schedule is the one way the project will not occur. I look for plans to replan, to take advantage of project advances and to deal with project delays.
• Is everyone watching for defects? Are people cleaning up as they go? This can be refactoring designs or code, or as simple as cleaning up the lab or other common work area. The messier the environment is, the more likely the work product is to be messy. If everyone isn’t watching for defects, it’s harder to clean up the work products later. (Yes, for me, these are interrelated.)

These aren’t the quantitative measurements I use as a project manager to know when the project will finish or how much rework we’ll need; these are the qualitative measurements I use to see if there’s any chance the project will succeed. I use the quantitative measurements to help the project stay on track or get back on track. I look for this evidence of adapatability and flexibility when trying to predict project success.

Tweet This Post