Sunday, May 23, 2010

Stop That Mole Now

�2010 Steven M. Smith

Do you have a mole undermining the work of your team? Someone who constantly complains privately to any teammate who will listen but refuses to bring that same complaint publicly to the team? Someone whose actions are destroying teamwork?

A mole erodes productivity. Stop that mole now.

A team is like a garden. A good gardener manages pests –

Bambi, a deer, can kill a portion of your garden by eating your produce’s leaves. His attacks can be seen so they can be managed by the non-specialist, by using such means as scaring him; erecting a fence; planting produce that he doesn’t like; and using chemicals that make your plants smell or taste yucky.

Buck, a mole, undermines the roots of your garden killing your produce. But unlike Bambi, you can’t see Buck in action so his attacks are almost impossible to mange by the non-specialist. For instance, scaring him won’t work because you can’t see him; erecting a fence won’t stop him because he does his work under the surface; planting different produce won’t stop him because his food source is the worms, insects and grubs beneath your garden; and using chemicals to kill the insects and grubs won’t stop him because his primary food source is the worms.

Bambi’s behavior can be managed so that it is an annoyance. Buck’s behavior is much different — it’s destructive.

Real moles aren’t malicious. Their intention is to eat rather than destroy the garden. I admire them for their single mindedness and work ethic. I, however, disdain a mole on my team.

I believe the Bucks of the world think their actions are helpful. But unlike my ability to manage the Bambis, I don’t have the special skills necessary to consistently manage or turnaround the Bucks. And in my experience, I estimate that there are only 0.1% of all managers who have that special management (therapy) skill.

What’s to be done? Confirm you are dealing with a sibling of Buck’s by — bringing the tunneling behavior to the person’s attention, telling them it’s unacceptable, and determining whether the tunneling continues. If it does, work with HR to immediately rid yourself of them.

Once they’re gone, the team will feel like the weight of the world was lifted from their shoulders. Productivity will skyrocket. Stop that mole. Now.

convert this post to pdf.

Friday, May 29, 2009

Drawing Out the Facts: The Art of the Discovery Interview

“What?” raced through Janet’s head as she read the email. “Now that’s a surprise.”

The message was from Jack Johnson, vice president of development. It said she would receive a meeting request from Rajan Alak, an outside consultant, to interview her about the problems with the new system. The message went on to say the company had made a significant capital investment in the development of Synergy and problems with the system were preventing the company from enjoying the expected ROI. Jack asked Janet to give Rajan her full cooperation.

“He wants me to give an outside consultant–a total stranger–my full cooperation?”

The problems with Synergy didn’t surprise Janet. She had invested almost all of her time during the past year in developing the system. She believed the business planners had been too aggressive with the system integration plans. She thought the company’s chance of achieving the projected ROI was zero. Her suspicion was that the projection was based on politics rather than reality.

A portion of Jack’s message was a surprise: In addition to fixing the problem with Synergy, he wanted to fix problems in the development process that had caused the issues with the system. Solving problems with the development process was an initiative Janet had wanted to see since she started her job seven years ago.

She waited to exhale and asked herself, “How much should I tell this outside consultant? Will my statements be used against me? Or my manager?” And as she exhaled, no answers came.

The next morning Janet received the meeting request from Rajan to interview her the following Wednesday. The request included a copy of Jack’s message and told her she would receive more information about the interview in a forthcoming email.

A part of her kept wondering, “How much can I say?”

Rajan’s email titled “The Interview Process” arrived two days later. Janet read the message carefully. It said she had complete control over the information she shared. She could choose to have information marked as originating from her, originating from an anonymous source, or recorded as off the record. Rajan said that after the interview she would receive a transcript of the “on the record” parts of the interview for her review and approval. Rajan emphasized he would not share any of her comments with anyone else until she approved them.

“Hmm . . . ” she thought. “Maybe it’s OK to share what I know.”

Fundamentals

The quality of an interview depends on how safe the interviewee feels. People guard their knowledge when their answers may endanger themselves or a valued colleague. The safer the interviewee feels about answering questions, the higher the quality of information available to the interviewer.

Creating a safe environment is only the start. In addition to safety, the quality of a set of interviews–whose purpose is to discover problems and solutions–depends on managing the sponsor, interviewing the right people, and interacting skillfully with the interviewees.

Let’s explore effective actions available to the interviewer before, during, and after the face-to-face interview.

Before the Interview

Sponsor Agreement

Gaining clarity about the objectives of the sponsor saves everyone time. Help your sponsor write down what is important to him and, just as importantly, what will gain the cooperation of the interviewees. Have the sponsor sign off on a written set of discovery objectives and a list of people to be interviewed.

For instance, if a vice president says her objective is to fix the problems with a system, her message will be compelling to some of her people. Adding that she also desires to solve the development problems that caused the system’s problems may energize additional people.

Rarely does anyone create objectives that are compelling to everyone. Objectives that are compelling to some people may de-energize others. So, focus on creating compelling objectives for the people whose opinions matter most to your sponsor.

Overcome Restrictions

You will want to talk to the organization’s customers. Some organizations carefully restrict who communicates with their customers. Despite these barriers, assume management wants you to speak with them. Work with your sponsor to identify which customers you will interview. If your sponsor objects to your talking directly to the customer, negotiate. Explain that without customer feedback, the most that can be discovered is less than half the available information.

I prefer to interview the customers first. I want to hear their unfiltered perspectives about outcomes that were expected but never satisfied. Next, I like to interview key middle managers to gain additional perspective. The customer and middle management interviews reveal a panorama of the most visible problems and provide an opportunity to find out more about whose opinion is the most influential.

Sponsor Communication

Regardless of whether you are an inside or outside interviewer, the person you are interviewing needs to hear from his management why he is being interviewed, who will perform the interview, and what actions management expects from him. In the introductory story, a vice president, Jack Johnson, provided that information to Janet.

Prepare an email for the sponsor to send to all the people being interviewed. Take control; if the context isn’t set properly, it will be a barrier to your success. If the sponsor is uncomfortable with your message, ask him to discuss it with you and work with him to revise it so it works for the sponsor and you.

Ask the sponsor to send the message to each interviewee individually. My experience is that messages addressed to a single recipient gain more attention than messages addressed to a group.

Also ask the sponsor to mention the interviews in staff meetings and to emphasize the importance to the interviewees. Scheduling interviews is difficult in busy organizations. When upper management deems the interviews to be of high priority, middle management will more readily support the scheduling of its people’s time. Otherwise, the interviews will be a low-priority event that may never happen.

Interviewer Communication

After the message is sent from the sponsor, it’s up to you to schedule the interview. I suggest you attach the sponsor’s original message to your scheduling request so recipients can review it. The inclusion of the original message prevents confusion by people who may not have read the message from their management.

Follow the meeting request with an email from you to each interviewee explaining how the process will work. This message lets the interviewee know he controls the use of the information he shares. This email will surprise the recipient. People in large organizations frequently receive messages about protecting the company’s rights but rarely receive messages giving them rights.

My preference for the first interview requires no preparation by the interviewee. If you are interviewing the right people, they already know everything they need to know. Inform the interviewee that he doesn’t need to do anything prior to the interview.

I strongly suggest you telephone the interviewee the day before the interview to confirm the time and location. Priorities change regularly in organizations and the interviewee may need to cancel the interview. Knowing about cancellations early will enable you to reschedule your day. If your call is transferred to voice mail, let the interviewee know the time and location of the interview, leave your cell phone number, and let him know that you’ll assume everything is as scheduled, unless you hear from him.

Question Sequencing

The sequence of your questions contributes significantly to a successful interview. A key aspect of most interviews is gathering information about problems. I like to look at questions as either branches or stems. Branch questions move to a new subject area. Stem questions (indented below) gather more detail about a branch. Let’s look at a high-level plan for sequencing questions during a sixty-minute interview:

Q: Who is your customer?

Q: What problems did Synergy solve?

Q: What problems did Synergy create?

Q: What problems happened during development?

Q: What other questions should I be asking you?

Q: Do you have any questions for me?

Q: May I contact you if I have additional questions?

These questions can be asked to anyone in the organization. As you gain information from each interview, adapt your questions to fit the person you are interviewing.

Metaquestions

In addition to questions on the topic of interest, effective interviewers equip themselves with metaquestions to gather feedback about the interview process itself. Metaquestions are questions about questions. For instance, if you see a puzzled look on the interviewee’s face, you might respond, “I see a look on your face that suggests to me that you might be puzzled by my question.”

I find answers to metaquestions open new possibilities about what to do next. For instance, you may discover that the person you are interviewing has a different role than you thought and the role isn’t relevant to the discovery. Rather than continue the interview and waste his time and yours,you now have the option of ending the interview. The following is a list of metaquestions I have found valuable in any interview situation:

Don’t Worship the Plan

Plan the interview, but don’t worship your plan. Effective interviewers adapt to the desires of the interviewee. Don’t be the type of interviewer who never deviates from his list of questions. I have experienced that kind of interviewer, and I wondered if he even heard or cared about my responses.

If the interviewee makes it clear that he would enjoy answering more questions, you have connected. And connection is an objective of every interview.

During the Interview

Virginia Satir, a pioneering family therapist, created an interaction model that offers interviewers insight into how to conduct an interview. Satir insightfully broke down each interview interaction into a series of steps. She suggested that careful processing of each step offered new choices for strengthening the connection between the interviewer and the other person.

Satir’s interaction model can be summarized as follows: Perceive -> Interpret -> Evaluate -> Respond.

Let’s use the interaction model to examine a portion of the interview from the perspective of Rajan, the interviewer. For example, Rajan asks Janet, “What problems did Synergy solve?”

Perceive

The first step in the interaction model is to perceive the interviewee’s response. Rajan hears and sees Janet’s response. The words are a single component of Janet’s response; other components–such as tone, pace, breathing, and facial expression–are also part of her response.

For instance, before Janet uttered a single word in response to the question about the value of a solution, Rajan noticed her eyes narrow and her forehead crinkle. Rather than rush to interpret the words, the interaction model suggests there is an opportunity to gather more data before interpreting meaning.

Rajan has the opportunity to say something like this to Janet: “I noticed that your eyes narrowed and your forehead crinkled before you answered my question. I’m not sure how to interpret that reaction. What can you tell me about it?” Regardless of how Janet responds, Rajan has gained additional and perhaps more relevant data about Janet’s response.

Janet blinks, straightens herself, and answers, “It would mean a whole lot to the department. We could process work faster.” Let’s analyze this. Notice that Janet’s words are about the value of the solution to her department rather than to herself. Without further probing, valuable data could be missed.

An effective interviewer explores how something directly affects the interviewee. That’s the subject where the interviewee has total expertise. Rajan, an experienced interviewer, then asks Janet a clarifying question, “What would a highly effective solution to the problem do for you?” Rajan might ask several probing questions to gain more specific data about the value of the solution to Janet.

Interpret

The second step in the interaction model is to interpret the data. Rajan decodes Janet’s meaning from the data he gained through his senses. Successful completion of this step happens when the interviewee agrees that the interviewer’s interpretation is the same as his meaning.

Sometimes interpretation is simple. For instance, Rajan says, “Janet, I understand that solving the problem would save you four to six hours per week. Does that capture the value of the solution for you?” If Janet says yes, Rajan is done with that question. But watch for her wanting to say more. After a long pause from Rajan, she may say, “But the most important thing is that I then could rely on the accuracy of the results.” Now Janet has revealed the real value to her.

Sometimes interpretation is difficult. Transmission errors are normal. Your perception might be wrong. The interviewee might have said something wrong and not realized it. That’s why it’s crucial to gain the interviewee’s agreement about this meaning. After you publish the findings and recommendations, the last thing you want to hear is an interviewee saying, “That’s not right,” “That’s not what I said,” or “That’s not what I meant.”

Let me suggest a method for confirming that you have captured an interviewee’s meaning correctly. Ask the interviewee a series of “Do you mean X? Do you mean Y? Do you mean Z?” questions until you hear three “Yes” answers. For instance, Janet may have provided Rajan with a lot of data about the value of the solution that doesn’t have a single simple interpretation. Rajan asks Janet:

A “Yes” answer confirms your interpretation. “No” answers provide opportunities for finding out what was meant.

Evaluate

The third step in the interaction model is to determine the significance of the meaning. Explore how the meaning connects to value for the interviewee, organization, and customers.

For instance, consider the response “X will save me four to six hours per week.” On the surface that sounds terrific. But how significant is that savings? During the interview with the head of engineering for an airplane manufacturer, I informed him that someone in his organization said that a new system would save each of his engineers four hours per week. He squinted his eyes and said, “So what? That doesn’t guarantee me increased productivity. They may take that time savings and stare at the holes in the ceiling tiles.”

In other words, without connecting the time savings to something else, a benefit that seems obvious at one level may not be obvious at all to a different level or perspective. Dig deeper. Ask follow-up questions such as, how would you use the time savings? Keep probing until you uncover a benefit that is meaningful to the interviewee and, if possible, to his management.

Respond

The final step in the interaction model is for the interviewer to choose the next question. You can choose to continue asking stem questions, ask the first question in a new question branch, ask the first question in an unplanned branch, or ask a metaquestion to help you decide what to do next.

If you are like me, you may have times when you aren’t sure what to ask next. I have found a comment and a metaquestion that has worked well. I tell the interviewee, “I’m not sure what question to ask you next,” and then ask the metaquestion, “What question should I be asking you?”

After the Interview

Observe And Transcribe

I suggest an interviewer use a pocket recorder so you can keep your eyes on the interviewee rather than looking at your notes. Be sure to ask for permission to make a recording, and if you don’t get it, don’t record. Throughout the interview, watch for signs that the interviewee is uncomfortable with the recording. Be willing to switch it off if it’s obstructing the interview process.

Write the transcript of the interview as soon as you can. The transcript only includes the material you may want to use in your discovery report. Share only what is relevant and needs to be confirmed by the interviewee.

I like to tell the interviewee that anything in the transcript is something that I might quote directly. I believe it’s extremely powerful to include in the discovery report quotes from people in the organization as well as customers. If the interviewee grants you permission to quote him, give him the credit for discovering a problem and how to fix it.

Don’t Share Until Approved

Don’t share information from the interview with anyone until the interviewee has given you permission. And let me be clear: I mean no one else. That includes the sponsor and your manager. You have made a commitment to the interviewee with the hope he would feel safe to share things with you. Don’t break your promise.

Adapt Your Plan

From each transcript, follow the suggestions about questions to ask other people. The interviewee gave you a person’s name because he thought that person knew something important or his thoughts had significant influence within the organization. Use this information.

Revise your question plan based on what you have learned during the interview.

Thank the Participants

Thank the participants at the end of the interview. Thank them when you send the transcript. Thank them when all the interviews are done. Thank them all in the preface to your report.

The more appreciation you show the participants, the more they will appreciate you.

Summary

Interviewing is an art. Learning how to do it effectively takes practice.

I’ve made many suggestions. If you can only do three of them, I recommend:

Building a foundation of safety so interviewees will tell you what they know.
Conducting face-to-face interviews so you hear and see what is being communicated.
Planning your questions and using metaquestions to adapt to the needs of the interviewee.

By executing a set of effective interviews, you will gain knowledge about the organization and its problems that no single person in the organization can offer you.

Remember to conduct yourself with integrity every step of the way. It’s fundamental for gaining the trust of people you are interviewing.

Steven M. Smith (www.stevenMsmith.com) is a management consultant who specializes in helping leaders of technical organizations delight customers, manage change, and strengthen teamwork. With more than three decades of experience as a thought leader in technical organizations, he shares his know-how through his writing, consulting, and leadership of experiential workshops. He is a founder and host of the annual Amplifying Your Effectiveness (AYE) Conference (www.ayeconference.com), at which he leads experiential workshops. You can contact Steven at steve@stevenMsmith.com.

convert this post to pdf.

Tuesday, March 31, 2009

The Technology of Cooperation

IT professionals must be good team players, but what does that mean?

For one thing, it means they must know how to come into a situation and quickly cooperate and gain cooperation, but cooperation takes many forms. It’s not sufficient to want to cooperate. You must also know how. This column is about the technology of cooperation.

People
Most people, when they think of cooperating, think of everybody doing the same thing?like all pulling on the same rope in a tug-of-war or rowing in the same Roman galley, perhaps chained to the oar. When you consider cooperating by sharing people’s direct labor, first try to categorize the situation into one of these two:

1. The job is well understood and easy to communicate to a newcomer.

2. The job is fuzzy, or not understood at all, or complicated.

In the first situation, as in a tug-of-war, it is relatively easy to move people about from one work group to another. The amount of productivity in this situation is roughly the sum of the individual productivities. Ten people can tug ten times as hard as one. Many managers think that adding IT professionals is just like adding bodies to a tug-of-war team.

But even a tug-of-war is not so simple, for those who are experts at it. Given roughly equal weights on both sides, the team that understands and uses technique will win every time – and can even overcome substantial weight deficits. Adding a new member to a skilled tug-of-war team will not add proportionately to their success. Indeed, unless the new member understands their technology and system of communication, the addition of another body is likely to reduce their total tugging effectiveness.

When the job is fuzzy, and ideas are needed more than simple tugging power, the addition of a new member can be helpful if the team is ready to accept new viewpoints imported by the new member. Experienced IT professionals, however, know how hard it can be to have their better ideas heard when they’ve just started a new assignment. It can be horribly difficult to integrate a new person. Time and “wasted” effort must be allowed for in such additions, especially as the job grows more complex.

Thus, if quick addition is needed, adding people willy-nilly is not the answer. This observation was the essence of Brooks’s Law – adding people late in a project makes the project take even longer. Adding them early, however, which allows time for this “wasted” effort of integrating the new people, can, in the end, make a project go faster.

Any IT professional who is thrown into a project late and expected to make things go faster needs to be aware of Brooks’s Law and needs to communicate to the management what kinds of delays are to be expected. Moreover, each of us IT professionals needs to master the arts of quickly learning what the job is about and how the existing team communicates.

Programs
When we import a program or a piece of hardware to a project, we import technology in a form that may seem more acceptable than a new team member might be. This is the dream of reusable software. But when the team members feel that their own technology is an extension of their own egos, programs may not be portable at all. Instead, they run into the “not-invented-here” brick wall.

Of course, even when a team is willing or even eager to import software or hardware, it may prove poorly designed for portability. In general, portability of complex technology doesn’t come by accident, but by design and by testing of the design. Even for well-designed technology, there is a break-in period which may or may not be shorter than the time taken to add a new member to a team. Of course, the payoff for an imported technology can be huge, but only if it’s adopted and used.

Some IT professionals come on the job with their own tools, not anticipating the amount of difficulty they will experience getting the existing team to adopt their “superior” tools. If you feel that your tools add to your value as a IT professional, you must master the art of introducing tools – especially to people who may be insulted by the very idea that you might know something better than what they already know.

Perceptions
Ideas or ways of thinking can be the most portable of all kinds of technology, as long as the ideas or perceptions are not labeled too clearly as “belonging” to someone. The rule here is perhaps the most important that a technically-oriented IT professional can learn:

There’s nothing you can’t accomplish if you aren’t concerned who gets the credit.
If a project is successful, there’s always enough credit to pass around.

Points or Perceptions
Much of what we do on a job is to win the approval of the management, or of the customer. We call this “scoring points.” Success on a job depends very much on the ability to score points, in whatever game management happens to be playing. If they are playing a good management game, then the more points you score, the better the job you must actually be doing.

But bad managers give points for the wrong things, and if you work under such a point system, you soon become a poor performer. In any case, though, in work as in life:

Points can never be passed directly from one person to another.
To pass points, you must pass people, programs, or perceptions.

In general, sharing perceptions may be the easiest way to cooperate. Moreover, if you don’t share perceptions, it may be almost impossible to cooperate. So, when you enter a new group and want to cooperate, it’s best to start by listening?and learning how other people perceive the world.

convert this post to pdf.

Wednesday, February 20, 2008

How Much Building Is Too Much?

During a recent in-house project management class, I suggested that the project teams move from weekly builds to nightly builds, preferably with an automated smoke test as a technique to increase the pace of the project. “We can’t do that,” one of the project managers said. “Our testers can’t keep up.” Why do your testers need to keep up? Nightly (or hourly) builds aren’t for the testers?though they can take advantage of newer builds?but for the developers.

Developers receive timely and frequent feedback

With staged integration?building weekly or less often?developers receive feedback about their work at least a week after they check it in (sometimes a month or more, in my experience). With nightly builds, developers receive feedback the next day on the previous day’s work, which is a hallmark of agile development.

With nightly builds, if a developer has a bad development day, that developer receives feedback the next day, wasting only one day’s worth of work. With less frequent builds, developers receive feedback days or sometimes weeks after they’ve finished their work. It’s too easy for developers to get stuck with incomplete or wrong thinking and not realize it until weeks have passed, making the project late and adding to the needed rework.

One of my clients can only build their system about once a month. They need a full week to resolve the compile circularities, and then another couple of weeks to find all the people who broke the build to fix their problems, resume or restart the compiles, and finally complete the build process. It’s possible for a developer there to have to change something checked in two or three months ago, because problems with that code didn’t appear until a build or two later when someone else checked in a complete piece of work.

Staged integration, in which developers wait until an entire piece is done to check in the whole darn thing, helps each developer complete a chunk of work, but slows the progress of a project. Here’s why: A developer starts developing in a private sandbox, and every day pulls down the latest changes from the mainline. The developer checks for differences and integrates any found into the code under development. With any luck, no other developer is working in the same area. But if there is someone else working in that area, the developer has a choice to make: does she take the updated code or continue to work in solitude until her piece is complete?

Many developers wait to integrate their code until it is structurally complete and cohesive. But the longer it takes for that developer to complete the code, the more the mainline is changing. And the longer the developer waits to integrate that piece of code with the mainline, the more work the developer has to complete for integration?and the longer the developer has to wait to receive feedback from the build process.

Contrast staged integration with continuous integration: where small pieces are integrated every day and the system is built every night. Every day the developer brings down the new changes into the private sandbox, makes changes to the code, saves the changes, and updates the mainline. Not only does the developer receive feedback on the code via the build process, but also other developers can see what’s changing in that area.If multiple developers are changing code in exactly the same area, they have to talk to each other to make sure they don’t step on each other’s code (a practice that helps any project). But chances are good that even if developers are working in the same set of files, they’re not working in precisely the same areas of the files. Most configuration management systems will automatically merge the changes without problems.

When developers integrate small pieces every day, they are less likely to propagate mistakes for weeks. Instead, because changes are available to everyone using the updated sources and builds, the developers receive feedback within a day. If something is wrong, they only have to look at yesterday’s changes, not a week’s or month’s worth of work.

Testers receive the option of which builds to take

While continuous integration (nightly builds at minimum), solves the problem of ensuring developers receive feedback about their changes, testers might feel left out in the cold. In fact, one tester told me, “I can’t take every night’s build?my regression tests alone take three days to run.”Testers have a choice. They don’t have to fully test every nightly build. Maybe they’ll use the weekly build on which to run regression tests. Maybe they’ll choose to do some exploratory testing on a nightly build in a particular area. Maybe they’ll verify fixes in a different area for a particular build. Testers are responsible for assessing the risky areas of the product and deciding how to test that area in the current build.

It’s not reasonable to expect testers to fully test every build every day. It is reasonable to discuss with testers what their testing strategy will be during the different times of development, so you know the testers are making progress and the developers can receive the testers’ invaluable feedback.

Nightly Builds Might Not Be for Everyone

I have yet to encounter a project where someone can’t use nightly builds, but, then again, I haven’t encountered all projects. It’s possible that your particular circumstance prevents the use of nightly builds. Certainly, if the testers are the only people on the project who use the build, nightly builds may be building too often. But increasing the frequency of your project’s builds is a quick step toward helping the developers see where they’re going, and that helps the project make forward progress.

convert this post to pdf.

Tuesday, May 15, 2007

Approaching a Conflict in Style

This column originally appeared on Stickyminds.com.

Conflict is inevitable at work. Sooner or later, you will disagree about what to test, when to test or how long to test software. How you.and the person you disagree with.approach the conflict affects both the outcome and how you feel about the exchange. Let’s listen in as Jim, a test manager, and Pam, a development manager work through one of those inevitable conflicts.

* * *

Jim, the test manager, started the coordination meeting with
Pam, the development manager, by stating that he needed her team to turn over
all the code on the first Monday in September. In a previous meeting, they’d
discussed having the code complete in October, but Jim’s statement sounded like
a demand to Pam rather than a starting point for discussion.

Pam asked Jim what was behind the change, and when he said
he wanted to begin testing early, Pam was thrilled.

“That’s great,” Pam said. “Early testing will really help
us. We won’t have all the code done until the October date we discussed
earlier, but we’ll have features ready to test starting in August. I can turn
over features every two weeks from August through September.”

“No, I need all the code for early testing the first week
in September,” Jim reiterated.

“Is the issue that you don’t have anyone to assign to
testing earlier?” Pam probed.

Jim shook his head. “No, we need the code all at once.”

Pam asked more questions to understand Jim’s concerns and
offered more options, but Jim stood firm.

Later, Pam mused to herself, “It’s almost as if he needs me to lose in order for him to win. I
offered everything I could think of so the situation would work for both of us.
Now we’ll have to hash this mess out with the VP. Why does Jim always have to
have his way?”

Meanwhile, Jim was thinking, “Why did Pam try to weasel out of this? If I agree to her options, she wins.”

Scenes similar to this one play out in business every day.
The people and the topic may be different, but the ways Pam and Jim are
approaching their differences represent common approaches to conflict:

Collaborative Problem
Solving–Pam is approaching her conflict with Jim by trying to find options
that will work for both of them. She’s looking for the interests behind Jim’s
position, sharing her interests, and looking for options that satisfy both
parties.
Competition–Jim, on the other hand, is approaching the conflict with one aim in mind: achieving his goal. He’s not willing to explore other options; he’s intent on pressing his preferred solution. If he get’s his way, Pam doesn’t get hers.

In addition to Pam’s Collaborative Problem Solving approach
and Jim’s Competition approach, there are three other common approaches to
conflict:

Yielding–In this style, one person yields, accommodating the other person�s wishes without pressing his or her own interests.
Avoidance–Sometimes people do
everything they can to avoid a conflict. They pretend the difference doesn’t
exist to avoid the unpleasantness of confrontation.
Compromise–In compromise, people try to meet halfway. Each gives up some of what he wants and achieves some of
what he wants. Compromise is common, though not always satisfying since no one
is completely happy with the solution.

All of these are valid and useful ways to approach conflict
in some situations. And each can be destructive when misapplied.

In the story about Pam and Jim, Jim could have achieved his
stated interest had he been willing to look for more options to meet the goal
of early testing. His desire to prevail–competition–in this situation will
damage his relationship with Pam, and may hurt his reputation with the VP.

Pam’s approach�collaborative problem-solving, while
appropriate in this situation, might not be helpful when there’s a clear
downside to meeting the other’s interest—for example if the other person
wants to pursue an illegal or unethical action. Pam’s collaborative approach
also takes time in order to uncover interests, generate options, and reach a
mutually satisfying outcome. It’s worth the time when long-term relationships
are at stake, but may not be when time is of the essence or the relationship is
transitory. (If a store clerk in the airport wants to talk on the phone with a
friend instead of serving you, and you have a plane to catch, you probably
won’t use a collaborative problem solving approach. You just want to pay for
your item and be on your way.)

Likewise, yielding is fine when one person doesn’t have much
investment in the outcome and the other person does. Yielding hurts when it’s
habitual–one person always gives in to the other. Others may perceive habitual
yielders as doormats and walk all over them. An
example in the workplace is when someone always says “yes” to all his manager’s
requests without discussing risks and negotiating. The long term cost of
habitual yielding is resentment, depression, anger, and contempt.

Avoidance may be the best policy when there’s nothing to be
gained by working through an issue. For example, one manager walked away from a
conflict with a peer when they couldn’t agree on a testing standard. He saw
that the situation would correct itself as soon as the standard (which he
believed was misguided) was published to the organization, and that arguing
with his peer would only damage their relationship.

We often hear that compromise is the ideal, and sometimes it
is. But looking for compromise often ends in a half-horse, half-camel solution
that isn’t fully satisfying to anyone. Compromise leads people to miss novel
solutions that can satisfy both parties and may be better than either of the
original solutions. Pam could have compromised and agreed to turn over
partially completed features, but that wouldn’t have worked out well for either
Pam or Jim. Compromise is the best option when it’s clear that a collaborative
solution isn’t possible.

Like Pam and Jim, most of us have a preferred style for
approaching conflict. Sometimes it works for us–and sometimes it doesn’t. When
we approach every conflict with the same style, regardless of what’s at stake
and without consideration for maintaining important relationships, we may win
in the short term but lose in the long term. Or we may avoid a difficult
conversation but build up resentment. We’re all more effective when we develop
our ability to approach conflict with the style that suits the situation.
Consciously choosing which approach fits best, given the stakes and the
relationships, is a winning strategy every time.

convert this post to pdf.

Wednesday, February 28, 2007

An Appreciative Retrospective

“Our retrospectives have become so repetitive,” Fran told me over lunch one day. “We seem to cover the same ground no matter what problem-solving approach I try.”

“Have you tried AI yet?” I inquired.

He retorted, “What does artificial intelligence have to do with anything?”

“Sorry for the confusing acronym. Not artificial intelligence. AI stands for Appreciative Inquiry, a different approach. I find that folks can get a lot more out of their retrospectives when they use an approach that focuses on where they’ve added value or felt high energy. Teams often lose energy when they hunker down to confront setbacks, obstacles and mistakes. It’s discouraging.”

“I haven’t heard about your AI. Tell me more.”

Developed by David Cooperrider and colleagues at Case Western Reserve University in the 1980’s, the AI method brings a fresh approach to improving systems and catalyzing change. AI begins with a series of interviews and questions ? the inquiry. Cooperrider based his method on the observation that humans learn and change in the direction of their questions. Appreciative inquirers search for the best in people, their organizations and their environments. They ask questions to uncover stories of when their group felt most alive, contributed most effectively, and found itself most capable of adding value?or appreciating. (For fuller definitions, see the links at the end of this article.)

I prefer an appreciative approach in retrospectives and try to build an appreciative focus to all or part of every session I lead. Teams who build on strengths, successes, and positive energy carry that energy and momentum forward. They also accelerate and deepen trust in their team and work relationships.

Retrospective leaders and teams who focus on what went wrong, where the team failed, and who to blame generate a downward spiral of depleting energy. The team often stops holding retrospectives as a result. Putting attention on failure and blame depletes trust among team members?who start to avoid failure more than seek success. Continuous improvement discontinues.

How can a retrospective leader shift to an appreciative inquiry approach?

What would a retrospective that followed an exclusively appreciative model look like?

Follow the retrospective framework from Agile Retrospectives: Making Good Teams Great! by Esther Derby and Diana Larsen, then give it an appreciative twist.

Book Cover

Set the Stage:
To begin, welcome team members to the retrospective. State an affirmative goal for
the session. Choose among goals like:

During this retrospective, we’ll find ways to amplify our strengths in process and teamwork.
In this session, we’ll discover where we added the most value during our last iteration and plan for increasing the value we add during the next iteration.
The goal for today’s retrospective is building on our best uses of engineering practices and methods.
We’re going to seek out our highest quality working relationships and find ways to expand on them.

Or any goal that sets up an expectation for positive outcomes.

After stating the goal and giving an overview of the agenda for the retrospective, offer a quick round-robin question to each team member, “Which of our working agreements did you see in action during this iteration
(or release)?” This question brings team members’ attention into the retrospective session and reminds the group of their working agreements?by focusing on the times when they followed them.

Gather Data:
Team members ask and answer a series of three or four questions that focus awareness on individual and team strengths and successes.”Tell us a story about a time this week when you felt particularly energized by our work.”"What did you value most about your contributions this week?” (No false modesty allowed. This isn’t bragging or boasting, it’s important data for the team.)

“What did you value most about the work we’ve done together?”

“In what ways did this iteration (release or project) make a unique contribution?” or “What metaphor describes this iteration (release or project) best?”

Keep track of these answers for later. The team will use the responses along with ideas from the next phase to help determine which actions they want to take.

Generate Insights:
Follow the data gathering questions with a question that creates a vision, such as, “Imagine we could time travel to the end of the next release. When we arrive there and converse with our future selves, we hear that it was the most productive, most satisfying effort we’ve ever worked on. What do you see and hear in that future time?”

Wait 2 or 3 minutes for team members to connect with this vision. Then ask: “What changes did we implement now that resulted in such productive and satisfying work in the future?”

Write down all the answers.

Look back over all of the answers the team gave in the last two phases. Pull out common ideas. Look for patterns, common threads, and compelling ideas, then consider why these hold significance for the team.

Decide What to Do:
Based on the data and insights, discuss the implications of different possible actions. Ask: “Which ideas and actions build on our successes, meet the situational (or customer) needs, and tap our greatest energy?” “What are we best positioned to try next?” “What do we really want to try (or sustain)?” Create a list of potential action steps.

Choose no more than three small actions the team can take during the next increment of work. Identify which team members want to lead the follow through effort for each action. Only volunteers with zeal for the action item need apply. No one gets “volunteered.” Ask team members to include the tasks in iteration or release planning and report on the outcomes at the next retrospective, or sooner.

Retrospective leaders can create various activities around affirmative questions by having team members record some key words from answers on sticky notes or index cards for easy sorting. Or record answers on flip charts or white boards. Use dot voting or consensus techniques for selecting final actions.

Close the retrospective:
Reiterate the actions the team chose to undertake. Lead the “Offer Appreciations” activity or hold a full “Temperature Reading,” if you have time. Ask that team members write the thing or things they liked most about this retrospective, so the retrospective leader can incorporate that feedback and design even more satisfying, enjoyable retrospectives.

Voila! A retrospective held entirely with an appreciative inquiry approach.

Keep the lists you’ve created of patterns, common threads and compelling ideas. They will provide a rich source of future retrospective goal topics. Look for other sources of appreciative questions to hone in more specifically to those topics. Sources include:Appreciative Team Building by Whitney, et al, and Encyclopedia of Positive Questions by Whitney, et al.

Teams hold retrospectives to inspect and adapt their processes, methods and teamwork. Taking an appreciative approach to leading retrospectives gives the team a new perspective and renewed energy for implementing actions. Conduct your own experiment. Track the enthusiasm for follow-through you get from a positive core-focused, affirmative retrospective. Compare it to “balanced” and/or obstacle- or vexation-focused ones. Let me know what you find.

For more on Appreciative Inquiry:

“What is Appreciative Inquiry” at http://appreciativeinquiry.case.edu/intro/whatisai.cfm or visit the Appreciative Inquiry Commons hosted by Case Western Reserve University http://appreciativeinquiry.case.edu/.

“Appreciative Inquiry” entry at wikipedia http://en.wikipedia.org/wiki/Appreciative_Inquiry

convert this post to pdf.

Sunday, March 5, 2006

What to Do When Your Project Slips

You’re not going to meet schedule. Maybe requirements have taken longer. Perhaps in the middle of implementation, you uncover something requiring redesign. Maybe developers haven’t met one milestone yet and you’re worried about the test time. What do you do?

The first slip is the initial indication that something is wrong. Don’t think you can make up time. You can’t. Use the first slip to evaluate what’s going on vs. what you’d like to have going on. When you hit the third or fourth slip, you’ve lost the schedule battle.

Early Schedule Slips

When software projects begin slipping, they’re talking to you. The first slip is a whisper: “Your expectation is not matching my reality. Listen. I can tell you my reality.” If you ignore the first slip, the second slip is a murmur: “Things aren’t quite right. Don’t you want to know what’s going on?”

By the third slip, the project says: “Knock-knock. Are you there? Don’t you want to know what’s going on?” At the fourth slip, the project yells: “Hey, you! You didn’t listen when you could act. Now you’ll have to pay.”

As an observant project manager, when you detect an early schedule slip, you have several options, all related to the project quality requirements and project constraints common to every project:

Project Requirements	Project Constraints
Ship Date	Cost to Market
Feature Set	People working on the project
Low Defect Levels	Work Environment

With an early slip, you can change all, or a combination of these: change the ship date or feature set, allow different defect levels, increase project cost, add more people, or change the work environment.

Mid-Project Schedule Slips

After a couple of schedule slips, when you’re in detailed design or early implementation, it may be possible to inject more people into the project, or change the way you work. I’ve had success with design inspections from people outside the project when we realized the design was not going as well as it should. If you’re in early implementation, maybe you can change the feature set or allow more defects, and still ship on time. If you consider the project requirements and project constraints, changing the feature set or allowing different defect levels are no longer options at this stage.

It’s easiest to slip the ship date, increase the project cost, or change how people work. If you can’t slip the ship date, then you must change how people work. Reviews and inspections can help the design and implementation effort dramatically. The implementation may not meet its milestone date, but with reviews and inspections, you may be able reduce the rework and therefore, some of the test time.

It’s much harder to decrease the feature set (some features may be coupled), or achieve low defect levels in the same amount of time. Generally, it’s also difficult to get more people on the project, but you may be able to hire some people with specific skills: automated test developers or exploratory testers, an external architect to help look at the design, more project managers on a large project. When you add more people to the project, ensure everyone understands their roles so that you don’t slow the project.

Late in the project slips

I recently worked with a company just before they planned to ship a beta release. They were having trouble getting the software ready and they wanted help completing the work done by their beta date. I had questions about the schedule, defect data, testing, and how the developers integrated the code. My first question addressed schedule. “Oh, we planned the schedule six months ago. We haven’t changed it.” I asked if they’d met their milestones. “Well, not really. We missed the first deadline. The requirements weren’t done, but we had to get started, so we started designing without knowing all the requirements.” This is risky, but not a Terrible Thing, especially if they planned to manage the risks. I asked about the other milestones. “Well, since the requirements weren’t done, we couldn’t finish the design on time. Since the design wasn’t done, the coding was late.” The first slip cascaded into every other milestone. Then came the key question: “When did the testers know what to test, if the requirements, design, and implementation were late?” The answer? “Last week.” Uh oh.

I asked one more question: “How much testing did you plan for this project?” They looked at each other. “Well we planned about six weeks worth, but I guess we won’t get to that now.” These people were not stupid. They had a simple problem with a huge cascading effect. Then they had trouble hearing the reality of their project. They started with a small slip, but because they kept going, it magnified the effect of later slips. If they had stopped at the first slip and re-planned their work or schedule, they might have met their beta date. Now, their only option was to extend the schedule.

It’s extremely difficult to recover from late-in-the-project slips. Our only options are to extend the schedule, increase project costs, or change the work environment. In this situation, see if you can change what people are doing. I find that peer review or inspections of every fix helps reduce the number of bad fixes. If you can reduce the amount of rework, especially from bad fixes, you can stop having to extend the schedule. It’s extremely difficult to add more people unless the testers have not yet had a chance to design the tests -you might then be able to use more exploratory testers to save some time.

Summary

If you’re still early in the project you have some options and the most appropriate ones for you depend on what’s driving your project. Clarify your project’s requirements and constraints and you’ll know better what to do. You can reduce the feature set by using peer review on all fixes (to decrease the number of bad fixes), and re-plan the rest of the schedule in detail with the technical staff, using inch-pebbles. If you’ve lost the schedule battle, give up and cut your losses.

Schedule slips are a useful indication that something is not-quite-right on your project. Use that information to make the best decision for your project.

convert this post to pdf.

Delivering Effective Feedback

Josh was dumbfounded when his boss, Brad, fired him. As far as he knew, his work was just fine. But Brad believed he?d given Josh ample warning that his work and work habits weren?t up to par.

When Brad told me he?d fired Josh, he seemed puzzled, too.

?I just don?t get it,? Brad said. ?Josh acted all surprised that he was being fired. But he should have known. I told him not to watch stocks at work. And it wasn?t just that,? Brad continued. ?His other work wasn?t so great. I expect tech writers to turn over clean copy. When Josh handed in work, I always had to proof it.?

?Hmmm. That is puzzling,? I said. ?How did you give him feedback??

?Well, I was walking by his desk one day and saw him checking the stock market sites, so I asked him what he was doing. Josh closed the browser and said something lame like ?Oh nothing.? So I said to him, ?Doesn?t look like nothing to me. Looks to me like you?re checking out the markets.??

?Is that the only time you gave Josh feedback?? I asked.

?No, I gave him other feedback. I brought up appropriate Internet use at a team meeting. And I gave him feedback on his writing, but it was always the same thing. I told him, but he just never listened.?

?How?d you tell him about his writing?? I asked. I was beginning to detect a pattern.

?Well, I proofed it and handed him back the markup. Next time it was the same thing. All five chapters he worked on were the same. It was like he expected me to proof his work,? Brad huffed.

I?ll bet poor Josh didn?t have a clue he was in hot water at work.

Communicating Expectations

Brad may have been more effective, and Josh might still have his job, if Brad had followed these steps for delivering clear and intentional feedback.

Give serious feedback in a serious setting. Brad gave Josh important information in a casual manner while walking by his cube. Neither the timing nor the setting marked the communication as important. Regular one-on-one meetings are a great place to provide feedback for minor course corrections. Always schedule a separate, private meeting to address situations that are more serious.

Address specific issues individually. Brad made a general announcement outlining appropriate Internet use in a staff meeting. General announcements of policy don?t carry the same weight as an individual conversation. If it?s important enough to bring up, it?s important enough to speak directly to the person involved.

Give clear examples. Brad would have been more effective if he had said something like, ?Josh, I saw that you were checking the stock markets on the Internet this afternoon, and on Monday and Tuesday,? or ?In Chapter 1, I had to correct numerous spelling and grammar errors.? General statements such as ?your work is of poor quality? don?t provide enough specific information for people to know what to improve. Labeling statements, such as ?you?re a sloppy writer,? will set up an oppositional dynamic that is likely to go nowhere.

Check for agreement. Getting agreement on the data is the first step in problem solving. Provide concrete facts. People are more likely to accept what you say when it is specific and observable. Josh will probably acknowledge that there were spelling errors in Chapter 1; Josh is less likely to admit to being sloppy. (Of course, if the employee consistently denies the facts, that?s another problem for another article.)

Request a change in performance. While he did drop little hints, Brad never clearly communicated to Josh that he?d like to see changes. Brad could have said, ?I?ve marked spelling and grammar errors on the copy you gave me. In the future, I expect copy to be clean when I receive it.?

Engage in problem solving. Brad could have made a straightforward request for a change in performance, or he could have engaged Josh in helping to solve the problem. Brad might have said, ?Josh, I was surprised at the number of spelling and grammar errors in the chapter you turned over to me. I expect copy to be clean when I receive it. What are three ways you can make sure the copy?s in good shape?? Josh might come up with several ways to reduce errors. He?s more likely to accept the solution if he?s involved in creating it.

Agree on how you?ll follow up. Sometimes you?ll need to follow up on the changes you?ve requested. Brad and Josh could have made an agreement that Brad would skim for obvious spelling and grammar errors and return the work to Josh if he found any.

Check for understanding. Brad assumed that his indirect hints were sufficient. He didn?t check to ensure that Josh had received the message. One manager I know wraps up feedback conversations by saying, ?I?m going to check for understanding now. I?d like you to summarize our conversation for me so I can be sure I?ve been clear.?

Giving clear and intentional feedback is an important part of every manager?s responsibilities. Our employers pay us to provide timely information to our direct reports to guide and influence their work and work habits. Providing feedback effectively gives employees information that may help them improve their performance. And that means we?re more likely to meet management goals, too.

convert this post to pdf.

How to Improve Meetings When You’re Not in Charge

This column originally appeared on Stickyminds.com

Are you tired of attending endless meetings where the conversation goes in circles and nothing gets done? Even if you can’t stand up and take control, you can nudge the meeting in the right direction from where you sit. Here are some strategies for improving the quality of meetings when you’re not in charge.

Ask for an agenda ahead of time. When you receive a meeting notice, ask for an agenda. Make your request in the spirit of the best use of everyone’s time: “Knowing the agenda will help me come prepared to participate.” You can also say, “Knowing the purpose of the meeting will help me determine whether I can contribute.”

Sometimes a request for an agenda is unsettling to the meeting convener? probably because he hasn’t though through the purpose of the meeting. Your request may prompt him clarify in his own mind why he called the meeting. If you’re really lucky, he’ll realize he didn’t really need a meeting at all (it happens!).

Sometimes though, a meeting convener will insist that you must be there, even though he can’t provide an agenda. I’m a little skeptical when the meeting convener assures me that I need to be there but can’t articulate the purpose of the meeting. If you feel like its not political suicide, tell the meeting convener that you can’t assess the priority of his request against all your other work without an agenda.

Send only one person. Sometimes the person calling the meeting goes overboard to be inclusive. If two or more people from your group are asked to attend a meeting, check to make sure that all perspectives are really required. In many cases, one person can speak to the interests of the group and you can send a representative. One person can go spend an hour at the meeting and then report to the rest of the group. Fewer people will make the meeting easier to manage and the people from your group who don’t go will have a bit more desk time.

Politely decline the invitation. When you don’t have relevant knowledge and expertise to contribute or won’t be affected by the outcome of the meeting, bow out. Ask to be on the distribution list for meeting notes or other communication.

Offer to take notes. Some times when I talk to people after a meeting, its hard to believe we were in the same room. Taking notes can help. As a participant you can offer to help by taking notes. Bring your flip chart paper and a marker and take notes so that all can see. Taking notes in public ensures that every one agrees that what is written is what was said.

Facilitate from where you sit. A well-timed question or comment has saved many a meeting. Here’s a sampling of tactics that I use to facilitate from the back of the room. One word of caution about facilitating from the back of the room: Do this only if you genuinely want to be helpful. If you’re feeling snide, it will come across in your voice.

Request a review of the agenda. When you arrive at a meeting with an overstuffed agenda, make a request to review and prioritize the agenda: “I’m wondering if we have time to cover everything we need to in the time we have. Can we please review and prioritize the agenda before we start?”

Ask for a progress check. When you see that time is getting short, ask for a process check: “I’d like to check on our progress. Its 1:50 and we still have three topics on the agenda. Can we prioritize them since we can probably only do one in 10 minutes?”

Help others participate. You can help the meeting when you help others participate. If you see a quiet person trying unsuccessfully to break into the conversation, say “I think Jennifer has something to say.” Don’t force her to speak, but make an opening if she wants to take it. You can also help when a speaker is interrupted: “I think we may have cut Josh off before he had a chance to finish. Josh?” Then Josh can finish his though if he wants to, and the interrupters will be a bit more aware of their behavior.

Rephrase. Sometimes rephrasing can help when someone is stuck on one point: “What I hear you saying is XYZ. Is that right?” Rephrasing helps people feel heard and can break the logjam.

Comment on what you observe. Sometimes it helps to comment on what you observe: “I think we’ve covered that already,” can help get people moving again.

Summarize. Summarizing important points and decisions can help the group move forward. “Here’s what I heard us agree to. Is that right?” Don’t be upset if people disagree with what you’ve said ? you’ve just turned up the fact that people really don’t have a common understanding. Once you’ve surfaced the misunderstanding, it’s more likely to be resolved before everyone leaves the room.

You may not be able to solve every meeting problem when you’re not in charge. But you can help many meetings to run more smoothly. After a while, people may start following your cues: they’ll write an agenda, pay attention to whom they invite and start attending to the interaction. And you’ll look good, too.

convert this post to pdf.

Going the Distance: Five Tactics to Compensate for Distance on Distributed Teams

This article originally appeared in Stickyminds.com

When people
communicate face-to-face, they not only hear words and inflections, but also
see facial expressions. This helps each communicator understand what the other
is saying and gives clues to assess when people are mad, sad, or glad.
Teammates know what each other looks like; they learn about each others
families.

But it’s not always possible to have a
team working in the same room. When people aren’t co-located, you can’t just
hope that communication will work and the team will gel–that somehow,
miraculously a group in the U.S.
will hand off to a team in Hungary
without missing a beat. Some teams can achieve round-the-clock attention
through seamless hand offs, but it’s rare and takes a lot of work.

When teams aren’t collocated, they face
challenges about contact, time, context, and culture. To compensate for the
distance, extra effort is required to make contact with distant members,
leverage phone time, adjust for time zones, and learn the differences in
context and culture. Below, I’ve detailed five tactics that can help you
compensate for distance on your distributed team.

1. Make Contact
When people are in the same room, or at
least close by, they get to know each other. They develop relationships that go
beyond work-related transactions. They may not be best friends, but there’s
some social element that ties them together.

You may never get to meet your
distributed teammates in person, but you can make contact. Post a map that
shows where your far-flung team members are located. Post pictures of them. (We
tend to trust what we can see, and this little gesture can help build trust.)

When you can, share a meal together–even
if you are on different continents. Schedule a call, post the pictures, and set
the table. Breaking bread together is an ancient sign of hospitality and good
will. This simple gesture can help knit the team together.

2. Make the Most of Phone Time

There’s an old adage, “Children
should be seen but not heard.” It seems that conference calls go even
further: people who aren’t seen are often not heard. One team I work with has
pictures of every offsite team member in stand-up frames. When they have a
conference call, the frames are placed around the table to remind the people in
the room of who else is on the phone. This way they are less likely to forget
the people they can’t see.

Until everyone on the team recognizes
each other’s voice, it’s good practice to say your name each time you speak.
Yes, it feels awkward, but it really helps the people on the other end of the
phone who aren’t in the room and can’t see who is speaking. Be careful to have
one conversation at a time; a babble of voices emitted from a small, black box
is impossible for most mortals to decipher.

Appoint a facilitator for each call.
Having someone monitoring the flow of conversation and participation helps the
quality of conference calls immensely. Poll the people on the other end of the
line when it’s time to generate ideas or give input. Don’t rely on them to
break into the conversation.

Utilize wikis–Web pages that users can
edit on the fly–to build a meeting agenda and post decisions, action items,
and other meeting outcomes. My team–there are six of us in six different
states–uses a wiki to keep track of meeting outcomes and any other important
information that each of us needs to know.

Don’t use conference calls for serial status
reports. In my experience, the people who aren’t talking during these regularly
scheduled calls also aren’t listening. They’ve hit the mute button and are
probably checking their email. Save phone time for when you need to have
conversations.

3. Adjust for Time Zones
Most of the time, I can keep track of
time zones within my own country. I have a harder time minding time zones
across the world. Along with your map, try posting inexpensive clocks that show
what time it is where each group is located. The clocks remind us that the end
of our day may be the beginning of someone else’s.

Make every effort to schedule meetings in
the slice of time that overlaps “normal office hours” for as many
people on the team as feasible. When there is no overlap, don’t always expect
the “other” team to get up early or stay up late. Be willing to trade
off for the extra hours of work.

4. Understand Context
Even if you work for the same company in
different locations, you work in different organizations. Learn as much as you
can about your teammates’ work world. What is the organizational structure?
Don’t assume it’s just like yours, even in the same division. What are the
physical arrangements? Having a picture of your teammates’ physical
surroundings–their cubes, floor, and building–is another way to make distant
people more real.

Look for commonalities between your
organization and each teammate’s organization. They may share similar values,
or they may not. Knowing where there is overlap and where there isn’t helps you
manage expectations.

5. Be Sensitive to Culture
Some cultural differences are readily
apparent, while others are subtle. Watch out for words or expressions that mean
one thing in your language and something different (and possibly negative) in
another’s culture.

A Canadian friend of mine tells a story
about how he inadvertently offended half his team by offering a virtual
toast–”Cin cin!”–after a successful code release. His toast had a
completely different meaning in Japanese–one that I can’t write in this
column.

Making a distributed team work takes
extra effort, but putting all these tactics to use can help any team traverse
distance. Differences in context, culture, and organizations are magnified when
there isn’t day-to-day contact to build familiarity. Compensate for the
challenges by applying these and other practices to help your distributed team
gel.

convert this post to pdf.

Incorporating Part-time Team Members

This article originally appeared on
stickyminds.com.

“Part-timers just don’t seem to fit in with the team,” a manager complained. “I do everything I can to impress on them the importance of team work and team spirit, but they just don’t gel with the team. What can I do to motivate these people to fit
in?”

Here’s the news nobody wants to hear: The problem is no with the part-time people. It’s with the part-time assignment.

Priority

When a person is assigned to more than one team, she’ll guage priority by the proportion of her time that’s allocated to each project. One tester I know was assigned 90% to developing manual test cases and 10% of her time to creating a “critically important” automated test harness. No matter what words her manager said about the importance the test harness, the fact that she was directed to spend only 10% of her time on it communicated a different message. Further, when she attended meetings or working session with the automation team, she spent most of the time catching up on what had transpired since her last sliver of time with the team.

The arrangement wasn’t satisfying for her, and frustrated the automation team. Soon, she stopped working on test automation at all.

Ambiguity

Many people will opt to spend their time on work that has clear-cut outcomes over work that’s ambiguous. The more clarity around the part-timer’s contribution, the more productive the situation will be for everyone.

Team Cohesiveness

If the full-time team is cohesive, the part-timer may not be able to fit in. Gelled teams develop their own subcultures. They may have unspoken rules of engagement, communication patterns, and established relationships that make it difficult for someone who isn’t full time to fit. Over time a part-timer may acculturate, though the process will be slower than it would be for a full-time team member.

Missing Context

When someone works on a team part time, he is by definition missing part of the context of the team. While the part-timer is off doing something else, the full-time team makes decisions, solves problems, and exchanges information. While the full-time team may document and transmit major events, there are numerous small decisions and communication events that may not seem important enough to pass along but still affect the way the work is done. The adage “You never step in the same river twice” fits this situation. Each time the part-timer re-enters the team, the team has inevitably moved on from the last time the part-timer participated.

So, what can managers and team members do to improve the situation? First look at the work and how the part-timer needs to contribute. Here are some of the questions you may ask about the work:

Is his contribution time-limited, meaning that his skills are needed for several days, but not for the duration of the project? Maybe the person only needs to contribute at some critical point. Perhaps he is only needed for one or two iterations, when the team is working on a particular feature. Consider contracting for the person to focus full attention for those periods of time.

Can the contribution be batched so the part-timer interacts with the team for a day or two a week? Blocking out a day or two a week to work with the team is more effective than having the part-timer spend an hour here and an hour there with the team. This may require more clarity and coordination from the full-time team, but it will make better use of everyone’s time in the long run.

Is the part-timer needed for hands-on work, or can he act as a reviewer, consultant, or coach to members of the full-time team? Sometimes the full-time team needs to use a certain skill a little bit each day or week, but needs the skill over all long period of time. In this situation, it could make sense to develop the skill on the team and have the part-timer act as an expert coach or reviewer until the full-time team members are self-sufficient. Teams who have all the skills needed for the work are often most productive.

A person can act as a resource to a full-time team without being a member of the team. The team can contract for deliverables, consulting, review, or time. After you understand the nature of the work and the contribution needed, work with the full-time team and the person whose skills are needed to develop explicit agreements. Don’t rely on happenstance and assumptions. Reach agreement on how the full-time team and part-timer will work together, how the part-timer will contribute, and how the full-time team will keep the part-timer in the loop. Don’t expect he’ll gel completely as a member of the team?because he won’t.

Sometimes I see groups in which almost everyone is part time. Sometimes a group working together part time will gel, usually when they have a long, shared history. Don’t expect groups made up entirely (or mostly) of part-timers to gel as a team without time and attention to creating a cohesive whole. And as long as the group is accomplishing its goal and managing the interdependencies between tasks, that’s OK.

It may look simple on paper to say a team needs a specialized skill X amount of the time, but by analyzing the nature of the work and being explicit about part-time arrangements, you will help the team and the part-timer work together more productively.

convert this post to pdf.

Decide As a Team

Do some members of your team make agreements during meetings but fail to support them afterwards?If this behavior is happening, I suspect your team is using an obscure process to make decisions.

Identifying Obscure Process

An obscure decision making process is easy to identify. Ask each member to create a map of the process used to make team decisions. If the individual maps aren’t similar, obscure is an accurate description of the process.

Probe the maps of an obscure process further and you will find false assumptions. Members assume things about the behavior of other members that isn’t true; for instance, some members assume that their teammates will support the decision made by a team and how it was made with outsiders and yet some other members assume that their support is only necessary when they personally agree with the decision.

I believe an obscure decision making process disables teamwork. People aren’t connected by shared principles. They don’t cooperate. They work like a group of individuals. It doesn’t have to be this way.

I have worked with a simple, clear process for making team decisions for over a decade. I have found it highly effective. It’s designed for teams who make their decisions by consensus. If you are the leader of a team, you may object to the idea of a consensus decision. The idea may trigger the word “groupthink” to pop into your head. But as I will discuss later in this post, a leader has more control over a consensus decision than they might initially think.

Making Team Decisions

The aforementioned simple process is called Roman Evaluation. Figure 1 is a map of the process. Using the process creates visible feedback about the state of each member’s agreement on a proposed team decision. That feedback drives needed discussion and eliminates unneeded discussion.

Figure 1. A Map of the Roman Evaluation Process

Follow the following four steps to help a team reach a decision:

1. Propose

A proposal that defines a course of action desired by a member of the team drives the process. Without a concrete proposal, there isn’t any decision to be made.

The first four words of any proposal are “I propose that we…” This wording explicitly announces the proposer’s desire; for example, “I propose that we reduce the duration of this meeting to 60 minutes.”

Note, the word “we” is used to clearly identify that it is a team decision.

Post a written copy of the proposal in the room so that every member is able to read it own their own during the entire decision making process. The proposal may be amended so leave room for changes.

I would write the proposal mentioned earlier as, “Steve proposes that we reduce the duration of this meeting to 60 minutes.” Communicate it to the group using whatever medium you prefer, such as a flip chart, overhead projector or computer projector.

2. Discuss

Let the proposer speak first so he or she can provide context. Start facilitating a group discussion with an explicit duration. The purpose of the discussion is to understand the proposal and its impact. Using the example, I might ask the proposer: “What’s the problem you are trying to solve by reducing the duration of the meeting?” I might ask the team, “What do you think?”

My experience is that groups often exceed the time allocated for discussions so constantly monitor the time and periodically share how much time remains. Whenever either the discussion naturally ends or the time limit expires, close the discussion and vote.

3. Vote

A group recognizes their agreement faster with clear signals. Ask each person to signal their decision with one of their thumbs:

Up means “I agree.”
Sideways means “I will accept the majority’s decision and support it.”
Down means either “I disagree.” or “I have something to say.”

I suggest that you emphasize that a thumb up or sideways means the member will support the proposal. Spell out that support means they will say “We decided to…” when asked about a decision by an outsider (see my post entitled Word Choices — We — Part 2). And they will defend the logic behind why the decision was made. This understanding makes voting a serious responsibility rather than a ho-hum exercise.

The vote gives the team clear feedback about the state of their agreement on the proposal. It enables different choices to be made than are possible without feedback.

Record the vote and verify that you have the same number of votes as members. A consensus is any mixture of thumbs pointing up or sideways. Any thumb pointing down signifies dissension.

4. Process

As you tally the vote, write down the names of people with their thumb down. Ask each dissenter, name by name, what he or she would like to say about their vote. Don’t let anyone interrupt them. When each dissenter finishes, ask them whether their thumb is still down. They may surprise you. My experience is that many people want to say something and once they do, they move their thumb up or sideways.

If there is still dissent, ask the team whether someone wants to amend the proposal. If someone offers an amendment, discuss, vote, and process. Otherwise, reject the proposal.

Considering Consensus

As you may have guessed, I believe in consensus decision making. Some leaders have told me they don’t like it though. They believe it leads to “groupthink.” I understand the thought, but that doesn’t happen. If the leader makes it clear that in the absence of a consensus they will decide on the course of action, groupthink is impossible.

The leader is a member of the team. They vote on a proposal. And, like all the other members, they are free to vote so the team makes the appropriate decision. If they put their thumb down and an acceptable amendment can’t be found, then they are free to make the decision they think is best.

I suggest that leaders don’t make a habit of using this power. But, in my experience, some situations demand decisions in a faster time frame than a team may be able to process them.

Conclusion

Roman Evaluation has a powerful effect on decision making. It connects the members of the team. It creates shared principles. It increases cooperation. It helps build a solid foundation for teamwork.

When reinforced, the act of voting makes it clear that unless a member vetos a proposal, as a member of the team, they are expected to support the proposal. And that’s the kind of thinking that binds a team together.

If your team’s decision making process needs improvement, I can help. Contact me.

convert this post to pdf.

Implement by Feature

This article was previously published in Better Software, May 2005.

Brent and Deidre, both technical leads, poked their heads in Myrtle’s door. “Myrtle, we have a problem.”

“OK, come on in. What’s up?”

Deidre started. “Remember on our last project we had trouble integrating the entire system? Testing couldn’t start until later than we wanted. And, when they did start, the testers found a whole bunch of things we hadn’t considered? Well, Brent and I think we could be doing the same thing again.”

Myrtle asked, “Why? What have you seen?”

Brent took up the story, “Well, I’m leading a design review with the other middleware developers, and Jon asks me how we’ll get the data from the GUI, and who will verify the data is good. I said, ‘The GUI will.’� Jon said he checked with Nancy, and she said, ‘You guys will.’ So I fixed this potential problem, but there are dozens of others we haven’t talked about.”

Deidre added, “Right, we’re running into the same thing in the backend/database group and with the stored procedures. I discovered one problem, but there are plenty more I haven’t dealt with yet.”

Myrtle thought for a few moments, considering the information her team leads had just provided. She answered, “OK, both of you are the technical leads for your areas. If we bring in Nancy, can’t you three
deal with all of these issues and solve them?”

Brent looked at Deidre, and then shook his head. “No, there are just too many little details we have to resolve with each feature. We can’t do all the design up front. We need a way to interact with each other as we build the system.”

Deidre burst in, “But we have an idea! We can work a little differently, integrating as we build.”

“But, we already build every day. What do you mean?” questioned Myrtle.

Deirdre said, “Right now, the GUI team does all the GUI work for the whole release, the middleware team does all the middleware, and the backend/database team does all of their work. But what if we took each feature, like the one we’re working on now, enabling payment from two sources, and worked on each feature?and just each feature? with a cross-functional team?”

Deidre went on to explain how they could have several concurrent teams working on several features at one time, but with someone from each area?GUI, middleware, and backend?working together.

“If we need a few more people from each team because a particular feature has more complexity, OK, we get more people,” Dierdre offered. “We can use people who are not on our teams to review our designs. But the key is that we implement by feature, not by architectural component.”

Brent added, “But we need testers as a part of that cross-functional team, because we don’t want to wait until all the development is done to test. That way, we’ll know that we’re actually creating pieces that work together.”

Myrtle considered their proposal. “Well, it means our project schedule is toast, but from what you’ve said, it’s toast anyway. It sure would be nice to know that when you guys say the product works, it really works. Can we start with just a piece of the system, maybe the two payment sources piece, just to see if we can do this?”

Brent nodded. “You bet. In fact, if you give me these people,” he pointed to an organizational chart, “I can finish two payment sources in a week.”

Brent arrived in Myrtle’s office four days later. “Hey, Myrtle. We’re done with two payment sources.”

“You are? You’re a day early. But did you test it? Do you really know if this works?”

“You bet we did. In fact, we tested lots more than we normally test, because the tester was able to focus on just this one piece.”

Myrtle was thrilled with their progress, but knew she wasn’t ready to rush a new practice into use across the project without trying it again. She asked Brent to suggest another couple of features on which to try the same practice to ensure that the first success was not just an anomaly. Brent agreed and soon those features were implemented with similar speed and reliability.

Once the other cross-functional teams completed their features better and faster than expected, Myrtle took the risk and reorganized the project to create integrated feature teams, and continued to implement feature by feature. The project was a success.

convert this post to pdf.

Plan to Re-plan

Do you sometimes feel partway through a project, that you now have some key information that would have helped you plan the project’s tasks better?

If so, you’re not alone. Software projects typically unfold in unforeseen ways. One task might complete faster; another task might take longer. When I plan to replan — to iterate the planning — I can improve the overall project schedule.

Here’s how you can plan to replan:

Define the five to six major schedule milestones. Choose milestones that have specific meaning for the project team, such as feature freeze, code freeze, system test start, Beta test start, and first customer ship. Outline the already-known tasks in the initial schedule for all of the project phases: requirements, design, implementation, test, beta, and ship.
Specify criteria for each milestone. This way you will know whether or not the project has actually met those milestones. To see if my project team has met feature freeze, we hold a short project status review. For every feature, we ask, “Did we complete the requirements?” and “Did we complete the high level design?” If the answer is yes, then we have met our definition of feature freeze.
Plan the tasks needed to get to the next date. During the requirements and design phase, I refine the planned tasks and duration for the coding phase. I start outlining the tasks in the integration phase. Once the project team agrees when we’ve met the feature freeze, I can fill in the outline of the tasks needed for the integration and test phase. Then I can start outlining the tasks for the following phases.
Build the re-planning activities into the original project schedule. Use this project’s history to help update the project plan. This way the project team realizes the project is under control, but the project team and the project manager can continually assess and manage the schedule risks.

At the start of the project, when the requirements are clarified and the prototypes are under construction, I plan the initial activities to get to feature freeze. As the project team understands more about the project, I update the initial phase tasks as necessary. Sometimes this is as frequently as every day, but it is more likely to be weekly.

I plan in as much detail for each phase as possible, as early as possible, but the plan and tasks are not frozen. During each phase, I plan the next phase’s activities in detail. In addition to continually looking at the planning activities, I measure how long the different tasks take, and where the software faults are. This allows me to start gathering data about my project while I’m in the middle of it. During the project, I use the schedule and fault data to reassess risks and refine the schedule during the project. By the time I’m in the final test phase, I am certain of the schedule required to ship the product.

For example, during the initial (requirements) phase of the project, I plan that phase in great detail and the design phase in some detail. Then, once the requirements are complete, I can finalize the design phase and plan the implementation phase in some detail. During design, I can solidify the implementation phase, and fill in the integration and initial testing phase. During the implementation phase, I can finish the detailed scheduling for the final test and ship phases. By the time the project is in the integration phase, the schedule is pretty solid, and we already have knowledge of the potential project showstoppers.

Iterative planning is not for everyone on every project. It is most useful under these conditions:

When you have an idea of what needs to be done, but not a clear idea of how to do it.
When you are pressed for time, and want to take advantage of project advances.

Iterative planning and scheduling can help you on projects with technical risk or schedule risk — when you don’t have enough product knowledge or historical data to plan the schedule with certainty.

convert this post to pdf.

Starting With Rolling Wave Planning

Some project managers considering moving to iterative, incremental, or agile lifecycles, stumble when it comes time to move to rolling wave planning. They aren’t sure how to start it, how to continue it, or how to see where the project is without using a more traditional Gantt chart and planning the whole project in advance. But for me, it was the easiest practice to start, because I knew the Gantt chart was the one way the project would not happen. No matter how good the project team’s estimate was, some events would prevent them from completing the project the way they originally estimated.

A rolling wave plan is a continuous detailed schedule that’s only a few weeks long. As you complete one week of detailed schedule, you add another week to the end of the schedule. With a four-week rolling wave schedule, I never have less than four weeks of detailed schedule, and I never have more than four weeks of
detailed schedule.

I choose a four-week rolling wave schedule for two reasons. If I’m not managing a project with defined two-week iterations, less than two weeks is not enough detail for me to foresee risks. A schedule that’s more than four weeks long tends to be wrong the farther out we schedule, so I don’t bother trying.

If you’ve never tried rolling wave planning, here’s how to start. Find a large-enough room to organize the schedule on the wall or on a whiteboard. Lay out your major milestones on yellow stickies, moving from left to right. Then ask the project team to join you in the room.

Explain to the team that instead of trying to develop the entire project schedule in detail all at once, you’ve identified when you want to reach the major milestones, as noted by the yellow stickies on the wall. Now, ask the question for the first milestone: “What will it take us to reach this milestone?” Then ask the project staff to write down their tasks and interdependencies on stickies, one task to a sticky.

I find it easiest to ask people to plan in inch-pebbles. Inch-pebbles are one- to two-day tasks that are either done or not done. Since the project manager can’t assign inch-pebbles to people, each member of the project staff has to understand his or her own tasks in detail and develop inch-pebbles to complete those tasks.

If the project staff isn’t able to plan in inch-pebbles, ask them to tell you how you will understand their progress. Thinking in inch-pebbles is not easy for some people, and they will need time to learn how to break their work into smaller and smaller pieces.

If you must make a Gantt chart, copy the contents of each sticky into your favorite project scheduling tool. Each week, as you meet with each person on the project team, you can ask them to tell you their next set of tasks, and you can update the schedule. If the people need help with their interdependencies, bring everyone together again and let them discuss their issues.

As long as you keep each milestone in mind as you proceed, you’ll find that the schedule is easier to maintain and that you spend less time with the schedule, enabling you to spend more time with the project team.

Rolling wave planning isn’t a panacea for understanding the true state of the project and planning how to achieve the next milestone, but it’s a great way to start.

convert this post to pdf.

Schedule Chicken

I perform project and process assessments as part of my consulting work. During one assessment, a senior manager took me aside, and said, “I want you to tell me what you think of our testers.” “All of them?” “Yup.” “Ok, why?” “Well, the developers meet all their milestones, but the testers don’t meet any.”

Hmm. It’s hard for me to believe that an entire group isn’t delivering what they need to deliver, but stranger
things have happened. Here’s what I discovered during the assessment. Yes, the developers met every milestone. Every single milestone. They were never late?not once.

Now, you don’t have to review too many projects before you realize that’s an incredible event. I’ve never met a project where the developers weren’t at least a day late on something. But these developers met every deadline.

I dug a little deeper. I asked one of the developers if his code was complete. “Sure it is.” “So, you’ve unit tested it, run it all on all the platforms, and made a build that you ran on your machine?” “No, I didn’t do
that. But the structure is all there.”

I asked what the developer meant by structure, and discovered that not only wasn’t the code tested, it
didn’t exist. The project schedule was so optimistic that the developers could never meet any of the deadlines if they’d worked in a reasonable way. So they sketched out what each module was supposed to do, checked it in without any testing or review, and never checked to see if the product could build. Of course the developers met every milestone; the milestones were meaningless. This is an example of schedule chicken.

You may have also seen schedule chicken in project team meetings where the project manager reviews the major milestones with the project team. Then the project manager asks the magic question, “We’re on target to make the release date, right?” Everyone seems to be nodding, or somehow agreeing with the project manager, but every single person in that meeting knows he or she will not meet this schedule. All you have to do is be ready before the last person who claims to be on time actually finishes.

Many projects have suffered from schedule chicken. It’s very hard to speak up in a room of your peers, or worse, your managers, and say “Um, my part’s not going to make it on time.” You look like the only one who can’t keep a schedule. Even if your management doesn’t blame you for being late, you might feel as if you’ve let the group or the project down.

And if you’re a developer with an impossible schedule, what hope do you have of injecting reason into the schedule? Most of the time you don’t. So, you implement as much as you can, and claim you meet your deadlines. Or, you can do what another of my clients is noticing: in the last few days or the last week before the last time you can add new code to the system, all the developers check in twice or up to five times as much code as they’ve checked in during any other week. Even if you’ve been building every night, by now the build is broken, the testers are finding problems faster than before and the developers can’t keep up with
the fixes.

Schedule Chicken starts when everyone is afraid to be honest and hopes someone else will blink first. Astute project managers recognize they need to gather more data than “Yes, I met my deadline.”

For quantitative data, I gather information about the date (planned and actual major and interim milestones), what’s been created (feature set completed) and what’s left to do (feature set remaining to implement), how fast we’re developing and testing (velocity levels), and defect levels (open, closed, and remaining open problems. If you only measure the schedule data, you’ll get schedule chicken every time.

I also measure qualitative information about the project. Anonymously, I ask people how they feel about their date commitments. The two measures I gather are % confidence each person will make his or her dates, and each person’s confidence in the overall schedule. The lower the confidence people have in their individual dates, the less likely the project will meet the schedule. The less confidence people have in the project schedule, the more problems there are in the interactions among people. As a project manager, you’ll know where you have work to do.

When I manage projects, I want to know the reality of the project, whether I like it or not. I don’t want to play schedule games with the project team, nor do I want them to play schedule games with me. And if you’re in senior management, or are a project sponsor, don’t make people “commit” to a project date they don’t think they can make, because you’re setting yourself up for schedule chicken.

convert this post to pdf.

Use All Four Parts of Project Estimation

Project work estimation has three components: the initial first cut, commonly known as a SWAG (Scientific Wild Ass Guess), tracking the estimate against the actuals, and using the schedule to see what’s happening in your project.

If you’ve been assigned project estimates, or if your project estimates aren’t particularly close to reality, don’t fret. Try these techniques to estimate and learn about your estimates.

Part 1: Create an Initial Estimate

If you’re a project manager, you probably try to estimate the work at the beginning of the project, even if you’re assigned a project end date. Sometimes, senior managers have trouble hearing what you’ve said in your estimate. I use one of these three alternatives to creating estimates for the entire project:

1. Provide a date range for the estimate: “We’ll be able to release between May 1 – June 15.” Some senior managers can’t hear the second half of that statement; they only hear May 1. If you work for a manager like that, try either of these other two suggestions.

2. Use the word “about” to describe the precision of the estimate: “5 people for about 9 months or 10 people for about 6 months.” You haven’t described an end date, but you have explained the resources you’ll require.

3. Provide a confidence level to describe the range of dates: “I have 90% confidence in June 1 and 100% confidence in August 1.” In my experience, even the managers who can;t hear the “between” estimate can hear my confidence levels.

Once you have a gross estimate at the beginning of the project, you can drill down and create estimates for each of the project components. Whether you try to create precise estimates, or choose to use slack buffers to deal with incomplete estimates, you will have some project estimate.

The problem with estimates is that they are guesses. They’re the best guesses we can make, as good as we can make them, and they are still guesses. As the project unfolds, you will be able to acquire feedback on how well you estimated and to know how to update your estimates, with the second part of estimation, the EQF, Estimation Quality Factor.

Part 2: Track EQF to Understand the Project Estimate

As you continue to manage the project, track your initial completion date estimate. Each month, or in a short project, each week, take 5 minutes out of your project team meeting, and ask: “When do you think we will finish the project?” Track that estimate on a chart set up with the release dates on the Y-axis, and the date that you asked the question on the X-axis.

There are two good reasons for asking this question. First, you continue to focus your project staff on completing the project. People tend to work on what you, the project manager focuses on. Second, by asking your project staff, you can discover the various confidences the staff has in the release date. When you look at the EQF chart, you can see if people are concerned that the project will not meet its release date, or if they are feeling confident about meeting or beating the release date. Then you can deal with their concerns or your concerns.

When you track EQF with your project team, you’re learning more about the project, and using EQF to learn how good your initial estimate was.

Part 3: Use EQF to Manage Project Concerns

I use the slope of the EQF to ask questions like, “Tell me what’s happened in the project to make you think we will meet/beat/miss the date.” When people become more optimistic or pessimistic, I want to know why. The EQF not only gives me feedback on my initial estimate, it gives me another technique to discuss the project state with the project team.

And, once I understand the project team’s concerns, I can deal with them or elevate those concerns to my management.

Part 4: Update Your Estimate as You Know More

When you first created an estimate, you developed some date range, an “about” date, or a series of dates with a confidence level. Once the project is underway and you’re using EQF to understand what the rest of the project team thinks of the date and the risks to the project, you’re ready to update your project estimate.

If the team has missed interim milestones and all of you think there is no way to deliver the requested feature set in the estimated time with appropriate defect levels, then it’s time to slip the project. Remember, don’t slip a week every week; that’s an out of control project. Instead, make the slip as long as you need it. Manage the risks of further slippage by creating more interim deliverables.

If the team has met their milestones, and you’re on track, you can close in on a more specific date. For example, if you started with a completion date of “May 1 ? June 15,” about halfway through the project you might be able to say, “May 8 ? June 10.” About three quarters of the way through the project you can probably say, “May 20 – June 1.” As you reach May 1, you can say when in those ten days you can complete the project.

Summary

If you’re only using one of these techniques to estimate and manage your projects, consider adding the others. Every project worth completing has some project uncertainty. EQF is a great technique for displaying project uncertainty, and understanding why the project team is uncertain about the project.

The more everyone understands about the project, the better your project management will be, and the more likely you are to meet your SWAG. At least, you’ll know how far off your SWAG was, and why. And that knowledge can help you on your next project.

convert this post to pdf.