Managing For Results

by Johanna Rothman. This article was originally publised in Software DevelopmentMagazine, June 2002.

If you're getting stuck counting cars in the parking lot or fetching meals to fuel your team's overtime marathons, dump the dinners and trade in the clock for more accurate means of measuring productivity.

By Johanna Rothman

How do you find out who's working hard in your organization? Do you count cars in the parking lot, or note whose light is on or whose coat is still on the coat rack?

Ted, a veteran victim of this type of management, once complained to me, “My boss wants to know when we start and when we leave. So, we start at 8:30 on the dot, and we're gone by 5:30. If he'd cut us some slack, we'd work when we needed to, but he's treating us as if we can't be trusted to know when to come to work and when to leave.” If you see yourself in this picture, toss the clock and start thinking quality, not quantity: There are better ways to evaluate your staff's efficiency.

When you measure office time as a surrogate for productivity, your staff will spend plenty of time at work—but may not accomplish anything productive. Measuring office time implies that work success is dependent on duration, rather than value. If you're like most managers, you don't really want to snoop and spy: You just want to know if the work is being done, being done well, and being done on time.

Choosing Priorities

First, choose your priorities, based on the results you want to achieve. If you have forgiving customers or you're working on a demo that doesn't require a completed product, time is of the essence, and you need to focus on the schedule. If you're working on more than just a demo, however, you'll want to measure how much work is complete and how good the work is: the schedule progress in terms of the completed product, defect counts and fault feedback ratio.

Let's assume you're near the project's end, and making the deadline is your top priority. You've had a few missteps along the way, but the testers are testing and the developers are fixing the defects. The code has a few too many problems, but you're sure your developers can fix them in time—you think.

Cheryl, one of my colleagues, was in a similar bind, with her entire small company working on a single release. Deep in system test, they were about a month behind their original schedule. They'd already slipped the schedule once, and management didn't want to slip again. The project team had many defects to fix and verify, and a couple of small features to complete. Because Cheryl was the project manager, her senior manager asked that she bring dinner every night for the employees, so they would work harder and longer. Cheryl was not happy with her new culinary role:

“Organizing dinner for 60 people every night stinks. A wedding would have been easier, because you're organizing only one event. The dinners did work for about a week, but then people started coming in later in the morning and leaving right after dinner every night. I suggested that we stop having dinners at work and just send people home to relax and sleep, so they would be rested and fresh for the next day. Senior management thought that having more people at work meant we did more work. I certainly didn't think so, and I don't think we made that much progress after the first couple of weeks—in fact, it took longer because we were all so tired. I know I was tired from having to do my project management job and organize those dinners.”

Cheryl's management thought that keeping employees at work longer would help them work faster. However, people can't think any faster than their capability—especially when they're tired.

Cheryl's staff understood that they needed more away-from-work time, even though they were under pressure to finish the project. They needed time to decompress and let their subconscious minds take over some of the thinking. After a month, Cheryl dumped the dinners and started working smarter.

Cracking the Time Crunch

First, Cheryl talked to her team, explaining that they were in a time crunch and asking them to concentrate on this project. She said, “I want everyone to focus on this project, and this project alone. Here's our deadline, and I'd like us to do everything in our power to meet it. You don't have to work on anything other than this project. If someone asks you for something else, come to me, and I'll deal with it.”

Cheryl also wanted to make sure people were spending time effectively. She asked the developers to have all of their bug fixes peer-reviewed. Cheryl didn't specify how; her goal was only to have another pair of eyes on each fix.

Cheryl and her project assistant updated the schedule daily as the team completed their tasks. However, she realized that the large number of defects still present would make it difficult to predict the project's end date. She decided to measure how many fixes could be made and how many were problematic.

Tricky Fixes

Cheryl measured the average times to fix defects of high, medium and low severity, and started to measure the fault feedback ratio (FFR), the ratio of bad fixes to good fixes. (A bad fix either introduces a new defect or doesn't completely fix the original one.) The higher the number, the more employees are spinning their wheels, trying to repair something that just won't stay fixed. The longer employees work and the less sleep they get, the higher the FFR, because they're too tired to identify and fix the real problems. For commercial products, I'm concerned when I see a FFR higher than 20 percent, because that creates undue pressure on the rest of the project team to find and fix the defects. For mission-critical or safety products, an FFR of even 5 percent may be barely acceptable.

The FFR isn't linear with time, so a 10 percent FFR doesn't mean that you spend 10 percent of your time fixing fixes. However, the FFR does tell you if you're making progress.

Cheryl found that by instituting peer reviews for fixes, keeping people focused on just one project and tracking the FFR, the project team was able to meet their last deadline. She also had other options: choosing to incorporate usage-based testing to verify that the most frequently used part of the product worked; using exploratory testing to look for probable faulty product areas. In this case, the team used the FFR as a feedback mechanism. When it was too high, the team realized they needed to slow down and look at what they were doing.

Once her project team started getting enough sleep and reviewing each other's work, Cheryl's project began making dramatic progress. Her team kept the FFR under 10 percent, and because extraneous duties had been distributed elsewhere, they were able to use the entire workday to focus on the project. Some team members still worked an extra hour or two daily, but most went home to recuperate after an eight-hour workday. The project team was able to complete their work on time and release a satisfactory product.

Quality, Not Quantity

At an earlier phase in the project, you'll want to take different actions. Certainly, tell the project team that the schedule is important, and decide if they can afford the time to work on other tasks. Your staff must understand this project's priority compared to other work that needs to be done.

Look at your project and choose what to measure, so you can measure something other than office time. Assuming you want to know if your project progress is more than an illusion, here are some suggestions.

After you've assessed the schedule, ask people to define inch-pebbles for themselves. Inch-pebbles, or miniature milestones, are one-to-two day tasks. Don't track everyone's inch-pebbles in the project schedule (if you do, the schedule quickly becomes unwieldy), but ask your staff to use these tasks to gauge their progress. If, early in the project, people are having trouble meeting their small estimates, you know your project is in trouble. You can re-estimate the whole project, cut the number of features, or add more people to do more of the requested project work.

Then, identify any changing requirements, because unless you're using agile project management techniques, frequent requirements changes prevent “full steam ahead” progress. Focus on helping the stakeholders agree on the requirements before you start asking employees to work hard. Sometimes, revisiting and rewriting requirements can instill the necessary confidence that you're addressing the right problem.

Balancing Change and Stability

Maybe the requirements are relatively static, but the design is in flux because the project team can't decide what to do. One organization tried to solve the problem of competing designs by letting everyone implement his or her own design for each feature. The result? A disaster: The final product has six ways to open and save data files, and at least two ways to do everything else. The organization had trouble meeting the original project deadlines, and now, several releases later, they're still paying the price for not deciding on one design. It's difficult to make progress on a project when the team is working in different directions.

If your requirements are relatively clear and you agree on designs, make sure you have a way to assess and manage the project risks. Do you have a risk list, and do you manage those risks? Or do you let risk fall on your team's shoulders? Choose a place for people to send you their risks, so they can focus on their work. It's your job to manage the risks—and make sure you do so.

Examine how you talk about the project. Do you say things like as “my” project instead of “our” project? If you're the only project owner, your staff will never be committed; their work will be just a job. Make the project “our” project.

Then, look at how well the project team collaborates. Do people work together or alone? People isolate themselves to protect themselves from something painful or annoying, such as miscommunications, nebulous project roles and responsibilities, poor commitment management, interpersonal problems, overweening egos, and unclear vision and scope, as well as many other causes. As a manager, you can help uncover the problem and fix it.

Defining Success

Sometimes we don't clearly identify and communicate the objectives that are most important to us. As a manager, you must ensure that the project team knows what success means for the project, especially if releasing the product quickly is a component of this success. If you don't tell your team that you want the project completed by a certain date, they have no way to plan for a deadline. If you're currently measuring office time because you want to get a project done quickly, explain your need for speed to your staff instead, and tell them what you're willing to trade off to meet the schedule.

You can say something like this: “We won't reach these goals if any of us are working at less than peak effectiveness. Do you have ways of knowing when your effectiveness is slipping? [Try priming the pump by suggesting tools such as the FFR.] If you can tell me what to look for, I'll be able to notice and let up on the pressure. And here's what you can notice about me, so you can tell me when I'm slipping.”

Measure for Measure

Remember that your staff's effort is focused on that which is measured—and office time is a dysfunctional measurement, concentrating on quantity, not quality. When employees are evaluated based on a single aspect of their work, they'll find ways to optimize that measurement that don't necessarily contribute to the desired outcome.

In Ted's case, team members became clock-watchers, and their resentment prevented them from doing good work. A year after Ted's supervisor started watching the clock, 75 percent of Ted's colleagues had left for other jobs.

In Cheryl's case, people stayed for the dinners, but started coming in later and leaving right after dinner, not actually doing more work.

When you measure and reward office time, you'll get only office time, with no guarantee of a finished product. Change your focus and share the wealth: Instead of snooping at the sundial, distribute your project's ownership and help your team create a picture of the project—and its goal, the evolving product. By redirecting focus from the clock to the product, you'll know if employees are committed to your project and are working hard to finish it—not just doing time.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.