I was supposed to start coaching with a project manager, Trish. She postponed our weekly coaching call–for the third time. I said, “Trish, are you postponing again because you have too much work to do?”

“Yes!”

“Then I suggest we carve an hour out of your day sometime sooner than next week and determine why you have so much work to do.”

She reluctantly agreed.

When we spoke later that day, I asked her about all her projects. She sent me her spreadsheet of everything she was working on.

“Trish, I see these three projects. They are unique and stand-alone, right?” She agreed.

“I’m confused about these six projects here, and those seven projects there. Are they related to each other?”

They were. The six projects composed Program1 and the seven projects were Program2. Each project in the programs had its own project team, so Trish was trying to manage 13 project teams for the two programs.

How did we decide these projects were really programs? Without the sub-projects, the larger “project” had no value–that is, the organization could not release the sub-projects or the larger “project.” That interdependency of sub-projects to create one valuable deliverable is one definition of program.

A program is a collection of projects that all together deliver significant value. Each project may have some value by itself. But the real value is the collection of projects into one deliverable: a program. You might have a program of a number of subprojects all with one release date. Or, you might have a program of phased releases, where each release delivers some significant value.

Managing one program is difficult enough. Managing more than one plus other unrelated projects is impossible. But the first step is to recognize when you are managing a project or a program.

Once we collected all her work and decided which were projects, which were programs, and the relative progress on each one, we could start solving the problem of how to manage all that work.

Trish was very lucky. Of the three projects, two project teams had been pushing at her to let them work feature-by-feature in timeboxed iterations. She’d never managed a project like that so we discussed how to assess project progress. I assured her that once she saw a velocity chart she could let her Gantt charts go. That’s because a velocity chart shows actual progress of completed work.

She also promised to assign one of the technical leads who had been helping her on each of two teams as the real project manager for those projects. Now we were down to one project and two programs. We discussed the relative importance of the three efforts, and realized that both programs were more important the project–at least, Trish thought so.

I asked, “Can you really manage both programs at the same time?”

“No.”

“Do you have someone you can ask to manage one of the programs?”

“No.”

Ok, so now Trish feels stuck. She can’t do all the work and she doesn’t know anyone else to ask. It’s time to ask for help.

We discussed what she could say to her manager, Ted, so he could see the seriousness of the situation and help Trish with her work.

“First, make sure you know what Ted wants. Make sure he actually wants both programs and this project completed at the same time. Do you know that he does?”

“Um, no. We never discussed the real due date. Everything here is due yesterday. It never occurred to me I had some wiggle room on when things needed to be done.”

“You might not. But you might. Asking ‘when’ might be a big help. If all the releases are staggered, no problem. But I bet they are not staggered, so after the when question, ask which project or program is more important.”

“JR, I know that Program2 is more important.”

“How do you know?”

“It’s obvious.”

I repeated my request for Trish to ask Ted about the relative importance, and sure enough, when we spoke again, the priorities were not what she expected.

“Ok, the priority was not obvious. It turns out that Program1 is more important than anything else I’m doing. Surprised me. I could have sworn that Program2 was more important. And that other project? That’s not even on Ted’s list of things to discuss.”

“Ok, can you stop work on Program2 now, and concentrate on Program1?”

“Yes! If Program1 is delayed, I’ll be in trouble because that will postpone Program2, but for now, I can work just on Program1.”

We discussed how to organize Program1′s work, how to have other people lead the project management on the subprojects, and how to see if Program1 was making progress or was in trouble.

Trish was lucky. Normally managers say everything has to be done–and now! If you want some tips on how to help your manager rank projects, see the next Pragmatic Manager.

In the meantime, if you are attempting to manage 57 gazillion projects, or develop 30 bazillion, or test 92 zillion projects, first think about whether each effort is unique, as a project or if the work is interdependent and is a program. You’ll make different choices about the work you need to do depending on whether this is a project or a program. Sometimes, it’s much easier to see how things fit together when you know you’re managing a program.

Janice strode down the hall and made a sharp right at a cubicle decorated with dragons. “Hey, Steve, got a minute? I need your help with a problem.”

“Janice, the last time you asked me for my help, I got stuck in that installation mess. I appreciate being one of your team leads, but I get worried when you ask for help with problems. What’s going on now?”

“We have a problem with customizations for Big Customer2. The good news is that we do these customizations, right?” Steve nodded. “But the bad news is that we have to port them from release to release.”

“We did that last month.”

“Well, you did. Then tech support decided to add the extra piece of the reports we discussed last month.”

“What? Why did they do that? Not to this product-they can’t.”

“Well, Big Customer2 paid us a pile of money for not too much work. And that’s where you come in. I need you to add that new report to the point release you’re working on now.”

“How much money? I bet tech support has no idea how much this piece of the report will cost us to support or how much time it will take away from our next release. We can’t just think of this report as a pile of money; it’s a headache. We were never going to put that functionality into the product. We were going to put it in the new reporting system, remember? Now we’re going to have to support that report forever. Big Customer2 is never going to want to change.”

Steve put his head in his hands. Finally, he looked up and said, “OK. I’ll do it. But on one condition: We decide what we’re doing as a development group once and for all. You asked me to be a team lead, right?” Janice nodded. “Well, I don’t know what I’m leading. Let’s decide what our mission is-whether it’s to support any crazy thing our customers want, or make products, or support installations, or what. Let’s define our mission and write our mission statement. Then we’ll have a basis on which to say no to new work if it doesn’t support our mission. From now on, we will have a reason for the work.”

A week later, Steve and Janice met to develop their mission. “Steve, I invited Chris so we have all you technical leads in one room. Since you prompted me to think about the mission for our group, I decided to ask my boss for his mission, as well. He doesn’t have one yet, so we may have to revise ours later. But at least we’ll know where we’re going.”

Janice placed two lists on the table. “Here’s all the work we’re doing in development. One list is a month-by-month portfolio of all of our projects and all the extra things I’m supposed to do as a manager. This other list is the work other people would like us to do that we’re not doing. Now, do you two have work you’d like to be doing that’s not on this list?”

Chris and Steve nodded.

Janice handed them a stack of index cards and said, “OK, let’s write all the work we’re doing and the work we’d like to be doing, one project to a card. We’ll organize them on the table into these buckets: work that seems to make sense for our group; work that needs to get done, but maybe not by us; and work that we are doing but we don’t understand why.”

After a few minutes, Janice, Chris, and Steve had their cards sorted. Chris said, “Wait a minute. Why are we looking at the work? Why don’t we decide on our mission first and then manage the work?”

“Good question,” Janice said. “Since my manager doesn’t know his mission, yet, I’m not sure we can finalize ours beyond the work we do. Clearly someone in the company values our work, so we have to make sure we continue to do work the company values but that also makes sense for us to do. By starting with an analysis of our work, we’ll have a basis for our decisions-especially when we start looking at the work we’d like to be doing that we never have time to start.”

Janice, Chris, and Steve discussed their work, bucket by bucket, starting with work it made sense for them to do.

Next, they discussed the work that they thought the company needed to have done-but not necessarily by them-and put a sticky on the card with the name of the group that they thought should do the work.

Finally, the trio discussed the work they didn’t understand why they were doing. Janice wrote a sticky with the name of the person she was going to talk to about those projects.

“Now that we understand our work and the reasons why we have it, let’s discuss our mission. A good mission explains what we do and don’t do. It establishes the boundaries of our work and explains how our development group fits into the organization. A great mission will provide reasonable and measurable objectives for our work so other groups can see what we are responsible for-and not responsible for,” Janice explained.

“Oh, so I don’t have to add something impossible such as, ‘Respond to all requests in twenty-four-hours’?” Chris asked.

“No, that’s how we got into trouble with Big Customer1 last quarter, remember?” Steve said.

“You know, if we were a custom development group, responding to all requests in twenty-four hours might make sense. But we’re not!” Janice said. “Let’s develop a mission that makes sense for us, and I’ll talk it over with my boss. I’ll convince him our mission is on target.” Janice grinned. “But if he doesn’t agree, at least I’ll understand what he wants us to do differently.”

The three of them worked for a while, until they were satisfied. Janice said, “Read the mission out loud, Steve so we can hear it.”

“We will enable our customers to organize and see their data by creating products that our company can sell. We will continue to extend each product and family of products so the products provide a cost-effective solution to our customers’ needs.”

“OK, with this emphasis on products and product families, as well as cost-effectiveness, I now have ammunition to say no to more of these customizations,” Janice said. “Maybe my boss will think about his mission instead of just saying yes to everything that he sees. But if not, we can use our mission to set some boundaries for what we do and what the company does. Thanks, guys.”

Story Lines

1. Without a mission, you can’t define the work that belongs in your group and the work that doesn’t belong.
2. A mission should say what you will do and help you explain what you won’t do.
3. Beware of missions that promise immediate response or continuous response to the organization unless you do have a 24/7/365 organization and the staff to support that service level.
4. It’s easier if your manager has a mission, but if your manager doesn’t, start with the work you do (and want to do) to generate your mission. Be ready to revise your mission when your manager develops his.

Acknowledgments:

I thank Dwayne Phillips and Esther Derby for their review.

This article was previously published on stickyminds.com

“My company has decided to transition to agile after the team and I started this project,” Gina complained. “I know what agile is, but I still don’t understand how I’m supposed to transition my active, waterfall project to an agile project. I understand how to start a project in an agile way, but what can I do after a project has started? My managers don’t understand what’s going on. My team doesn’t understand either. I feel as if I barely understand. What am I going to do?”

Here’s a solution: Start by helping your team find a project rhythm and finish pieces of functionality. If you’re trying to transition in the middle of your project, follow these three simple steps to ease you into agile:

1. Establish timeboxes.
2. Finish partly done work.
3. Build a dedicated cross-functional team that includes developers, testers, writers, business analysts–anyone you need to create a product in its entirety.

Decide on the Length of the Timebox

The timebox helps the project team focus on the work they need to complete in a given time period, so they’ll need to estimate how much work they can finish in this time. Most people don’t have a lot of experience estimating, and estimating for the entire team can be tricky. A good rule of measure is the shorter your timebox, the less the team has to estimate, and the faster they get feedback on their estimates.

Make sure your timeboxes are no longer than four weeks. Any longer, and people can get stuck in “student syndrome” (putting off work until just before it’s due), or they overestimate what they think they can complete.

Start with a short timebox–no longer than four weeks. This short timeframe makes people feel the urgency of the timebox and teaches them to break work into smaller tasks. You’ll see tangible progress from day one. But be aware that for some teams, even a four-week timebox can be too long.

Gina started her team with four-week timeboxes. When the team couldn’t finish the features they estimated they could, she went to three-week timeboxes–but that was no better. When she shifted into her first two-week timebox, a tester confessed, “I really need you to tell my manager to stop assigning me to other projects because I can’t do those and finish what I need to do here.” Gina said it would be her pleasure.

When people work in timeboxes, they cannot work on two projects. As Gina’s team discovered, forcing people to work in short timeboxes exposes some of management’s misconceptions about how people need to work to be productive.

It wasn’t just the tester’s management who was unclear on how agile works; everyone was confused. Some developers thought they were done with their pieces as soon as the code compiled on their machines, without checking that the code worked across all platforms. One particular developer thought the idea of ensuring that his code worked on all platforms every time that he checked in a change was a “waste of time.” Gina asked him to track his time for an iteration and promised to discuss these concerns with him at the end of the timebox.

Gina had data on how long it took the other developers and testers to find and fix problems that arose from not checking the code against all platforms as the developers developed it–about twenty-five hours to find and fix problems. The developer spent about five hours during a two-week iteration to make sure his code worked on all platforms. Once the developer saw Gina’s data, he acknowledged that it made sense for him to make sure his code worked everywhere before checking it in.

Moving to two-week timeboxes also exposed the issues that prevented the team from completing its work. For example, the shorter timebox made it impossible for the testers to work on Gina’s project and other projects simultaneously. Gina knew she had to convince her management that she needed the testers on her project full time. The transparency of the issues allowed Gina, management, and the team members to resolve their problems.

Finish the Partly Done Work in Order of Value

If you’re in the middle of a project and you’re transitioning to agile, rank the partly done features by the value you expect them to provide when it’s complete. First, develop the most valuable feature to releasable quality. Then work down to the least valuable feature.

Gina tried to rank the features for her product manager, but she made the mistake of ranking the features based solely on the project team’s input. When she presented her product backlog of partially completed features, he told her she was wrong–he needed things in a different order.

Of course, it made more sense to finish some features first because of the way the team had started to implement them. Once the product manager understood this process, he agreed that some features–ones not that important to him–should be finished earlier than he wanted. As he explained his feature ranking, the project team gained insight into why it was important to finish some features earlier than others. This discussion about value was critical to the project team’s understanding of what it meant to finish a feature. In the past, the team had been successful with partially implemented features in the major release and would finish the features in a point release. But once the product manager explained what he needed from certain features, the team understood what it would take to complete the feature.

When I say finish, I mean doing whatever is necessary within the timebox to reach a level of quality where a feature can actually be used by a customer. At a minimum, this means the feature has to be tested. You might need some documentation, such as help documentation. You might need some examples. Whatever you need, a feature isn’t done until it’s usable.

If you don’t have a product manager, check with your customer or product sponsor–someone who knows what features the eventual customers will want and in which order. If you have no one, ask yourself why you’re doing this project. This is where a lot of teams trip up in their transition to agile. Your team might be like Gina’s, where the testers weren’t originally full-time on this project, and they had no automated tests from previous releases. When the testers and developers worked together uninterrupted, they created a series of automated, system-level tests. In addition, the developers created unit tests so they would know if they were breaking the code as they finished each feature.

Gina’s team did not have 100 percent automated system tests, which made testing during the timebox quite difficult. The lack of test automation prevented the team from reaching a velocity they thought they could because they kept adding tests to the backlog. This issue arose during an iteration’s retrospective, and the team decided to tackle the problem so they could actually release the product. For the following iteration, some of the developers created a framework the testers could use to automate most of their tests.

By the time they finished all the in-process work, the product manager told them they could release–a surprise to the entire team. Gina was convinced it was luck because they had not ranked the entire product backlog, just the in-process work. Regardless, she was willing to take luck.

Make Sure You Have Everyone You Need on the Team

At first, Gina wasn’t aware that her testers and writers were attempting to multitask on several projects. The problem surfaced when the team moved to shorter timeboxes, and no one had time to postpone work.

Gina held a meeting with all of the managers and asked, “Do you care when we release this product?” Each person cared. “Do you care if we release it on time?” The unanimous answer was yes. Gina explained that their only choice was to keep everyone assigned to the project on it full time–no multitasking, no context switching, no quick interruptions.

One of the test managers asked, “But how do I staff all my projects?”

Gina said, “You don’t. If this project is more important than the others, you staff this one. You don’t staff all the projects.”

The test manager replied, “But I don’t have enough people for the other projects.”

Gina was tempted to say “tough” but realized that wasn’t a career-enhancing move. Instead, she said, “Look, you folks told me this project was critical to the company’s success. If it is, we staff this project. If we have too many projects critical to the company’s success, you folks have to decide which ones really are critical. But if you want me to run this project in an agile way, you can’t pull anyone off or ask them to work on more than one project at a time. They either work on this project or they don’t. This is a binary decision. The team can’t estimate what they can do nor can the project succeed if they have to work on more than one project at a time. Now, if you really think we have two critical projects and we need these people to work on both, we can alternate timeboxes to work first on this project and then the other. But I bet we don’t really have two critical projects.”

The managers discussed this loudly and long and finally agreed with Gina. If they assigned people to her project, they would not ask those people to work on other projects.

A Relatively Happy Ending

Gina and the team successfully delivered their release, just a month after the senior management’s requested date. They had never delivered anything that fast before and with as few defects. However, the team was tired. Instead of maintaining a sustainable pace, they tried to add overtime to their last three timeboxes. Not only was the intensity of the work in the timeboxes something they’d not encountered before, they also realized adding overtime was nuts because it came at a high cost.

Some people left the company to work where the intensity was lower. But a funny thing happened. Gina started receiving resumes. Since she wasn’t a hiring manager she forwarded the resumes to HR, so they were able to replace the people who left.

When Gina’s boss told her to take over another project in mid-stream and “convert” it to agile, she said, “I’ll restart it as an agile project. I won’t start in the middle again. And I want some outside help if I have to do this with a new team again.” She got it.

Transitioning to agile in the middle of a project is difficult. As a project manager, you have to learn to work in timeboxes, help the team plan just enough for a timebox, and resolve obstacles quickly. Management may still ask for a Gantt chart even though you don’t need one.

If you’re a developer or tester, you need to collaborate closely with your team to accomplish “done” for each feature. If you’ve never worked feature-by-feature before, this can be quite difficult. And while the timebox helps you stay focused, the intensity of the timebox might be different from how you are accustomed to working.

Moving to agile and seeing how the whole product comes together before the end of the project is a reward in itself. Try it.

Acknowledgements:
I thank Esther Derby, Tobias Fors, and Don Gray for their review of this column.

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.

This article was originally published in Diamond Harvard Business Review, May 2003.

- I’m so busy, I barely have time to think. I don’t have enough money to hire on someone full time, but I’d like to get off the merry go-round.

- I wish I had more business.

- How can I take on jobs with more challenge?

- I’m lonely. I don’t want to keep working alone.

Consultants have problems like these all the time: living through the feast/famine cycle, inadequate knowledge to take on new work, and loneliness. If you’re suffering through any of these problems it’s time to consider changing how you collaborate with others.

Collaboration can take many forms:

• Refer other consultants
• Write with another consultant
• Present with another consultant
• Refer a consultant for a fee
• Work with one other consultant
• Create a consulting partnership

Review the collaboration steps and see where you can improve your collaboration to create an even more healthy consulting business.

Refer other consultants
Make a practice of referring other consultants to perform work you no longer perform. When I started my business, I taught test and development techniques to technical staff. I now focus my business on project management and people management, so I refer the testing and development work to other consultants.

Refer work you no longer perform, even if you’re desperate for money. A colleague, Fred, had this story:

“I had a slow period, and at the end of three months, I was worried about making the next mortgage payment. I took a contract to develop a system like some I’d developed as an employee. My first mistake was taking a full-time contract. Without making time to market, I couldn’t find new clients. My second mistake was taking development money instead of management consulting money. This client refused to hire me later at my management consulting rates because I’d performed development work.

What I didn’t realize was that I could have suggested a good contractor or offered to manage the project for them. If I’d done that, the client would have seen me as a management consultant. As a management consultant, they wouldn’t have expected me on site for a full workweek. I would have performed the consulting I enjoyed, not the development work I did to put food on the table. I wish I’d thought of more alternatives.

I don’t work for that company anymore, because they don’t believe I’m a management consultant. I can’t seem to break them of their initial impressions. I don’t use them as a reference. When the current management leaves, I might be able to consult to them, but for now, I cut off a client by taking work at a lower level.”

Fred violated most of Weinberg’s Laws of Marketing :

1. A consultant can exist in one of two states; State I (idle) or State B (busy).
2. The best way to get clients is to have clients.
3. Spend at least one day a week getting exposure.
4. Never let a single client have more than one-fourth of your business.

Fred had more alternatives to taking on the development work. He could have:

• Recommended a fellow consultant to the client for no money
• Suggested that he take over the project and run it for a fee
• Coached the people performing the work
• Referred the work to someone who wanted the work and received a finder’s fee

If Fred had suggested another consultant for the work, he would not have made any money just then. However, he would not have been too busy to market; he would have had time to obtain more exposure; and he would not have allowed this one client to have all of his time.

Referrals help you build your network. Clients respect you more when you define which work you will perform and which work you won’t perform. When you are helpful with clients and refer them to others, you are consulting—just not for money now. The money will come later.
Consultants give advice. Some advice we give for ?free,? such as when we speak or write publicly, or when we refer. But when you offer limited free advice, such as referring other consultants, you make life easier for your clients. They will remember and ask you to consult for money later.

Fred learned this painful lesson, and during the next slowdown, he contacted everyone in his network. He talked to some of his best clients, asking them about their business, suggesting books and papers to read. He noticed when local associations put on programs that were of interest to his best ten clients even when other consultants were speaking, and let them know about them. He became a resource, and after only two months of “free” advice, Fred landed his largest consulting engagement yet. His client said, “You know our business and our problems. We know you have our best interests at heart. We want you to help us solve these problems. With your connections, we know you’ll do a good job.”

Referrals help your clients see that you have an active and substantial network. A consultant with a large network is an asset to a client. Referrals create immediate business for others. The people to whom you refer work will remember you and refer other work to you, increasing your network and reputation.

Discretion counts when it comes to referrals: a large network by-and-of-itself isn’t always an asset — anyone can say they have a “large network.” What matters is knowing when and how to use it to add value to the client rather than adding value to you.

Write with another consultant
Once you’ve created your reputation, try writing with another consultant to explore a subject in different ways. Once you’ve explored the subject, you’ll know how you’d like to work with this person again.

I wrote an article with Karl Wiegers about project retrospectives . Karl and I have completely different writing styles, so it was both pleasurable and frustrating to write together. Pleasurable for seeing how the article became a combination of both of us. Frustrating because we don’t approach writing the same way.

However, the benefits of writing the article with Karl were:

1. We learned how each other writes. If we ever choose to write together again, we’ll both know to write better faster.
2. Each of us brings a different readership. By sharing my readership with Karl, and with him sharing his readership with me, we each gain an entrée to a different potential client base.
3. Each of us had specific perspectives on the topic. During the writing, we each learned from the other, to provide better retrospective services to our clients. If we ever chose to facilitate a retrospective together, we could provide a rich environment for the client.

I’ve written with other consultants. I’m in the midst of writing a book with Esther Derby about making the transition to management. Our writing collaboration has resulted in a more thorough exploration of the subject matter and in better consulting for our clients.

Present with another consultant
I enjoy speaking even more than I enjoy writing, so I’ve chosen to collaborate with Esther, Naomi Karten, and Elisabeth Hendrickson on speaking and workshops.

Collaborating with Naomi helped me bring more humor into my speaking. Naomi combines humor effectively with her message (in both the presentation and handouts), so I was able to learn how to observe her lightheartedness and adapt her style to my speaking and workshops.

When Elisabeth and I decided to collaborate on a workshop, we chose a subject (communicating with management) that we’d each written about and presented before our collaboration. Because we each had significant knowledge and experience about the topic, we were able to incorporate interactive activities in the workshop. The attendees loved the workshops.

When Esther and I developed and presented our first public “Making the Transition to Management” workshop, we learned how we each develop material and how to integrated our different speaking styles. Our attendees tell us that they appreciate our different perspectives and styles. They learn something different from each of us. Esther and I have presented many presentations and conference tutorials together. Since we trust each other and know how to work together, we’re comfortable and can be spontaneous with each other and the audience.

I learned these lessons from my collaborations with Esther, Naomi, and Elisabeth:

1. The other consultant has a valuable perspective I can choose to share with the audience. I can acknowledge it and explain when that viewpoint is useful when I’m presenting with the other consultant or at another time.
2. Presenting with others requires more presentation design, role clarification (who does what when), and practice. It’s worth it. The audience loves seeing multiple perspectives on the same topic.
3. I learned alternative techniques to explain concepts and integrate humor into my presentations. Since presentations are part performance and part education, I’m a better presenter for it.
4. Each consultant can reach more people together than they can separately. Especially if you’re considering presenting public workshops, you can more easily acquire the minimum number of participants when you speak with another consultant.
5. Working with new people keeps me fresh, and nothing works better than positive energy in front of an audience.

I learned a different lesson from presenting with another consultant, Jerry Weinberg. At the first AYE conference, my co-presenter was ill. Jerry filled in and gave me the support I needed to create an outstanding experience for the participants. Our presentation was different from the original planned presentation, and it was just as good. I gained more self-confidence from that presentation, and have since asked Jerry to review other presentation designs.

When you choose to write or present with another consultant, choose someone who complements your expertise. Discuss how you’ll develop the material and who’s responsible for what (initial editing, article submission, presentation submission, and so on). Then have fun!

Refer a consultant for a fee
There are ways to make money while you work with other consultants. One technique is to refer business to another consultant and charge a finder’s fee, a referral fee.

When you recommend people, you recommend for free. The client is free to take your advice, and the other consultant is free to reject the engagement. You have no obligation to the consultant or to the client, aside from wanting to see the client happy with your recommendation.
When you refer for a fee, you’ve defined an engagement between you, the client, and the consultant. You’re not employing the consultant, but you make money every time that consultant works for that client, depending on how you’ve arranged the agreement.

It’s possible to have a successful consulting referral business. I’m listed with a local Boston-area consulting referral group, the Consulting Exchange, www.cx.com. Geoffrey Day, the owner, does not charge the client for the referral. Instead, Geoffrey takes a percentage of the fee for the specific referral. When the initial engagement is complete, Geoffrey takes a smaller fee for ongoing business for up to three years.

Geoffrey has set up his business congruently, taking the client, the consultant, and his needs into account. His fees are fair. His fees from ongoing work from the initial engagement have an end-date. Geoff realizes that the more consultants he has in his network, the more money he can make with his referrals. If he tries to gouge his consultants, or have them work forever for a substantial fee, he will win the contract and lose the business. Geoff has chosen to make money over the long term, by developing ongoing relationships with consultants and clients, treating each fairly.

Day does something else that few do: consultants set their own rates, working directly for the client. And he works only on specific projects, making sure that the consultant retains flexibility for existing clients and that crucial marketing time. This attracts a better type consultant and eliminates many problems common with agency type referrals.

The CX and organizations like it can also help you enhance your own business. While we all have active networks, it is common to run into a situation where you don’t know the right person. Maybe you are in a new city, working in an industry where you haven’t a lot of contacts, or just not happy with your immediate network.

If you choose to set up referrals for your business, make sure you’ve considered your short-term and long-term profits. A consultant who was referred by another referral company had this experience:

“I’ve been on contract to this client for over a year. They still need me, but I’m not being paid enough. The referral company increased the rate they bill the client, but the referral company took my entire raise. I can’t keep working for these idiots. If I quit, I can’t go back and work for the client, or even talk to them for two years. Because I’ve been working full-time, I haven’t been marketing. I can’t keep working like this—it’s slavery.”

This consultant made an innocent mistake—signing up with an unethical referral company. If you choose to refer consultants and make money from their client work, here are some guidelines for success:

• Be fair to everyone. Don’t be greedy. Set up your fees so that you encourage each client and consultant to work with you over the long term.
• Charge a small enough amount that the consultant will want to continue working with the client, and not drop the client if a more lucrative engagement comes along. If you’re underpaying the consultant, they have no incentive to complete the work, especially on a long-term contract.
• Place a limit on the time a consultant can work with the client and still owe you a referral fee. You may have made the initial introduction, but after a few years, the client and consultant have maintained the business relationship without you.
• If you bill the client, pay the consultant on time even if the client hasn’t paid. If the consultant bills the client, make sure you see a copy of the invoice so you know that you’re being paid according to your agreement.
• Build this into the legal agreement: Make sure that when it’s time to change the fee, everyone has to agree to the fee change.
• Make sure a lawyer looks at the agreement and that the agreement is fair to all.

In my business, I choose not to make referrals for a fee. I leave that to the professionals whose strategic direction for their companies is referrals, like Geoffrey Day.

Work with one other consultant
Instead of referring for a fee, I prefer to either recommend other consultants to the client without charging a referral fee, or to accept the consulting engagement myself and collaborate with another consultant.
When you work with another consultant, make sure you avoid these traps:

1. Taking care of another consultant.
2. Creating a master/slave relationship with the other consultant.
3. Ignoring early signs that your styles don’t mesh.

John’s client wanted John to teach more students than John could teach in a workshop. John explained that the client could either have two workshops or one workshop with two instructors. The two-instructor workshop would cost the client a premium over the cost of two workshops. The client agreed, and John asked a colleague, Jack, to co-teach. Jack asked for half the entire workshop fee. John agreed — a big mistake. John had completed the initial marketing and selling work—without which Jack would not have known about the project. Additionally, John provided extra services to the client (organizing the workshop, making all the handouts, and billing the client) and to Jack (initial workshop draft, already-proven exercises, billing the client and payment to Jack). By the time John was done taking care of Jack and the client, John was exhausted. John was resentful of Jack, because John had taken care of everyone except John.

Unless you and the other consultant come to the negotiation with equal investment and abilities, don’t split the fee 50-50. If you’re the consultant managing the client, the billing, and the intellectual property, you deserve more than half the fee. Don’t leave yourself out of the list of people to take care of.

On the other hand, you needn’t create a master/slave relationship with a consultant. Early in my career, I agreed to perform an assessment with another consultant as a subcontractor. The primary consultant was concerned with my work, the time it took, and the results. He was even more concerned when the client appreciated my part of the assessment more than his. I had discovered the key piece of information in one week. The primary spent four months and had not discovered the key necessary for the client’s success.

The client asked us to help implement the changes based on my report. Even though I requested a change in fee, the primary consultant was unwilling to increase my fee. The primary paid me after he was paid. Since the client paid late, I was in the position of reporting to someone who didn’t understand the problem, paid me inadequately, and paid late. I finally decided to end my relationship with the primary consultant.
Fortunately, I did not have an agreement with the primary prohibiting me from working for the client. I explained to the client that I was not continuing to work for the primary, that they could choose to hire me by myself, they chose to.

I learned these lessons from that engagement:

• Negotiate each phase of the engagement separately. It made sense to have one fee for the assessment and for me to adhere to the primary’s style of reporting. It did not make sense to continue the same fee arrangements and reporting into both the client and the primary contractor when I was working independently after the assessment.
• If one consultant is billing the client, make sure the client understands how quickly they have to pay. In addition, set expectations for subcontractor payment.
• Make sure all parties believe the arrangements are fair. The client was unhappy about having to pay money for pieces of an assessment that were not useful. The primary was unhappy because his work was seen as second-rate. I was unhappy because my fees were too low for the ongoing work and I had to wait for the primary to bill the client.
• I hadn’t recognized the early indications that the primary consultant on the assessment was a controlling personality. If I’d paid closer attention to the pre-engagement activities, I would have recognized the signs, and managed our collaboration differently.

To create a successful collaboration, discuss the fee arrangements early, and decide how you’ll leverage each other’s network.

Discuss fee arrangements early
To create a successful collaboration, discuss who is responsible for which pieces of the engagement before you start the engagement.

Weiss has a formula for revenue sharing that divides the sale, development, and the delivery of the project into thirds, and assigns relative proportions to each piece. Here’s how one consultant and I used that for one $10,000 engagement:

Sally made the original contact with the client and sold the engagement, so she deserves the total sale component. I developed the material, with substantial review from Sally. We decided to split the development, assigning 75% of the work to me. Then, I delivered the material to the client alone. If either of us receives follow-up work from this engagement alone, we own the follow-up work.

We could have split the money down the middle, and for this engagement, that would have been close. However, we’re business people. We don’t want to take care of each other, or take advantage of each other. We’re more likely to work together again because the relationship is built on a solid business foundation.

Leverage each person’s network
In this example, Sally’s network provided me the introduction to a new set of potential clients. My material offers Sally the chance to sell different kinds of consulting to her clients. Sally recognized I could provide a particular value to her clients, so she brought me in to perform a specific task. We both win—Sally learns how to perform another piece of the consulting, and I have access to new clients. In this case, Sally’s network is as much of an asset to me as the consulting work is to her.
When you create a congruent relationship with the client, the original consultant, and the additional consultant, everyone wins. If you ignore one piece of the relationship, it’s not sustainable, and will dissolve to everyone’s detriment.

Create a consulting partnership
If you’ve worked with a consultant on a contract or two and enjoy it, maybe it’s time to create a partnership. Avoid employing anyone who’s not a partner—non-partners are overhead that you provide for, not someone who adds value to the business. Partners bring complementary strengths and an additional client base to the business.

If you’re considering a partnership, use this checklist to make sure the partnership is appropriate:

• You trust this person with any of your clients
• You trust this person with your intellectual property
• This person has already succeeded independently performing the work they’ll do as a consultant
• If you’re already consultants, the other person has already succeeded as a consultant
• You have the same goals, including financial goals, for your business
• Together, you are worth more to a client than you are apart

The principals, Donna Johnson and Judi Brodman, formed a partnership, Logos International, about ten years ago to perform research for a government contract. Donna and Judi had each worked independently as consultants before they formed a partnership, and had worked together in limited engagements. They found that they could offer more as a partnership than each could alone. The partnership benefited them in these ways:

• They enjoyed having another person available to discuss ideas
• They could create other products based on their original work together
• They were able to bring their current clients more value
• They were able to bid on larger projects because they had more depth to their company

Donna and Judi were already successful consultants when they chose to create a legal entity to work together on projects for their clients and enjoy their partnership of equals.

I know of two other long-term successful partnerships. Both partnerships started when the people who’d performed the work inside companies chose to continue working outside their original employers.

One partnership, Process Enhancement Partners, Inc., started with two principals who had not been consultants originally, and added two more principals after a couple of years. The original principals realized that one of the two people did not have the same goals. The consultant with different goals left the partnership.

The other partnership, Process Group, periodically reviews their business — to make sure their individual and group activities continue push their strategic goals. They considered taking on employees to grow their business, and then decided against it. Adding employees would grow the company, but would not help them meet their individual goals of being able to provide services themselves to their clients.

Each of these partnerships has people with different strengths. Each partnership developed and continues because the principals have common business goals and a common work ethic.

When you create a partnership, decide if and the conditions under which each of you can take on work alone and how you’re going to dissolve the partnership, like a prenuptial agreement. If nothing else, one of you may want to retire. If so, what does that mean to the partnership?

Summary
Collaborating with other consultants helps you increase your expertise as well as your client base. Referrals help you maintain and grow your network. Writing and speaking helps you access other potential clients, as well as increasing your expertise.

When you refer others for a fee, or work with another consultant, remember to clarify who’s responsible for what, the compensation each of you receives, and when the arrangement is complete. When you’re ready consider a partnership arrangement to continue to capitalize on what each of you can bring to the client and the business.

None of us works entirely alone. Consider which options you want when, and your collaboration will provide you and your clients excellent service.

Acknowledgements
I thank the following people for their helpful review: Geoffrey Day, Esther Derby, Elisabeth Hendrickson, Naomi Karten, Jerry Weinberg.

References

Weinberg, G. M. (1985).
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully.
New York, Dorset House.

Weiss, A. (1998).
Million Dollar Consulting: The Professional’s Guide
to Growing a Practice.
New York, McGraw Hill.

Wiegers, K. a. J. R. (2001).
Looking Back, Looking Ahead.
Software Development. Feb 2001.

Have you ever had a conversation like this one?

Vice President: In the last release, you were able to bring the release date by over a month by cutting the testing. Do that again, ok?

Project Manager: Sorry, boss, we can’t do that. For the past three releases we’ve shortchanged the design work and the testing. We can’t cut any time from this project. In fact, it’s time to re-architect the system, redesign it, and do the testing we’ve put off.

Vice President: NO WAY!

Project Manager: Hey, that’s just the way it is. We haven’t taken the time to finish this product yet, and our shortcuts have come home to roost. Our technical debt is too high to work this release the way we’ve worked the others.

Technical debt, as defined by my colleague Dave Smith, is the debt a company “owes” to a product they persisted in shipping in an incomplete or unstable condition. This is a situation referred to in Hunt and Thomas’s book The Pragmatic Programmer as “software rot” or by Gerald M. Weinberg in Quality Software Management, Volume 4 as “design maintenance debt.” The software isn’t necessarily rotten—the product is incomplete.

As the technical debt increases, the load on the customer support staff becomes overwhelming, and the developers have trouble adding or changing system features. When developers are stuck on new development and support is overloaded, you face difficult choices about what to do now: have developers support the current product; ignore the current product and continue with development; some combination of support and development; or stop developing and fix what you’ve already got.

Project managers, development managers and test managers often can see this coming. They know there is a window of opportunity to fix the product before the technical debt overwhelms the company’s ability to do new product development.

Look for these signs of technical debt:

• You ship a product and then have to put out a point release before it’s even left the CD duplication house.
• Testing time increases disproportionately to the development time.
• The developers tell you that part of the product needs to be re-architected, because the current architecture doesn’t support the current requirements, never mind the additional requirements.
• Developers refuse to touch a part of the product saying, “No one but Fred can touch that. I know Fred left three years ago, but no one else can work on it, because we don’t understand it.”
• Developers spend more time supporting current customers by solving customer problems, fixing defects, and answering customer questions, than they spend developing new product.
• You hire more testers than you have developers, and you’re still not sure you’ve tested the product.
• Your developers threaten to leave because all they do is “maintenance”.
• You ship the product not because it’s ready, but because the developers’ families have abducted them to go on vacation, or the developers are too exhausted to continue the crunch mode you’ve been in.
• You stop testing because you don’t want to find more defects.
• Your cost to fix a defect continues to increase, from release to release. (If you’d like to see a picture of this dynamic, check out Weinberg’s Quality Software Management, Volume 4, reference below.

Recognize your technical debt, and start planning what to do. Before you can plan, you need to know a little about how you came to have this technical debt problem. These questions may help you understand how your product acquired its technical debt:

How do you staff projects? Do you assign enough people at the time they are needed, or are some positions never assigned or assigned late to a project? If you never assign enough testers, or you don’t have an architect, you will incur technical debt. Don’t blindly accept people starting on your projects late, because you can’t make up time in a project. Have people start when they’re supposed to start, or recalculate the project schedule.

How do you design your projects? Do you first architect the entire product for its entire lifetime? Do you iterate on the design for several projects? If you don’t architect the product, and update the architecture as necessary, or if you don’t do a high level design before starting to code, you will not have a congruous product. One way to recognize an incongruous product is when you have multiple ways of doing the same thing. At one organization, the developers couldn’t agree on how to open and save data files. Since they couldn’t agree, every time a developer wanted to open or save their data file, they had their own open and save functions. When they moved from a command line interface (CLI) to a GUI interface, they had no easy way to integrate the open and save functionality.

How do you test the product? Do you have a way to start testing the product at the beginning of the project? Do you only have manual tests through the graphical user interface? If you start limited testing late, you’re guaranteeing yourself technical debt. You have many opportunities to test early and often: requirements inspections, design reviews, code inspection or peer review, unit tests, daily builds and smoke tests (tests to verify the daily build works at least a little bit), peer review of fixes in addition to system test. Decide what makes sense for your environment, and add test capability as early in the project as possible.

How do you organize your projects? Do you have functional managers who hand off the product from the analysts to the developers to the testers to the manufacturing folks? If so, no one has the same view of what the product should be. At a minimum, assign an overall project manager or program manager, so someone is pulling the entire project together. Projects without project managers are highly risky, and in my experience, always fail. In addition, projects without a sponsor or champion have a difficult time finishing.

How do you know what done means? Do you have some objective criteria to know when the project is complete? If not, you’re more likely to release an incomplete product. Develop release criteria for every project, so that everyone on the project, and the project sponsor understands what your company will receive for its project money.

How do you run your projects? Do you stick to only one type of lifecycle and one process? You may need to choose other lifecycles and/or processes to avoid future technical debt. Many project managers are comfortable with a particular lifecycle and/or process, and it can be difficult for those project managers to switch to a different lifecycle for a project. If you’re used to a waterfall lifecycle, you’ll have to learn to plan for an iterative or incremental lifecycle differently. And, you’ll have to monitor your projects differently.

If you’ve changed your lifecycle, you may need to change your process. What you do and when you do it will make the lifecycle successful and keep down technical debt. If you’ve never planned when to do inspections and reviews, start with something small, such as peer review of defect fixes during system test. I’ve found that a nightly build and smoke test helps find defects faster, and helps everyone realize when the product is not ready to ship.

Although it feels as if you’re moving faster when you take shortcuts on a project, in reality, your technical debt prevents you from making project progress. You might be able to shortchange your product on one or two releases, but at some point your product technical debt is like credit card debt — if you don’t pay it off in a planned way, the debt buries you.

Observe and measure your products, to know when you should act to reduce or avoid technical debt.

For more information, see

Hunt, Andrew and David Thomas, The Pragmatic Programmer. Addison-Wesley, Boston, MA 1999.

Weinberg, Gerald M., Quality Software Management, Volume 4. Dorset House, New York, 1998.

Meetings are a fact of our lives. Most of the time we don’t need a facilitator to help move our meeting along; we can manage to accomplish the goals of the meeting without a formal facilitator. However, there are times when a facilitator makes sense.

Darcy is a middle manager in a startup. They have enough money for the next eight months. For the last three months, the senior managers have closeted themselves in meetings day in, day out. Darcy knows they’re trying to define the current strategy and tactics to accomplish the goal: drive enough revenue to break even. If they can break even in eight months, their investors will consider investing just a bit more to overcome the slow economy and the company will succeed. If they can’t break even, they’ll be shut down.

Darcy’s no dummy. Neither are the other people in the company. They all know what these closed-door meetings mean. Darcy is concerned that if the senior management team can’t figure out what they’re going to do soon, the meetings will turn into layoff-decision meetings.

Darcy’s management team needs a little facilitation to help them overcome their inability to come to a decision and move forward to specific tactics and action items.

Senior management teams aren’t the only groups who become stuck and need help making decisions. Sometimes, a technical group has the same problem. Desmond, a database developer has on ongoing discussion with George, the GUI developer, and Tina, the tester about how to appropriately design the database upgrade for their product. Desmond, George, and Tina all agree they need an upgrade. They can’t decide how the upgrade should work. Depending on how they choose to implement the upgrade, their work will change, as well as the work the users will have to accomplish. Each of them has different ideas, and each idea is valid. They can’t come to a decision, and they have only a week left to decide.

In both of these cases, well-meaning, intelligent people are stuck. Their normal ways of managing their disagreements are not working.

Consider choosing a facilitator under these conditions:

• When a group has trouble coming to agreement on a strategy or set of actions.
• When you want to be part of the discussion and decision-making. It’s not possible to treat the group fairly if you want to participate and facilitate.
• When you want to explore a previous project (retrospective facilitator) or explore alternatives (meeting facilitator)

You may be able to use people inside your organization as facilitators. Sometimes HR people or others are trained as facilitators. If you’re not part of the problem context or solution, you can facilitate the decision-making.

Whatever you do, choose when you require a facilitator. Don’t let the problems or conflicts escalate into no decisions, especially when you require a timely decision.

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:

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.

Many of the project schedules I review contain milestone completions on Fridays and new task or phase beginnings on Mondays. With a Friday or Monday milestone, what you’re really saying is that people can work overtime all week and all weekend to make the Friday milestone, so they won’t be late for the Monday start.

Why? Why do we do this to ourselves and to our project teams?

It’s convenient to think about project milestones ending on Fridays and new things starting on Mondays. But just because it’s more convenient from a calendar perspective, should we use Fridays and Mondays to end and begin project segments?

I say no. Down with Fridays and Mondays. Let’s end and begin project segments on Wednesdays. Wednesday is a perfectly good day, and one that is possibly underutilized in project planning. Tuesdays and Thursdays are also good, and in my experience, underutilized. Here are the effects we might see if we choose a Wednesday to end a project phase or start a new phase.

1. Improve schedule precision. We would know that our schedule estimations are wrong, and we might know more about how we estimate incorrectly. When we hide the actual milestone complete dates behind massive overtime, we encourage our project staff to inaccurately predict the next schedule, leading to even more overtime. Here’s why: When we schedule project phases to complete on Fridays, we allow ourselves to take the weekend to complete the pieces not quite done on Friday. Completing a phase on Friday really means the phase is complete by the time people get to work on Monday morning. If we don’t complete the work by Monday morning, then we’re honest-to-goodness late. But, if we completed the work on Sunday morning, are we truly late? In reality, yes! We have underestimated the work, and we need to know about that underestimation to improve our estimation the next time. Otherwise, we can continue to underestimate projects by however much we are underestimating them now.
2. Adjust for schedule risk sooner. We would know earlier in the project that the project has a higher risk than we earlier believed of not meeting its release date. The earlier in the project you know that the project is in trouble, the more options you have. At the beginning of the project, you can still add more staff, change tools, drop features, modify your life cycle, change how you work to reduce defects, or choose to allow more defects. In the middle of the project, you may be able to add more staff, drop features, change how you work to reduce defects or choose to allow more defects. At the end of the project, you can drop features or choose to allow more defects. As a project manager, I want to have more options rather than fewer when I’m faced with schedule-related bad news.
3. Avoid hidden overtime. We would have less self-induced project overtime. When we’re in the last couple of weeks of the project, it may make sense to ask people to work overtime. Many people can manage a week or two of overtime and still think carefully and make good decisions. However, allowing overtime for more than a couple of consecutive weeks is a poor management decision. People who work overtime for more than a couple of weeks stop thinking clearly because they’re too tired. Or they don’t have any new ideas because their brains are stuck on the same old ideas. Or they stop paying attention to themselves and their self-care, so they get sick and then pass the disease to everyone else, causing the entire project team to work at less than full strength. When we schedule for midweek milestones, the amount of overtime needed is much more obvious, and we can make conscious choices about how much overtime to use on the project. If you have numerous two-to-three-week minor milestones, and people are constantly working overtime to meet the milestones, you have an entire project of overtime. Constant overtime generally leads to staff burnout and software technical debt.

So if you’d like to see just how close your schedule estimates are, create schedules with milestones ending in the middle of the week. Track how closely you meet each milestone. At the end of the project, look at how much extra time you needed and see if you could have planned your project or estimated the tasks differently to have developed a more accurate schedule at the beginning. Make your project schedules honest and help yourself see the reality of the schedule sooner, say, on a Wednesday.

If you’re like most of my clients, you have too much to do. Recently, an Engineering Director, Stephanie, explained all the things she “had” to do: monitor the projects, participate in the requirements sessions, draw up a yearly budget, write three performance evaluations, monitor training classes, visit customers, assist technical support and more. Some of the items on her list were clearly her responsibility, but others were not. Her not-responsibilities were preventing her from doing her necessary work. Stephanie needed a to-do list and a not-to-do list.

Here are some signs that you need to create a not-to-do list:

• You’re always working overtime.
• You never have time to sit and think.
• You manage crises well, because that’s the only kind of management you ever do.
• You’re the bottleneck for work that’s not getting done on your project.
• Papers sit in your inbox for weeks, and you’re hopelessly behind in your email.
• You take refuge in the technical work because you’re uncomfortable with the management work you’re supposed to do.
• You get depressed looking at the ever-growing pile of paper on your desk.
• Your to-do list is a write-only list; things go on but never come off.
• You are doing more work but your manager is less satisfied with your performance.

Your not-to-do list is the list of everything that’s not part of your job to address or solve directly. Here are some suggestions for creating a not-to-do list:

Clarify your role. Try defining your job description with a one-line sentence. What does your company pay you to do? How broadly are you interpreting that? Should you make it narrower? One Director of Engineering said, “I’m responsible for the care and feeding of the engineers and the product.” He stopped allowing the salespeople and the support staff to lean on his organization, by putting training and other procedures in place.

Work at your level. Check to see that you’re working at the level appropriate for your title. Many people retain pieces of previous work out of habit after a promotion or a reorganization, rather than working at the most appropriate level If you’re now in middle management, think hard about whether you should be doing technical work. If you are doing technical work, who’s doing the strategic thinking?

Make decisions when you add value. When it’s time to make decisions, check a couple of things: are you the right person to make the decision? Are you too tired to think straight? Will you add value to this decision? If you’re the right person to make the decision, clear your head, think the problem through, and then make the decision.

Delegate or manage your paperwork. If you need administrative assistance, or filing assistance, or other paper handling assistance, ask for it. Then, deal with the rest of the paperwork. If you don’t know what to do with your humungous pile, throw the whole thing out. If someone needs something from you, they’ll be back with another piece of paper.As you decide what you should do and not do, don’t just drop things. Explain your decisions, possibly by negotiating with the people affected by your decisions. And when you make your not-to-do list practice living with it for a few weeks. See if other people are working on handling the items on your not-to-do list. If no one’s working on that list, does it matter, or will your project risks increase? If your risk increases, explain which work you’re not going to do to manage the risk.

If you’re working on issues that belong to other people, stop. Draw your boundaries, and make the rest of the people in your organization live up to their job descriptions; don’t just take on more work.