If you have too many simultaneous projects, maybe they are a program? Check out When Your Projects Are a Program and see.

�2009 Johanna Rothman.

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.

Always have an exit strategy.

©2005 - 2009 Don Gray, Gerald M. Weinberg

“The thought that disaster is impossible often leads to an unthinkable disaster.” - The Titanic Effect, The Secrets of Consulting, pg 95

Engelbert, the Software Engineering VP, sat quietly in his office pondering the current state of UberDenke’s next UDCRM release. Slowly he had realized the release wasn’t going to ship on time. There were many more errors than he planned for, and over half of the code had not even reached the testing group.

The more he thought about it, the more he felt trapped. The more trapped he felt, the more he wanted out. The more he wanted out, the more he felt trapped. And around, and around his feelings traveled in a vicious circle of trapped and wanting out. But there wasn’t anyway out.

Or was there? Engelbert’s thinking and actions have trapped him in a reinforcing feedback loop. His feelings are creating an emotional downward spiral that will continue until some system limit is encountered. The system limit may be the when he finally admits to others the release won’t ship on time. Perhaps his health (mental or physical) may break first. Or maybe he’ll change jobs.

We can all sympathize with Engelbert?s plight, because at some time or another, we’ve all been caught like this-a trap artistically summarized by Jean Paul Sartre’s depressing play about three people trapped in Hell, No Exit.

Engelbert set up his own No Exit hell right from the beginning, because he, like Sartre’s victims, had no exit strategy. An exit strategy is a planned set of activities to initiate when one party suspects that a relationship isn’t working, activities that should prevent the situation from becoming a hellish trap.

Dynamic Basics - Getting Started

The no-exit dynamic generally begins when two (or more) parties agree to work jointly on some project. Sometimes the agreement is not explicit, as often happens when the work of one party depends on another party’s output. This joint work could stem from a voluntary relationship (such as co-authoring articles) or perhaps from a management mandated decision. In Engelbert’s case, his manager told him to use a new process to build the next generation of their software product.

The parties start merrily to work under the agreement, and all goes well for a while. Next, life happens.

Perhaps the person with whom you agreed to write an article falls ill, changes jobs, or takes time away from the joint project to deal with pressing family problems.

Perhaps the other team at work discovers the problem is more difficult to solve than anticipated. Possibly another higher priority project siphons manpower from their team.

Or perhaps the dynamic starts up when the levels of commitment and interest are unbalanced, or when there is a different understanding of the agreement.

Locking In

The first slip or two may not create a problem. We use explanations like these:

• It’s only happened one time. (Not noticing prior behavior on the part of either party).
• Things are bound to get better. (Seeing through rose colored glasses)
• I’ve made a commitment, so I’d better not say anything. (The team player problem)
• They’ve got a plausible story. (Just one more chance).
• I’ve already invested so much, a little more investment and I’ll have what I want. (Good money after bad)

Whatever the reason-and there are hundreds of variations-the slips soon become the norm, not the exception. Since the slips happen individually, separated by days or weeks, the cumulative effect isn’t noticed until it’s too late to do anything reasonable about the slips. The more we become accustomed to the slips, the more tolerant we become as new slips occur. It’s not that Engelbert is stupid. It’s just that he lacked foresight, or was too optimistic. If he had known when starting development that the project would slip several times, he could have planned differently.

Failing to take early action sets the precedent for continuing failure to act. Failing to act causes negative feelings to accumulate. The negative feelings are there from the first slip, but they are ignored or suppressed until the accumulated value becomes greater than we can tolerate. When we finally surface the negative feelings, we feel trapped by our previous actions. We’ve become locked in the reinforcing feedback loop of simultaneously wanting out and feeling trapped.

In this dynamic the system continues accumulating more negative feelings until the system experiences a catastrophic collapse. Engelbert may be fired, or quit, or get sick, or ship a system that drives his company out of business.

Setting up the Exit

So, what’s the solution? The first step to exiting the reinforcing feedback loop is to become congruent by balancing the factors of yourself, the other party or parties, and the context in which the dynamic is taking place. Most commonly, in this type of a feedback loop, the other becomes lost. As you try to cope with the situation, you start blaming the other person for the problem, and that only tightens the loop. Responding incongruently like this creates stress and does nothing to improve the situation or help find an exit from the loop.

Becoming congruent allows you to be centered in your actions. Being centered opens a range of responses you can use to change your view, each of which might break the trap. By changing your view of the situation, we can see possible interventions that will change the loop dynamics. Among such interventions are these:

• Changing how you see your contribution to the problem.
• Determining why you feel like you’re trapped.
• Obtaining a better understanding of what you heard during the “agreement” process.
• Bringing in a third party who adds a compensating loop. Sometimes you do this by just letting the loop escalate until someone else is affected, often by not trying so hard on your side. This is an example of:
• Doing the opposite of what you’ve been doing. This personally applies Marvin’s Fourth Great Secret, ?If what they?ve been doing hasn?t solved the problem, tell them to do something else.? The Secret of Consulting, pg 41

Exiting the Loop

No self-reinforcing loop can last forever. Sooner or later, one way or the other, the loop will exit. If no action is taken, the reinforcing loop will continue its downward spiral until some other part of the system collapses:

• Personal health (mental / physical) will deteriorate until the exit happens. (This is breakdown of the self.)
• The interpersonal relationship will decay and animosity replaces the original camaraderie. (This is breakdown of the relationship with other.)
• A third party starts to be affected and intervenes. Of course, this is the result some people are hoping for (if we make enough noise, Mommy will stop the fight). But, you can also encourage it. (This is where the context intervenes.)

Another exit option is to become centered, congruent and work on changing the loop dynamics. The key here is to recognize the No Exit dynamic early, and take corrective action quickly. Your plans and strategies must be flexible. While the goal can be constant (exiting the loop), life continually changes, so fixed plans inevitably become obsolete or, even worse, counter-productive.

When the loop finally exits, there are several possible outcomes:

• An intervention works and the joint effort continues
• The “healthy” participant becomes “sick” and the effort ends due to lack of effort
• One person takes over the entire effort

This applies to multiple party systems (two or more). In addition to software development this could include:

• marriage and other long term interpersonal relationships
• business ventures
• article or book writing
• sports or other activities you are doing “for fun.”

An Ounce of Prevention

Next time, Engelbert should consider prevention interventions. Prevention interventions can be used to prevent the No Exit dynamic from happening in the first place. Or if it starts anyway, they provide an agreement among the parties as to how to handle it-if you like, a meta-agreement, or agreement on the limits of our agreement and what we’ll do when we reach them.

In a crisis, it’s much easier to stop and think if you have provided time in your plan for stopping to think. If you haven’t, one party will say, “Here you tell me that we’re behind schedule, but you’re adding this thinking-bit to the schedule. That doesn’t make sense.” With that easy dismissal, everyone quickly hurries back to their unproductive panic.

Examples of advance preparation of exit strategies include:

• Periodic check-ins
• Gate points where either party can exit the activity, if they’re not perfunctory so you can really exit at these points
• Better understanding and more explicit statement of each party’s expectations, along with a process by which expectations can be modified along with the plans that were based on them.

A well-designed system will set some limits at the beginning, limits that are not vulnerable to a buildup of tolerance.

Third Party Interventions

Most parents have learned some dos and don’ts about what to do when they witness such a no-exit loop. If you find yourself on the outside looking in, you might apply one of these principles:

• Know when to enter (never do unless you’re asked for help, though you can encourage the parties to ask you).
• Prevent damage (whatever that is) to others.
• Decide it’s not your problem and walk away, letting the nature of the no-exit loop take its course.
• Avoid creating addiction (co-dependent) dynamics.
• Avoid using fixes that accentuate the dynamics, unless you want to make it worse so it will crash more quickly or lead to enough pain that the parties will work out their own solution.
• Be careful not to prevent natural learning.
• Look for interventions that remove barriers and/or increase resource states.

Exit Levels

In deciding about intervening, choose which of three Exit Levels you’re seeking:

• First exit is when participants realize how much pain the feedback loop is causing and figure out a way to break out for themselves.
• The second exit is out of the situation (as when the parties concur that the agreement has failed). This may lead to a new agreement, or an exit agreement where they continue the relationship with each other.
• The third exit is where one party opts out of the system by ending the relationship.

Of course, the best exit is the one you have planned for before you ever get started. Unfortunately, there’s a prevalent romantic notion that real relationships shouldn’t need a pre-nuptial agreement. As Engelbert’s boss argues when he tries to set up some exit strategies before his next project, “Thinking of possible failure is negative thinking. It’s just that kind of thinking that guarantees we’re going to fail. Just like you did that last time.”

Of course, the last time, they had no such exit strategy, so their failure was much more costly and painful than it need have been. That’s The Titanic Effect: The thought that disaster is impossible often leads to an unthinkable disaster-”Why would we need lifeboats on an unsinkable ship?”

©2008 Johanna Rothman.

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.

©2006 Johanna Rothman. This article previously appeared on stickyminds.com.

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.

© 2002 Johanna Rothman, www.jrothman.com

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.

This article originally was originally published on www.StickyMinds.com

©2001 Johanna Rothman, www.jrothman.com

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.

©2005 Johanna Rothman

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.

©2000 Johanna Rothman, www.jrothman.com

I was recently driving on some back roads in New Mexico, and saw the sign “Watch for Falling Rocks.” I turned to my husband, Mark, and said “Now, why do they tell us to watch for Falling Rocks? Why don’t they tell us to watch for Fallen Rocks? What in heaven’s name can we do about them, even if we see them?” Mark shrugged and grinned at me. I sighed and said, “It’s a Mystery of Life.”

A few minutes later, I realized that successful project managers watch for falling (and fallen) rocks all the time. They constantly assess risk from all directions, and manage the project’s progress to avoid the falling rocks, as well as other impediments to the project’s success. Some risks you can predict. Other risks you just have to watch for.

I’ve run into falling rocks on projects when:

• A team member discovered her tumor was a pregnancy, and then gave birth within 48 hours of that discovery.
• Two team members broke off their up-till-then secret romance.

My falling rocks have all been unpredictable people issues. I’ve been able to manage explicit technical risks, such as new versions of compilers, databases, or other supporting products. The project teams I’ve consulted with have anticipated those kinds of risks. However, we’ve never fully anticipated the people risks.

Unpredictable risks can turn into disaster, as falling rocks can do when you’re driving on back roads. So, what can you do about unpredictable risks?

Observe the project

As Yogi Berra said, “You can observe a lot just by watching.” Risks, especially implicit risks, don’t have to be a Mystery of Life. If you pay attention to the people on your project, if you observe what’s going on, and how people are working, you have a better chance of seeing the rocks before they land on your windshield. There are a number of ways to observe your project:

Watch how people on the team interact. Are they collaborating in small groups, or are some people working alone? Should they be working together in larger groups? Are the people working in a way that fits the project’s needs?

How do people feel about the project? Are people excited about their work, or are they just putting in time? Sometimes people just come to work to do their jobs although they’re convinced the effort is futile, but since you’re paying them, they’ll keep working.

Are people not talking about the fallen rocks? I’ve sometimes been hired to consult on projects in which rocks have fallen and no one is talking about them. It’s as if there’s a “Cone of Silence” over the project — other people can see the rocks and talk about them, but the project participants can’t. When that happens, people say things like, “Everything’s fine,” but they say it with a sigh or a frown. Talk to the people on your project in a variety of ways: one-on-ones, over lunch, in the project meeting. Listen to what people say and don’t say, and how they say it.

Is someone unable to do his or her project work? Are other people covering for that person? Do some people regularly come into work late and leave early? Is someone taking a lot of sick time, or seeing the doctor a lot? Look for patterns of behavior that suggests rocks have already fallen. There are numerous reasons for people not to do their project work. Discover the reason, or at least keep an open dialogue with the person having trouble.

Assess the damage

What are the effects of what you’ve observed? How bad is it? When two team members broke off a secret romance, they were no longer secret about their hurt feelings. If I’d ignored them, they would have polarized the group, by making their colleagues choose sides. Since the project team was only eight people, the effects of choosing sides would have paralyzed us. I spoke to both of them separately, and explained that I needed them to exhibit certain behaviors at work. We all agreed they couldn’t and wouldn’t ignore their feelings, but they would attempt to work in a professional, if not collegial manner. If I’d worked in a larger company, I might have asked one or both of them to transfer to other projects. However, in a company of 20 people, there was no other project.

Replan your route

When the team member discovered she was pregnant, instead of sick, we were relieved — surprised, but quite relieved. When she started feeling awful and going to the doctor for tests, we talked about her “illness.” She was concerned that she couldn’t do the work we needed her to accomplish, and that I would fire her. Firing her was the absolute last thing I would do, not the first thing. We jointly put together a work plan that allowed her to do the work we needed done at the times she could do it. She took naps, saw doctors, and was still able to do the required testing. Once she had the baby, our current plans went out the window. However, because she’d kept me aware of her condition, I was able to make other contingency plans quickly.

Unpredictable risks, like falling rocks, are a Fact of Life, not a Mystery of Life. If you observe, assess, and replan, you can avoid much of the consequential damage. In addition, as Mark told me in New Mexico, “Honey, maybe I’ll just drive a little slower, just in case there are some fallen rocks or rocks about to fall.”

©2002 Esther Derby, www.estherderby.com

A software project is a complex thing. It involves many players, many tasks, and lots of things that could go wrong (and often do). If not for dogged optimism, some projects might not be tackled at all. But optimism doesn?t mean turning a blind eye to potential pitfalls. In this column, Esther Derby applies a lesson about asking, “What if…”

What could possibly go wrong in your software project? Thinking about what could go wrong identifies potential problems and gives you information to build a more error-resistant plan.

A while back, I decided to wallpaper a small room in my cabin. Even though I had done a lot of home projects, I’d never wallpapered before. But my mother-in-law Shirley is a wallpaper queen. She can do three rooms in a day.

After talking with Shirley, I made a list of materials and tools I’d need and calculated the number of rolls of wallpaper required to cover the room. I estimated that if Shirley could do three rooms in a day, as a beginner, I’d better allow a whole day to do one room.

On Saturday morning, I stopped at the home remodeling store and bought everything I needed and headed up the road to the cabin. I was set. I knew the approach, I had a plan and all the materials. I was confident I could finish the job in a day. What could possibly go wrong?

By Sunday afternoon, I had a rather long list of things that could go wrong:

• Not all the rolls of wallpaper were from the same print lot.
• The color and texture of half the rolls were noticeably different from the other half.
• The water trough for wetting the paste (free with five or more rolls of wallpaper) developed a crack and leaked pasty water all over the kitchen floor.
• Even though I switched paper lots in a corner, if I looked closely, I could see that the colors didn’t match.
• I didn’t have quite the right tool to smooth air bubbles out from under the paper, and in spite of all my efforts, some stubborn air bubbles remained.
• Too much fussing with the air bubbles squished out the pre-applied paste, and the paper came unstuck from the wall.

The list was actually longer. Did I mention that my cabin is two and half hours down a two-lane road from the nearest home remodeling store?

When we design solutions and plan software projects, we tend to plan for things to go right. It’s a human tendency to be optimistic and concentrate on how to get things done rather than dwell on what could go wrong. And I believe our software culture encourages this tendency?how many times have you heard someone say, “Failure is not an option,” “Don’t be negative,” or “Don’t tell me about problems, tell me about solutions”?

We go through stages of understanding the problem?we gather requirements, develop analysis models, and then design software solutions. We develop plans to build and deploy the solution. We come up with a well-ordered set of actions that will lead us logically and inevitably to the goal.

And then we skip an important step. We don’t sit down and think about what could go wrong. We learn about weakness in our plan and design approach as we go. Discovering oversights by running into walls costs money, causes delays, and can compromise quality.

I (now) use a rule of thumb when I approach a new project or design problem: I try to think of ten things that could go wrong before I start. If I can’t think of ten things that could go wrong, I haven’t thought enough.

First, I look for ?lack of? areas where the team doesn’t have experience, knowledge, or information. Then I look for areas where we’re dependent on someone else to provide something-areas where the project team doesn’t have control of a needed component. I look for areas where not all the key players are in agreement. And I look for areas where there’s not enough time to finish a component-or finish with desired quality. These questions help me identify natural areas of risk. I pull out a list of common software project risks to jog my thinking.

Then I start asking “What if” questions:

• “What if we can’t fill those three positions by week four of the project?”
• “What if a competitor releases a new feature and Marketing wants to change our feature set?”
• “What if we lose a key project team member?”
• “What if our design won’t carry the volume we think it will?”
• “What if the vendor code is buggy?”

“What if” questions help me figure out the impact of potential problems and develop contingency plans that will help us meet project goals when something does go wrong.

I look around the organization: How have similar projects fared? What wisdom do other project managers, developers, and testers have to share about past efforts? What’s the history of projects in the organization?

Finally, I ask someone else who has a fresh point of view or someone who has done something similar to poke holes in the plan. This isn’t always fun. When I’m in the throes of enthusiasm over a new project, or think I’ve found an elegant solution, it’s a drag to hear about what could go wrong. Sometimes I just want the other person to be as excited as I am about my neat design. In the long run, though, it helps me come up with an even better solution and develop a more resilient plan to help stay on track when something does go wrong (and it will).

©2005 Gerald M. Weinberg

We hear a lot these days about “reusable programs,” but we seldom hear about programs that shouldn’t be reused. Most programmers know what it’s like to be forced to reuse code that was supposed to be used only once and then discarded, such as:

1. prototypes, as for simple, quick formatting of output
2. one-time reports
3. test drivers and harnesses
4. research programs to probe some peculiar feature of the programming language, operating system, databse, or other “black box”
5. engineering assist programs, to help diagnose a hardware malfunction

These examples generally fall into two categories:

Frequently retained when they should be discarded:
protoypes and one-time reports, and

Frequently disposed of when they should be kept:
test drivers, research programs, and hardware testers.

That is, though all are thought of as single-use programs, the should-be-discarded software tends to be held somewhere, “just in case.” Only the should-be-kept programs are actually discarded.

If the developer is responsible for the decision, the program is likely to be discarded; but if the customer is responsible, the program is likely to be kept.

Developers discard programs because they understand tha reuse is not free. A program not designed and test for reuse, but brought out of hibernation will cost even if no requirements changes are requested by the customer.

1. The hardware environment may have changed.
2. The system software environment may have changed.
3. The size or format of the data may have changed.
4. The human environment may have chnaged, which might, for example, activate a part of the program that has never been invoked before.
5. Some part of the program or its supporting material may have been lost or damaged.

The longer the period of hibernation, the greater the cost - if for no other reason than somebody must check for one of these five conditions. But you already knew this - we all know this. then why, oh why, do we keep tumbling into the same trap?

I believe the answer lies in our unwillingness or inability to feed back the true costs of program development and program maintenance to our customers. Many software development vendors have reduced the problem to manageable proportions by the following steps:

1. When a program is commissioned, the customer must specify the lifespan and the number of executuions.
2. If there is uncertainty about either of these figures, the vendor bids contingent prices, reflecting the differing costs.
3. The vendor offers a contract stating that the program will be destroyed after a certain time and/or number of executions, whichever comes first.
4. The program remains the property of the vendor, unless the customer takes ownership. In such a case, the vendor places a much higher cost on the job - to pay for preparing the program to be maintained by other than the original developers.
5. The vendor notifies the customer when the program is about to be destroyed, and gives the option (at a substantial and realistic price) of rebuilding the program for further use.
6. If the original contract was for a “one-time” program, no notification is required. Instead, the vendor destroys all copies of the program as soon as the customer has accepted the program’s output.

Inexperienced customers readily accept these terms. So do very experienced customers, who know quite well the realities of “one-time” programs that turn out to be “N-time” programs. Only the in-between customers have difficult accepting these conditions, for they believe - incorrectly - that they understand programming.

In-house IT organizaitons - especially where there is no true chargeback for development or maintenance - have more difficulty teaching these lessons. The users pay nothing for specifying a one-time program and then asking that it be run N times. Without cost, they have little motivation to learn. With chargeback, however, in-house IT organizations can do what good, professional vendors do.

If you work in an in-house IT organization without chargeback, however, you can sometimes achieve relief by manipulating your one available parameter - time. You ask the customer to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use. Initially, users simply will not believe you will enforce this procedure, so get it in writing. After a few lessons - if you don’t submit to screams and threats - they will begin to understand the true costs. Only then will they devote some energy to making their initial decision of one-time versus N-time.

In this game,
the only way to win is to stop playing.

(c)2004, 2005 Don Gray and
Gerald M. Weinberg

It may look like a crisis, but it’s only the end of an illusion.

- Rhonda’s First Revelation

The Setup

Sharkey, the sales VP of UberDenke Software Products, firmly believes he needs to have the next release of the UDCRM product in three months. Engelbert, the software engineering VP, estimates a minimum of twice that long - six months - to implement all the new features. During the discussion, Sharkey drops some thinly veiled threats:

• Do you think we need to consider outsourcing this development?
• I wonder why our competitor manages to get software out, but we can’t?
• Perhaps we need to see the company president about the schedule.

Getting the message, Engelbert eventually agrees to “try to get the software done” in three months. Engelbert calls a meeting of the development group leaders and shares the story. “Marketing insists
that we ship the next version of UDCRM in three months. Sharkey already has a quote from an outside vendor, so I had to agree to the schedule. Let me know how we’re going to get this done.”

The developers head to their cubes and start to ponder how they will get the work done in three months. No matter how much they try to shorten their schedule, their estimates range from three and a half to eight months to deliver the next version of UDCRM. Engelbert figures that Pamela’s estimate of three and a half months is close enough to three months, so he shaves off two weeks and declares that as the team’s schedule. He rewards Pamela by making her project lead.

Objectives for Play

In the abbreviated story above, there may or may not be a valid reason Sharkey wants the three-month date. There may be legal considerations (HIPA, EPA, IRS) involved. Perhaps COMDEX is in three months and UberDenke needs to be ready to demonstrate the product. Or maybe a key client has agreed to pay to have UDCRM shipped in three months. Sometimes the “Big Boss” has determined that a date (usually 1 January) is a good day to start using a new system. And just maybe, Sharkey fabricated the date out of pure imagination.

Likewise, Engelbert may or may not have had valid reasons for his initial estimate of six months. Based on the new features and changes to infrastructure, six months could be a valid number - even optimistic. Perhaps previous experiences with marketing have always ended with Engelbert’s estimates cut in half, so this time he doubled his best guess for how long the next release would require.

When Sharkey makes up the needed date, and Engelbert starts by doubling his estimate, they become enmeshed in a Liar’s Contest. A Liar’s Contest is a dynamic interaction arising from a conflict between two people who hold different values for an outcome. The winner is the contestant who emerges from the game with his lie unchanged. The loser is the participant who believes the other contestant’s lie and changes his lie to match. Neither of them is ever forced to tell the truth.

Participants

A Liar’s Contest can happen between the same or different corporate levels as well as between organizations. Sharkey and Engelbert play the game as peers from different parts of the organization. Engelbert and the developers play Liar’s Contest as boss and subordinates. During the competition, one participant generally starts with some type of an advantage over the other.

The participants’ negotiations tend to be zero-sum situations. Winning for one becomes losing for the other. Generally, the interactions between the participants focus on a single value (three months, six months), not a range of values. They never discuss probabilities, even though the future is always uncertain. You can often stop the Liar’s Contest dynamic by creating win-win situations, agreeing on a range of values, or allowing probabilities into the discussion.

And even though Sharkey and Engelbert finally “agree” on a value for the outcome, the real outcome value will almost certainly be something else:

- A miracle happens. No risks occur and the salaried programmers work long unpaid overtime hours, and the product ships on time. This outcome reinforces Sharkey’s original request of three months. “Those programmers! Always padding their time estimates! I KNEW IT!”

- A miracle fails to happen and the product ships “on time” with serious or fatal defects. Sharkey points out that Engelbert agreed to the schedule, so the current mess is his fault. For extra affect, Sharkey can mention that “The only reason we’re not losing more customers is because of the frantic work of the sales staff.”

- A miracle fails to happen and the project ship date slips to six months - or, often, much longer because trying to do a six-month project in three months usually takes much longer than a well-planned six-month project. The product finally ships with minor defects. Sharkey points to lost customers
and lost revenue and blames Engelbert for the dip in quarterly revenues.

It’s interesting to note that in all cases, Engelbert and the software developers are “wrong.” That makes them the losers, but it doesn’t guarantee that Sharkey won’t lose, too. If he’s still responsible for sales, he may suffer the consequences of the failure to produce a miracle.

Choose Your Position

In a Liar’s Contest, one participant usually comes into the competition with one of five distinct advantages:

Positional Given most corporate structures and climates, it’s difficult to argue with a liar from above you who delivers the “Make it so!” ultimatum. That’s why Liar’s Contests often trickle down through several levels of an organization, producing incredibly far-fetched values of estimates.

Negotiation Experience Some people have more experience negotiating, which gives them an advantage when they press for their chosen outcome. They tie into the culture better (”Be a team player”) and have alternate options (real or fictitious) prepared as threats prior to starting the Liar’s Contest. (”We’ll have to go outside if you can’t do it.”)

Interpersonal Skills The ability to understand people provides additional leverage points. We all want to be successful and to feel competent, yet while the feelings are mutual, the participant who first brings them up tends to put the other person on the defensive.

Psychological Strength Anyone who comes to the Liar’s Contest off-center, entwined in other stressful events, or with generally low self-esteem will be at a great disadvantage to a more congruent opponent.

Nothing to Lose The less you have to lose by lying, the more easily you’ll win most Liar’s Contests. Your potential loss involves both the size of the loss if the lie is discovered and the chance that your lie will be discovered.

When a time delay exists between the negotiation and the outcome, it’s possible that neither party (like Sharkey and Engelbert) will be in the same position, or even with the same company when the outcome is
delivered. If the time delay is long enough, or the record keeping is bad enough, nobody will remember the original lie. Perhaps the reason projects keep such poor records of past estimates is that the people love to have Liar’s Contests and not pay the price of losing.

Penalties

After Engelbert and Sharkey have played a round or two of Liar’s Contest together, several different effects may be seen in the long term. Sharkey may no longer accept any of Engelbert’s first estimates - he always pressures for a decrease. Engelbert may compensate by padding his original estimate. Since the “pad” can be negotiated away, the reduction dynamic is reinforced. Engelbert may offer more honest first estimates. This does not change the underlying system, so the personal interactions won’t change. The system goes through another evolution and repeats the previously described activities.
This dynamic looks like Figure 1

Figure 1

If the Liar’s Contest continues to result in reduced delivery times but worse quality, secondary negative consequences appear. The developers will have a reduced view of Engelbert’s overall management abilities. The long hours developers work attempting to deliver the software will result in mental fatigue and burn out, a further drop in output quality (now on a downward spiral to disaster), and interpersonal stress (family life suffers, feeding back to even poorer quality work). If the economy and locale permit, developers will start leaving for greener pastures in more honest environments. Finally, customers may purchase the competitor’s software due to release quality and cycles.

All in all, Liar’s Contests establish the relationships and conditions for bad things to happen, both now and forever more.

Game Over

To end the Liar’s Contest, both parties must realize what is missing in their interaction: the other person and the context of the discussion. In our story, each player in the Liar’s Contest saw only his own role. Sharkey saw Engelbert only as an impediment to his success. Engelbert saw Sharkey only as an obstacle. Neither saw the other as a human in the same boat as himself, nor did either player see himself as just one part of the bigger system. The reality is that Sharkey and Engelbert are both parts of an interconnected system. For Sharkey’s sales to increase, the developers need to deliver a quality product. For client expectations to be easily managed, the sales force has to provide realistic delivery dates.

While early delivery may result in increased sales, these sales come at a cost. Increasing sales may mean more customers, but poor quality software leads to increased support costs. Thus, the company may be less profitable than before. Customers may lose time fighting a faulty product. As support degrades, they tend to switch to a competing product. What both the company and customers need is not software in three months, but software with
sufficient quality as quickly as possible.

When the goal is stated this way, both players can support it. This agreement allows for a number of possible interventions that could end the Liar’s Contest:

1. Include pertinent contexts in the negotiations. If Sharkey explains why the dates are important, it could give Engelbert an opportunity to suggest trade-offs, so they could deliver the most valuable product possible within the time constraints. If Engelbert points out the quality trade-offs that the short schedule forces, Sharkey may see that it could cause customers to choose competing software. Sharkey can then work with Engelbert to find a date that will work for both of them.

Ideally, Engelbert would show the trade-offs by bringing real customers into the discussion, but salespeople who like to win Liar’s Contests generally work to prevent actual contact between customers and developers. If this happens, Engelbert should ask the customers if they want to talk directly with him. If the customers do want to talk to him, Engelbert should ask them to insist on it. He shouldn’t volunteer more than that. Concerned customers will make it happen. If the customers are not concerned about lies, Engelbert shouldn’t be concerned either.

2. Avoid all or nothing discussions. Offer options during the negotiations. Consider a range of features over a corresponding delivery time frame. Say, “If you really need that delivery schedule, here’s a list of functions. Start cutting them one by one and I’ll tell you when you’ve cut enough so we can make the schedule.” Or, if it’s feasible, you might say, “If you give me this and this by such and such a date, then we could make that schedule.” Be sure to ask only for things they can actually get for you - not, for example, promises of “perfectly clean component deliveries.” And be sure to have this in writing, in case they don’t deliver and still expect you to make the date.

3. Say “I don’t know.” Instead of saying “that can’t be done,” Engelbert can engage Sharkey in trying to solve the problem by saying, “I understand what you want, but I don’t know how to give it to you. Do you see something I don’t? Can you show me how to do this?”

4. Let someone else do it. Sharkey might threaten Engelbert, “If you can’t deliver, I’ll find someone who can.” Engelbert may defensively insist there’s no need to go outside, but properly engaging outside help can create the opportunity for the inside developers to learn new software packages, techniques, and skills. Or, if the outside developer fails, the sales organization has a chance to learn more reasonable expectations about software development.

5. Add another information path. Include the company president, developers, customers, or other parties who have skin in the game. Again, invite them to ask themselves in, using their power to get what they want and need. If they don’t want in, then it’s no longer a problem.

Conclusion

Nobody has to engage in Liar’s Contests - unless they enjoy it more than they despise the consequences. Understand the dynamics so you can show other people the consequences of starting a Liar’s Contest. A copy of this article might serve that purpose quite well. It has for us.

< Publication Notice> - A version of this article was previously published in Better Software, May/June 2004

©2000 Gerald M. Weinberg, www.geraldmweinberg.com

As some of you know, a group of consultants are producing a conference for our colleagues and clients. It’s called AYE, for “Amplifying Your Effectiveness.” One of the main goals of this distributed project is to apply our own methods of amplifying effectiveness to the project itself, and thereby to learn what works and what doesn’t.

My first big learnings have been in the area of unplanned delays. The project members are distributed all over the United States, and often travelling from their home base — a situation that’s more than familiar to many Contract Professional readers. I was concerned about the difficulties of conducting distributed projects, but one advantage of this potential handicap is the availability of an email record of what’s happening. So, when I started being aware of delays, I surveyed my email and came up with a list of what had been holding us up and frustrating me.

I suspect the list itself will be a nice reminder to me for future planning, so I also thought it would be useful to many Contract Professional readers. After laying out all the delays and what we’re doing about them, I’ll present a few general principles that might also be helpful to others:

1. One project member’s email is somehow delayed in cyberspace for 2-3 days, without anybody knowing it. The result is messages arriving in the wrong order, and producing confusion that produces more confusing messages. We vow to notice dates on email.

2. Rick’s color monitor fails, and Rick is our webmaster (a single point failure). We talk back and forth for a week, and by then his monitor is fixed. We lose a week.

3. I forget to sign one of two signature lines on a bank form establishing the project bank account. This delays the payment of bills for 10 days, which might have caused rippling delays — but didn’t because people had their own budgets and could pay the bills and trust they would be reimbursed.

4. Kevin breaks his hand, which is especially tough because he can’t use his Braille reader. This delays lots of things Kevin is involved in, but the primary delay is in delivering his article for our pre-conference book. This turned out okay, because he wasn’t the only one whose article was delayed.

5. Dave, who is developing our wiki-web site, gets the flu. This delays the entire wiki testing for a couple of weeks, but it’s not yet on the critical path.

6. Some security certificates (whatever they are) expire on my browsers, and my attempt to update them crashes my system. This non-understood bug delays many tasks for several days (but the effect was somewhat ameliorated by having an alternative browser).

7. Several people take vacations they’ve been planning for a year or so (how inconsiderate of them!). This wouldn’t have been much of a problem if we’d thought to put these vacations in our plan.

8. Naomi has a serious family situation, so she decides she must cut back on her participation until it’s resolved. This adds extra load to several other people, but we were not overloaded, so the schedule effect is minimal once Johanna, our project manager, reallocates the tasks. We are able to reduce Naomi’s participation to the one area where her contribution is least replaceable, and we can do that because we know exactly what Naomi is best at (helping other writers).

9. People who were not at our initial planning meeting have to be brought up to date — not just on our plans, but on the logic behind our plans. We haven’t planned for this, so it’s a real delay — but has an excellent side effect of making us rethink some of our logic before it’s too late to change.

10. James joins the team and has to be brought up to speed. Again, more delay, but with the benefit that James is a talented tester, and subjects many of our plans to tests that we haven’t thought of. James is also an excellent writer/editor, and can take up some of Naomi’s tasks. So, we paid with some delay, and were repaid with some later catching up. In other words, educating James about the project turns out to be a sound investment. Late in the project, however, it wouldn’t have had time to pay off.

11. Our phone and email lists are somewhat out of date at the start of the project, causing irritating delays until we stop and fix it. This contact information should have been done at the very beginning, as it is a core competency for a distributed project. Also, we needed plans for updating this information, because the project is about a year long, and over that period of time, some contact information will undoubtedly change.

12. Marie’s son gets sick, which takes her attention away from AYE business for several weeks. I begin to wonder why all these people are being so inconsiderate of our conference’s problems!

13. I find a strange new mole on my neck, and have to have what the doctor calls minor surgery. (Minor surgery is surgery done to someone else.) Then she finds another suspicious mole, and I have more minor surgery. Then I have a dental emergency (I’ll spare you the painful details). I begin to understand why all these people are being so inconsiderate of our conference’s problems.

14. We are putting together a book of essays by the conference hosts, to introduce people to our work. By definition, we have to have an essay from every one of us, but a few people are at the tail end of the curve with respect to personal pictures, bios, and essays. There are a variety of fine reasons for their delays, but the fundamental reason this is so troublesome is the structure of that part of the project. Since everybody has to have an essay in the book, finishing is like trying to get that last Pokemon card, or last number for a bingo. The mathematics of this kind of requirement ensures that such a project will cause anguish, and we eventually decide to relax the requirement that everybody contribute. If a few are missing, we can live with that. Relaxing this requirement relaxes those of us who are responsible for the book sub-project — and curiously enough, seems to cause all the pictures, bios, and essays to arrive on time.

15. Unfortunately, some of the articles submitted aren’t up to quality standards we had set, and they have to be recycled. We could save quite a bit of time by lowering our quality standards, but we decide against this, since quality is one of the key goals of our conference. What good would it do, we reason, to preach quality when we ourselves don’t practice it.

16. There are lots of typos in the material we prepare for our web site (ayeconference.com), but unlike many web developers, we believed that web sites do have to be tested. Therefore, these delays were anticipated and planned for by the web and project teams, and so fit within the schedule.

17. From time to time, some team member panics about some item or another — which takes time and effort to soothe. Our perfectionism is a major cause of these panic attacks; satisficing (learning to think about what was acceptable quality, rather than perfect quality) is a major cure.

18. Then there are holidays, delaying things in a variety of ways. Why couldn’t Jesus have been born in August, we ask? Poor planning, we concluded — was it by God or by us? Probably us.

19. And of course there is bad weather, which turns out not to hurt us as much as we expected because our travel is mostly virtual. We are lucky there, because the infrequent travel is more by personal preference than project planning. Most of us travel much of the time, and we’ve learned Freedman’s First Law of Consulting: Don’t fly on the East Coast in Winter.

20. We are hurt much more when my ISP (Internet Service Provider) starts delaying delivery of my email by 1 to 7 days. We are hurt even more when Steve’s ISP, which hosted our email lists, starts failing intermittently. Once we realize what is going on, though, we are able to bypass the convenience of group lists and simply maintain our own teams’ lists until Steve gets things straightened out with his ISP. Steve eventually realizes, though, that he had chosen his ISP because they were the low-cost provider — a lesson for next time.

21. Then, once we have all the essays and bios and pictures, we realize that some people haven’t kept the paperwork concerning their articles that they had previously published elsewhere. As one contributor says, “It just didn’t seem important to keep those legal things — at the time.” Lesson obvious, and lesson learned — I hope.

Conclusions

Well, there are lots more than twenty-one, but I think I’ll stop here. Some of us will publish the entire project’s delay list in the future; it will probably be a book. And we’re planning to conduct a retrospective at the conference itself. For now, though, I think you might like to look over the list once more and compare some of your conclusions with mine.

God may have other priorities higher than your project. Leave some slack for Acts of God.

Perfectionism kills schedules; reasonableness saves them.

Certain project structures make success as likely as winning the lottery. Search out and eliminate this lottery effect from your project plan. Not only does this eliminate “bad luck,” but it also lowers psychological pressure on participants, which leads to “good luck.”

Quality is negotiable, but not infinitely negotiable.

Plans are predictions; plan to test them early and often, and then adjust them.

Machines fail. Software fails. People are even less perfect, but they’re more adaptable, so they’re handy to have around to back up the machine systems.

If you have a single point of failure, it will fail at a single point in time. After that, if you have any brains at all, you’ll remove it.

Cross-training is one of the surest ways to protect against those single points of failure. So is a good asset control system for all your project’s assets. If you fail to follow this system because “it doesn’t seem important,” you’re sure to lose your assets.

You won’t be aware in advance of all possible single points of failure, but if you do some risk analysis, you’ll be aware of many of them, which will leave you more time to deal with the ones you weren’t aware of.

You won’t appreciate other peoples’ delays until they happen to you, but try to learn to grant them a generous interpretation. This may calm you down sufficiently so that you can actually become part of the solution, rather than adding your blaming to the problem.

And, finally, I often hear my clients telling me that their project will make its schedule “if everything works out right.” Well, I’ve been in the project business for over forty years now, and I’ve seen several thousand projects. I’ve never seen one where “everything works out right.” This has led me to formulate Jerry’s Iron Rule of Project Life:

It Always Takes Longer

Defy this Iron Law at your peril. Plan for delays, and plan to be adaptable and forgiving when delays occur that aren’t part of your plan. You’ll be more successful, and you might even be happier. As of now, we’re on schedule for November, and we’re rather happy about it.

©2003 Gerald M. Weinberg, www.geraldmweinberg.com

People are always asking me to make predictions, especially predictions about their financial future. Which stocks will grow? Which dot.coms will fold? What jobs will be best? What should they study to prepare for their future jobs? Predictions are difficult. Well, actually predictions are easy - unless you want some accuracy. Since I’d feel responsible if I hurt somebody with a poor prediction, I seldom accept their invitation to predict.

Let me give some examples, starting with some predictions that, had I listened to them, would have seriously hurt my career as a writer. I have published about 40 successful books, yet I still don’t understand how publishers make predictions. The most successful of my books has been The Psychology of Computer Programming, which was delayed more than a year by a series of publishers who couldn’t decide what to do with it.

I first sent it to the company that had published all my previous books without hesitation. Here’s what they said: “It just is not worthwhile pushing this project any further. It may be that the concept is good … but the style and breadth of presentation is just not suitable. It could be that a major overhaul and rewrite will result in a marketable project. On the other hand, it may be wiser to forget the book concept entirely…”

The book was not overhauled, nor rewritten, but it was turned down by another publisher before it finally found a home. It’s now been in print for more than 30 years, and has sold over 100,000 copies in English, and many more in other languages. For the company that eventually published it, Psychology sold more copies and made more money than the next five books in their line. In retrospect, the two publishers who declined the project proved not to have much predictive power.

My second most successful book so far has been An Introduction to General Systems Thinking. Naturally, I sent this manuscript first to the perceptive publishers of Psychology. Here’s what they said: “Our referee believes that the market for such a volume is limited. With this in mind, I do not believe it is for us.” This one has been in print now for over 25 years, and has sold more than 50,000 copies.

The same pattern now holds for my third most successful book, The Secrets of Consulting, and the fourth, Are Your Lights On? - how to know what the problem really is, and the fifth, What Did You Say? - the art of giving and receiving feedback. And none of my less successful books, so far, have ever been turned down by publishers!

Experiences such as these have brought me to the reluctant conclusion that publishers know a lot about predicting the future success of a book - but what they know is exactly backwards. Or at least for new and different subjects. Shakespeare goes in and out of fashion, but even at low ebb sells pretty consistently. Algebra books compete with one another in a comfortable, steady market, as do introductory books in such subjects as economics, physics, philosophy. Books in such areas are more predictable, but, then, they’re less likely to make a big splash.

In computing, it’s not so steady, and predictions are even harder than with books. For publishers of computing books, the subject of tomorrow’s best-seller is unknown to today’s editor. Editors don’t follow the field; they follow the publications in the field. Unless and until somebody else publishes a book on the subject, the editor doesn’t consider it a subject at all. Those blinders are evident in the subjects of those books of mine that became the best sellers. Before the Psychology of Computer Programming appeared, the psychology of computer programming was not a subject.

Magazine and newspaper publishers have an easier time in a fast-moving field, because their publications generally get trashed before they become obsolete. Who reads last year’s Contract Professional to learn about the future of the job market?

But some of my friends do keep old copies of magazines, and I keep them if they contain an article of mine, so some evidence of successful or unsuccessful predictions remains for us to study. One of my friends sent me this prediction from Popular Science, May 1967, page 93:

“Timesharing, most experts agree, is the key to the computer’s future, at least for general use. A few years ago, when people thought about household computing at all, they thought of some small, inexpensive, individual unit that would keep track of the family checking account and automatically type out the Christmas card labels. Now we know it won’t be like that at all.

“The reason is economic. The bigger and faster the computer, the cheaper it makes each computation. Consequently, it will be far cheaper to build one monster computer with thousands of customers hooked to it than to have small, individual machines in individual homes.”

Here’s another prediction taken from the September, 1962 Datamation, which I happen to have because I had an article in it. (The article incidentally, was about how to make fake demonstrations, and that seems to be something we’re still doing 40 years later. Sound familiar?) Anyway, IBM’s 1962 recruiting ad said,

“IBM programmers … are devising programs that in turn use machine capability for formulating new programs. They are creating programs that enable computers to diagnose their own faults through self-checking. And they are helping to design the systems that will let scientists and engineers ‘talk’ to machines in the everyday language of science and engineering.”

I don’t know about you, but I hope they finish these projects before I retire. I so much want to talk to my computer in the everyday language of science and engineering. (Sound familiar?)

Patrick Henry once said, “I have but one lamp to guide my life. I only know the future from the past.” So, if the past can be used to make predictions, what predictions can we make using past predictions as a guide? Here are some that I’ve made, for myself:

1. Editors will predict what will be popular in the future. So will recruiters. They will be wrong.
2. People will predict that computers will get so cheap that programmers will be eliminated. They will be wrong.
3. People will predict that thinking and problem solving and other human activities will not be as important in the future as in the past. They will be wrong.
4. People will predict that there won’t be anything really new to do with computers (just Christmas-card labels and everyday language of science and engineering). They will be wrong.

So, here’s my advice for the future. Read some books, but not too many on one subject - and don’t take editors too seriously. Learn the most general of skills - how to think better and how to work with other people more effectively. Then look for jobs where you can apply those talents to build new things - but probably not things that are going to replace people. And, if you follow my predictions, you’ll probably have good jobs and good pay your whole life.

But I’m probably wrong.

© Gerald M. Weinberg, 2004 www.geraldmweinberg.com

Software Development Magazine recently interviewed Jerry. Here are some of his answers.

Q: What?s the most important piece of management-related advice anyone has ever given you?

GW: If you blame your employees, you’re a bad manager. You hired them, accepted them, supervised them, and directed their training. You?re responsible. If you don’t like what’s happening, look to your own behavior. But, if there’s credit to be given, it’s theirs.

Q: What about when a manager has been hired into a group where some or all employees were already hired by someone else?

GW: You don’t take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off — or you don’t take the position. I don’t know why managers don’t understand that. They take on new assignments like high school kids on their first blind date.

Q: What if an employee begins to exhibit bad behavior after he or she has been hired — behavior that wasn’t apparent in the interview phase?

GW: Well, that happens, and that’s what managers get paid for handling. It can be a setback, but it’s your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I’ve been trying to remedy for years — so in a sense, I’m to blame, because I’ve succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn’t need managers.

Q: If you were to publish a third edition of The Psychology of Computer Programming, what new insights would it include? (Dorset House Publishing released a Silver Anniversary Edition in 1998.)

GW: I might add something about how to make yourself so valuable that your work will never be outsourced — something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that’s just not being done because the odds of success are so poor.

Q: Is this bad behavior coming from the developers themselves, or do you mean to say the entire industry is to blame for not staying on top of innovation?

GW: It starts with the developers, and managers, too. But the overall result is, as you suggest, the entire industry getting too involved in navel-watching and competitiveness over the wrong values. For a long time, customers had nowhere else to go for service and had to put up with whatever we gave them. Now they have choices, and they’re getting even.

Q: In Are Your Lights On? (also available from Dorset House), you note that people like to complain. How do good managers draw the line between harmless venting and disruptive pessimism, if such a line needs to be drawn?

GW: “Drawing the line” is probably not the most useful metaphor. The approach I like most is to listen to the complaint for a reasonable amount of time, then say, “And what do you propose to do about this?” Depending on the reaction you get, take it from there.

Q: You once said, “If you can?t manage yourself, you have no business managing others.” Could you elaborate on that? What does it mean to manage one’s self?

GW: Well, perhaps you can look at Kipling’s famous poem,”If.” It starts:

If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting,
Or, being lied about, don’t deal in lies,
Or, being hated, don’t give way to hating,
And yet don’t look too good, nor talk too wise;

Most of this poem is still pretty good advice about what it means to manage yourself (except, unlike in Kipling’s day, it now applies to women, too).

Q: In your opinion, why do so many software projects go over budget or fail to meet their original requirements?

GW: There’s no single reason, but here are probably the top three:

1. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.

2. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have).

3. Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project?s success is determined by the leaders’ ability to manage themselves emotionally.

Q: If you were to find yourself on a development team, reporting to a project manager, what qualities would you want that manager to have?

GW: I’d want that manager to be a congruent, adult human being, capable of learning from others and his or her own mistakes. A good place to start honing these attributes is the AYE Conference.

©2007 Gerald M. Weinberg

Throughout my career, I’ve watched in dismay as one software manager
after another falls into the trap of achieving delivery schedules by
trimming tests. Some managers shortcut test work by skipping reviewing
and unit testing in the middle of their project. Others pressure the
testers to “test faster” at the end. And, most frequently,
they just drop planned tests altogether, hoping they “get
lucky.”

I’ve written several essays about the dangers of test trimming,
but nobody seems to understand, so I asked myself, “What am I
doing wrong?” Perhaps I wasn’t practicing what I was preaching.
Perhaps I was trimming tests myself. Perhaps my writing needed
more testing!

So, I wrote a story about taking shortcuts and read it to my
granddaughter, Camille. Here’s the story:

Rhubarb Cakes for the Queen of the Forest

Once upon a time, all of the animals in the forest were in an uproar.
Calling Crow had just proclaimed that in two hours, the Queen of the
Forest would arrive for a visit to choose a new Royal Baker.

“She’s going to hold a baking contest,” Calling Crow cawed.
“And the winner will be named Royal Baker?and win a prize of
100 pieces of gold!”

“What do we have to bake for her?” barked Burly Bear.

“Rhubarb cakes,” Calling Crow cackled.
“They’re her very favorite dessert.”

Rapid Rabbit ran nervous circles around a rhododendron bush.
“Rhubarb cakes? But the Queen is coming in just two
hours, and my recipe for rhubarb cakes takes three
hours.”

“So does mine,” complained Canny Coyote.

Burly Bear sharpened his claws on the bark of an ancient aspen.
“Mine, too.”

Prudence Porcupine popped up and headed for her kitchen.
“Then I think I’d better get started, and not just stand around
complaining?”

Each of the bakers pondered how they could make their rhubarb cake
in two hours.
“I’ve got it,” thought Rapid Rabbit.
“What takes the longest time is putting in a little sugar at a
time, stirring for five minutes, and tasting to see if it’s just right.
I don’t really have to test the sweetness a little at a time. I’ll just
throw in the right amount of sugar all at once, and that should save me
an hour.”

Burly Bear reasoned to himself,
“I have the biggest oven, so I can put the cakes on the top
shelf, in the very back where it gets super hot. And I can stoke the fire
with lots and lots of apple wood because that burns hotter than any
other wood. If I bake the cake at a higher temperature, I can save a
lot of time and have it ready when the Queen arrives.”

Canny Coyote didn’t have such a big oven, but he figured,
“if I just cut an hour off the baking time, the cake might be
a little soft, but I’ll put in lots of sugar.
The cake will be so sweet that the
Queen won’t notice.”

But Prudence Porcupine had a different way of thinking.
“I know my rhubarb cakes are delicious, but if I take any shortcuts,
I’m pretty sure the cake won’t come out right. I’ll just tell the Queen
that my cake is going to be late, but that it will be worth
waiting for.”

When the Queen arrived, Rapid and Burly and Canny all had their
cakes on display in the clearing, and the Queen was invited to taste
each cake in turn.

She took a bite of Rapid’s cake and made an ugly face.
“Yuck. This rhubarb cake is so bitter.
Why didn’t you add more sugar?”

Then she turned to Burly’s
cake and asked, “Why is this one all burned and black?
Well, maybe it’s better on the inside.”
But when she tried to cut a slice, the burnt crust was just too hard to cut.
Instantly, the Queen moved to Canny Coyote’s table
without even tasting the bear’s cake.

She tried to cut a slice of the coyote cake.
“This cake looks rather mushy.
Oh, it’s all gooey and runny when We try to cut into it.
We think it would make Us sick if We put it in Our mouth.”
(Queens always call themselves “We”
because they believe they are speaking for the entire nation.)
The Queen stuck out her tongue at the cake and refused to taste it at all.

Finally, the Queen turned to Prudence’s table and asked,
“Why is there no cake here? We distinctly said
that every baker was to make a rhubarb cake.
Who dares to refuse a Royal Proclamation?”

Prudence stepped forward, bowed to the Queen and said,
“My cake is in the oven, Your Majesty.
It will be ready for your tasting in one hour.”

“But We said the cake must be ready NOW
” shouted the Queen.
“That was a Royal Order, and cannot be disobeyed.”

Prudence bowed so low her quills caught some fallen leaves.
“Yes, Your Majesty. And I wished I could have made a rhubarb cake
in two hours. But I don’t know how to make a cake that
way that would be fit for a Queen, so I did my very best and took three
hours. If you want to punish me,
then you are the Queen and may do whatever you like.”

“Humph,” growled the Queen,
thinking of suitable punishments.

Prudence brushed away the stuck leaves.
“But the cake is in the oven now,
and you can just begin to smell how tasty it’s going to be.
In one hour, it will be fresh from the oven,
and a fit dessert for your refined tastes.
In the meantime, I’d be happy to tell you a story,
to make the time pass more quickly.”

“What story?” demanded the Queen.

“I thought I’d tell the one about the Princess and the Pea,”
Prudence offered. This delighted the Queen because that story was about her,
when she was a young princess. So the Queen listened to the story,
and laughed and cried and clapped so hard that an hour passed
by very quickly.

Then Prudence put on her mittens, opened the oven, and took out a
perfect rhubarb cake. The Queen loved it so much she ate the entire cake,
with just a small slice for Prudence. Then she gave Prudence a woven bag
with one hundred gold coins and announced to the whole forest that Prudence
Porcupine, though she was at times a little prickly,
was the Best Baker in the Forest and now would be the Queen’s Own Baker.

**********

When I was finished reading, I asked Camille what was the lesson
of the story. She said,
“Burly and Roger and Canny were not real bakers.
They were just pretending because they wanted to win the prize,
but they didn’t know how to bake a real cake.”

“Very good,” I said. “But maybe they did know,
but were afraid of the Queen.”

“If you’re afraid to do what you know is right,
then you’re not a real baker.”

Camille, who was not yet five years old, understood this story perfectly,
so it passed my test.

I wonder if forty-year-old software managers will be able
to understand it?

© 2005 Johanna Rothman (This article previously published in Better Software.)

The last few times I’ve taught project management, I’ve explained that multi-project context switching wastes time. The project managers agree with me. But then they ask the question, “How do I explain this to my management? They refuse to believe me.”

Managers, especially senior managers, don’t believe context switching wastes time because all they do is context switch. Senior managers frequently have several projects in the air, most of them waiting for input from other people. But that’s not how technical projects work. Most of the time, technical people are not in wait states, but can continue to work productively on projects. Senior managers don’t understand or remember that the work technical people perform is substantively different from the work they perform.

So to reach managers and convince them that context switching is a bad idea, make sure you speak their language. First, set the stage by explaining how technical work is different from management work. Next, help your manager determine the relative priority of each piece of work. Finally, block out the work, and keep your management apprised of the status.

Technical work is different from management work

Here?s one example I’ve used when explaining how technical work is different from management work. Assume you work for a bank, and you have three post-release fixes to complete. One fix is for the branches, for a particular type of new accounts. One fix is to change the format of particular data you send to the Federal Reserve. And the last fix is in the reporting software that the branches use to report a variety of measures to headquarters.

You’re the technical lead for a group of four other people(a total of five people), and each fix will take two calendar weeks to complete. That’s a cost of ten person-weeks for each fix, a total of 30 person-weeks. Because the fixes are in unrelated systems, you can’t batch any of them together. If you perform the work for each fix serially, at the end of six weeks, you’ll have all three fixes ready. (see Figure 1.)

Figure 1

If you context switch, the best case is the first fix is finished at Week5. The best case assumes that each person working on a fix spends the entire week working on a particular fix. Between each week is a bit of time context switching to remember the state of the fixing. In my experience, it’s more that the first fix would not be ready until about week seven, the second fix at week nine and the third at about week eleven ?if not later (see Figure2).

Figure 2

But that just represents the pressure on the technical staff. Don’t forget the pressure on senior management. In this example, in between their meetings, presentation development, document review, voice mail, and more meetings, three people are calling your VP and leaving urgent voicemails, emails, or stopping by your VP’s office.

Stacy represents the Federal Reserve auditor. She says, “I really need that fix for the Fed, and I need it right away. Your guys are working on my fix, right?” Betty represents the branch managers. She’s left your VP several emails and voicemails, each saying “Another call from a branch manager. This problem is costing us a fortune in back-office support to create those accounts with those workarounds.” And Dan, the CFO, represents the Board when he says, “We need the data from the branches. And we need it before the end of the quarter, so we can get ready for the end-of-quarter financials.”

Your VP is under tremendous pressure to fix all of these problems at the same time. So, first explain how you work, and how working on one fix at a time will get one customer off your VP’s back. Now, help your VP determine the relative priority of each fix.

Determine Relative Priority for Each Project

Each of these three fixes is critically important to the welfare of this organization. And, because there are a limited number of people, management will have to choose a relative priority for each fix. One question I like to ask about priority is, “What are the consequences to the organization if we select this project first?” Then I ask the same question as we review the project list.

Typically, I ask about consequences and risks in terms of regulatory issues, loss of customers, revenue, and ongoing operations costs. Your organization might rank these issues in a different order or modify this list. Then I ask about the data that says this project is urgent. When I worked with this client, we called Stacy and asked about the auditor?s needs for the data. Stacy was being proactive, but the real deadline was another quarter away.

Next, we called Dan, and asked, “Would you rather save this much money in back-office work or receive the branch reports?” Of course, Dan said both, and we explained he had a choice of one. If he didn’t make the choice, we would. He chose saving money in the back-office, a choice that surprised both my client and me.

I’ve been in situations where we really did need to have three things done at virtually the same time. In that case, we staffed each fix with its own project staff, and stopped working on new development work. Now we have three projects in priority order: fix the accounts, then the reports, and finally implement the data format changes.

Keep Management Apprised of Status

As you proceed with your projects, make sure you maintain progress on each project. Since you?re not context switching, it’s easier to do that, especially on smaller projects like fixes. Report your progress to management periodically, so they understand you are making progress.

Some of you may be saying, “Well, now I know how to do this for small projects. But I?m managing three big projects, all with the same thirty people. Each project is a year long. How the heck do I stop context switching on these projects?”

Extend the risk analysis for larger projects

First, perform risk analysis for all of the projects, developing a list of projects in relative priority. For larger projects, your management may not be able to or willing to define the relative priority for each project using the issues of regulation, loss of customers, loss of revenue, enhancement of revenue, or reducing operations costs. Two projects may appear quite similar. In that case, either consider how you prioritize projects (which may be out of your control) or consider changing how you develop projects (in your control).

Consider moving to iterations for projects that appear to have the same priority

One technique I’ve used is to move to month-long iterations when two projects are competing for the same people at the same time. Even after attempting risk analysis, if my management still can’t make a decision, I either assign half the people on one project and half to the other, or I select one project. Either way, everyone works on their assigned project for one month, and shows some visible progress. Then I ask management to look at the progress we?ve made. One technique to accomplish this is to implement by feature. If no one looks at the demo or our visible progress, I stop work on that project and move everyone to the other project. If management reviews our progress, I verify that this project is still the highest priority,and continue work. If I’ve staffed both projects with half the people, and management is happy about our progress, we continue with that staffing. Otherwise, if this is enough project work on this project for now, we move to the other project.

Context switching at a one-month boundary isn’t great, but it’s better than the alternatives. But in order for this to work, you need to show demo-able software. It doesn?t have to be release-able, but people outside your project have to be able to see your progress.

Stop the madness

Context switching is insanity, because it guarantees everything will be late. You don?t have to live with multi-project context switching. It requires an understanding of the differences in work between technical people and management. You may need to lead the risk analysis and ordering of projects. And when you’ve selected a project and started working,make sure you can show people your progress at reasonable time periods. It’s hard work to stop multi-project context switching. But the rewards are worth it.

Acknowledgements

I thank Dwayne Philips and Leo Hepis for their review.

©2003 Johanna Rothman www.jrothman.com

Jim, a new project manager, struggled to define the project?s parameters: schedule estimate, people estimate, requirements outline, and necessary capital equipment. Jim proudly walked into his manager?s office, and proceeded to walk through his project plan discussing these numbers:

64.1 calendar weeks

12.125 people

ROI (return on investment) of 7.5 months

Jim?s manager, Dave, stopped him, smiling, and said, ?So, Jim, where?s this .125 person coming from? And what?s .1 of a week?? Jim was a little stumped, and said, ?Oh, I guess we?ll borrow someone else. I thought you?d want to see a project plan with the fewest number of people. One-tenth of a week is part of a day.? Jim?s manager said, ?Well, we only have whole people, so I need a plan with either 12 or 13 or whatever you think the right number of people is for this project. And, while you?re at it, although I would love to plan a release for a Monday at 9:37am, we both know that?s not going to happen. Please work up an estimate that?s more accurate, but not as precise. And, while you?re at it, show me our options?how many people for how many weeks, giving me ideas for how we would staff a shorter project with more people and a longer project with fewer people.?

Precision is the exactness of the measurement, the number of decimal places. Accuracy is how close you are to the estimate. When I worked with robots, precision meant how close to a specific place in space we could move the robot arm once. Accuracy meant how many times we could make the robot arm move to that precise place. Jim?s estimate was certainly precise, but estimates are more useful when they are accurate, close to the mark. Projects are composed of numerous predicted estimates, so we can?t expect accurate estimates, except to an order of magnitude. Over time, you can learn how to estimate so that your estimates (predictions) are close to your actual schedule.

When you talk about estimates, you?re in much better shape if you choose accuracy (how close you are to the prediction) over precision (exactness). As you move closer to accomplishing milestones, you can re-estimate with greater precision.

One way to discuss a schedule estimate is to deal with a range. Jim could have said, ?I?ll need 13 people for about 64 weeks. Or, I can do this project with more difficulty if I have 20 people for about 50 weeks. Or, if we take out this specific performance requirement, we?ll need 18 people for about 48 weeks.?

Each of the ?abouts? in the previous sentence exists for accuracy. Schedule estimates are just that, an estimate. In my experience, putting an ?about? in front of a schedule estimate is more helpful than a range (?62-65 weeks?). I?ve met too many senior managers who don?t hear the second number, just the first. When I use an about, I can choose a number that makes sense to me to use to senior management.

However, some of you work for managers who prefer a range of estimates, with a confidence for each point in the range. This is particularly helpful if you use a graph to explain your confidence. (see Figure 1.)

Figure 1: Estimates: Precision vs. Accuracy

The graph is a vehicle for starting the discussion about why you have how much confidence when. You can explain why you only have 50% confidence that you will meet the 3/1 requested release date, and you can explain why your confidence improves over time. With this graph, you?ll especially want to explain the difference in confidence between 6/1 and 7/1. The project manager who generated this graph was concerned about the amount of rework (problem finding and fixing) at the end of the project, and wasn?t absolutely sure the project team could finish the rework for 6/1. When he explained how the last three releases had used more than the planned four weeks, his management understood why his confidence level was less than 100% for the 6/1 date.

If you have a sponsor who says, ?Just give me a number, and give it to me now,? you have numerous choices about the date you provide. You can choose a date somewhere in your range, depending on how risk averse you are. Frequently, sponsors who need dates without a discussion of estimates really do want just a date you can promise, not the first possible date the project could be ready if Murphy?s Law didn?t come visit your project and all the planets were aligned. If your sponsor is not willing to use the date you provide, you?re dealing with the ?Bring me a Rock? game. If you have a sponsor who appears to not be willing to consider why you don?t have a date, you have several options: make an appointment to talk about project schedule estimates; discuss your sponsor?s concerns and what matters to your sponsor; or find a new sponsor or new organization.

Choose some technique, ?about? an amount of time, dates with confidence attached, or a date in the middle of your range, to help your project sponsor see that the schedule or the budget or the ROI, or whatever number you?re discussing is an estimate.

Be precise at the end of a project, when you file your project information, and manage the data that was part of the project?s outcome. In the meantime, be as accurate as you can, by using approximations, ranges, and ?about?. Jim now works for accuracy at the beginning of his projects, and precision at the end.

©2003 Johanna Rothman www.jrothman.com

Do you ever wonder what you’re really supposed to focus on for your project?

Companies create a variety of products, and different releases of those products, for many reasons. Some product releases can tolerate glaring defects; others have to be extremely reliable. Some releases are bound by time to market. For other products, the customers will wait. Some releases are loaded with features; other releases have a minimal feature set.

The goals for quality, schedule, and features for a project are intimately related to the reasons for creating the release in the first place. Since the definition of quality is determined by the goals you?re trying to achieve, you need to define quality for your project, and figure out what you need to focus on.

Each project has one, and only one, of these goals as its top priority, and then addresses the other two goals within that context. This prioritization determines the tradeoffs the project manager and staff will make during the project, and should help define the product development process to use in developing the product.

An honestly designed project has two priority thresholds: the absolute bottom line and everything else. The bottom line is generally implicit?unless the top management is clueless, if a product destroys the hard drive of even 5% of the testers, the product will not ship even if time-to-market is the dominant priority. Why? Because the organization knows that shipping a destructive product will decrease its market share. In the same way, there is an absolute limit to features. A release has to have something new, even if there is just a requirement not to wipe disk drives. It might be a very minimal requirement, but it exists.

Project focus is about making “everything else” explicit. One way to focus priorities for a project is to use Geoffrey Moore?s high-tech marketing model to understand the market imperatives. Table 1 provides a view, based on his model, of the interaction between the definition of quality and the product lifetime. The users (and potential users) have different perceptions of product quality over the lifetime of a product. The chart shows how the three possible priorities are sorted for different classes of users. As a product evolves, it moves from one target user group to another, and (in the model) the priorities shift accordingly.

* Medium pressure for features does not mean pressure for new features. It means that the promised features must be in the product and must be working.

If you’re working on a product for Visionaries, you want to focus on time-to-market, not terribly low defects. If you’re working on a product for Pragmatists, you want to focus on low defects, not time to market.

I worked once on a project where the developers thought they were working on a project for Pragmatists. Management thought they were working on a product for Visionaries. Management panicked when developers missed a milestone about 6 weeks before expected ship. The developers’ priorities were low defects; time-to-market, then the feature set. Management’s priorities were time to market; feature set; and then low defects.

Since management realized they were not going to meet the original schedule with the original features, they then asked for anything the developers could get done in the next six weeks, to meet the original dates. Since the project focus was not explicitly stated, the developers did not change how they were working. The developer’s priorities remained the same.

This change of focus happened twice more, where management reduced the feature set, accepted higher defects, to get the product to ship as early as possible. SmartStore’s product development process was not flexible enough to accommodate the shifting goals, and the project manager was not capable of explaining to the organization how the shifting goals would prevent the project’s success.

After three sets of shifting goals, the Test Manager realized they might never ship a product. The Test Manager then chose specific product goals (a certain smaller set of features, moderate defect levels including performance no worse than the previous release, and an aggressive time to market) and formulated measurable release criteria. The project was complete when the release criteria were satisfied.

Even with all these goal changes, the product development activities did not change until the final product goals were defined. The development staff never understood the goals and what they needed to do to make those goals. Throughout the entire process, the product developers spent most of their time fixing defects to make a (lower priority) market ship target.

At the end of any project, defect-fixing is the main activity, it?s the choice of which defects to fix that is the most interesting. At the end of this project, the developers were able to consider which defects to fix, based on the release criteria.

If you’ve ever found yourself in the dilemma of shifting project goals, then consider how you focus your project goals on low defects, time to market, or features.

©2007 Johanna Rothman

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.

©2003 Johanna Rothman, www.jrothman.com

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.

©2006 Johanna Rothman

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.

©2005 Johanna Rothman

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.

©2004 Johanna Rothman.

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.

©2005, Don Gray

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” — Mark Twain

Working on hardware projects requires incredible attention to detail. Design time can take weeks, and actual fabrication time from order to delivery can be months. If something isn’t correct, you can’t just “edit and recompile”. You end up starting all over again, hopefully wiser, but just as far from delivery as you always were.

Recently I started working with a client bringing a hardened platform to market. The project involves in house designed custom electronics, tailored BIOS, an embedded OS, and their proprietary application. In addition to task monitoring and supply chain details, I also report project risks to the Engineering VP and CEO.

Evaluating Risk

After reviewing the project scope and delivery, meeting with the team and vendors, I started working on the risk assessment. My first pass was a spreadsheet that listed each risk I could think of, the probability it might happen (0 - 1), the impact if it did happen (again 0 - 1), and what we might be able to do if the risk occurred. A partial list looks like:

The risk factors are precise, but I couldn’t convince myself the numbers were accurate. The company has no quantitative data on vendor delivery, assembly times, or unit quality. I couldn’t justify the quantitative values beyond “Well, the numbers seem right”. Another problem with this approach is the side affect of multiplying two decimals together. The units failing certification presents more of a problem than the “.32″ implies. I decided to switch to a qualitative approach.

I now rank the risks using the following matrix¹.

A high potential loss coupled with a low likelihood results in a “C” rating. I spend more time working on the “A” risks than I do the “E” risks. My risk list now looks like:

Monitoring Risk

Now I could create time line with deliverable items and their associated risk. Given the short time span (about 10 weeks) I used a spreadsheet with columns for deliverable, due date, risk, and last updated. For incremental tasks, I added a column for “to do next”. This gave me a document I could quickly review everyday that was easily updated with new information.

Reviewing the deliverables, associated risks, and timetable left me feeling comfortable and confident we were home free. That’s when I started to worry. It’s not what I knew that was going to put the project in jeopardy; it’s what I didn’t know.

Exploring Risk

What I wanted to do was identify which risks were most likely to happen, and deal with them before the next set of units were built. What problems would we encounter? How could we prevent these problems from occurring? How would we deal with them if they did

I selected three activities to deal with these questions.

1. Build early - I borrowed this one from my software experience.
2. Learn from each build - Work on improving the process.
3. Simulate - If you don’t have the real thing, substitute and act like it’s real.

Build Early

This product had gone through three revisions without seeing the front door. It turns out there were units which were functionally equivalent to the units we waited for. Management agreed to create ten “engineering prototypes”. These units were slightly off the final spec, but were close enough that resilient users could work with the units. This brought less loving and more critical views to the product. Differences between the product, the specification, and expectations were highlighted more quickly than standard reviews. Users were encouraged to try and find ways to “break” the system. We used OS specific testing software to verify the hardware properly functioned with the OS.

Practice Building

We chose to build one unit at a time. We’d note the problems with the build, correct the problems, and then build another. Occasionally it took a couple of days to correct the infrastructure issues, but we had 10 weeks. Why hurry? Get it right. Try again. After three build iterations, we had the kinks worked out of the process. This also had the side benefit of reducing the amount of rework when we discovered we needed to go back to the beginning and modify the units already built.

Building early and practicing building helped identify process risks, and allowed us to deal with them in advance. But the nagging question remained, what else don’t I know?

Simulation

Jerry Weinberg suggested we simulate the builds. Act like everything was ready to go, and start building the product. This exercise flushed out an almost invisible category. We had all the big parts, but didn’t have sufficient small parts for some assemblies. Little things like washers, screws and the like. The simulation could have been much more complex. We could have included interfaces, software components, and interactions between components. Since we had working functional prototypes, we chose to use actual equipment for exploring these risk areas.

In The End

Knowing what could go wrong is half the problem. Risk management isn’t over when the risks and how to deal with them are identified. Risk management requires daily attention; active anticipation of what can go wrong, how to hopefully prevent the problems, and reducing the impact of risks that actually occur.

I appreciate the AYE community for sharing ideas on this topic. You can read all the suggestions at

/wiki/scribble.cgi?read=ProjectRisks

¹http://www.comp.glam.ac.uk/Teaching/ismanagement/riskman1f.htm

©2004, Don Gray

Michelle works as a software engineer. Recently we discussed the ?utility? concept (Measuring and Managing Performance in Organizations, Austin)¹ and she asked, ?Can?t we just measure for the sake of learning??

Measuring for learning is a wonderful idea. Project managers, developers, QA staff, and their clients and customers can all benefit from knowing what is happening (no matter how painful it might seem at first). However, I?ve never seen a metrics program that was designed ?learning?s sake?. Even if there was such a program, the very act of measuring changes the system being measured. Here are several reasons why.

The Lunch Law

?There is no such thing as a free lunch.? Robert Kiyosaki

The Lunch Law masquerades in several guises. Mom taught me ?You can?t get something for nothing.? A physicist calls this law the conservation of energy. Both my mother and the physicist are pointing out that to gain something (knowledge) you have to give up something. What are we giving up in software development in order to measure?

Time
The first thing we give up is time. Taking measurements takes time. Collecting the measurements takes time. Processing the measurements takes time. And it takes time to report the measurements. In the ?internet time?, lean & mean, bare bones, full speed ahead corporate mentality, from where (or more correctly whom) does this time come?

Energy
Energy that could be used to develop is now being used to measure. Knowledge workers rarely have a singular job, with a single attribute. More energy will put on the item being measured, moving energy away from the other job mix components². Software developers moving too much energy to the measured attribute change the customer?s total benefit. A measurement program becomes dysfunctional when enough energy shifts and the total benefit is less than originally existed.³

Focus
The greatest forfeiture that occurs is focus. Once a measurement program starts, focus shifts from development, to development and measurement and wondering what does this new measurement system means. Will this affect my performance review? How do my measurements compare with my teammates? This dilutes the focus that had been solely on development. The informal communication network will focus on ?what does this mean?.

The Look Law
?Believe only half of what you see and nothing that you hear.? - Norman Cousins

The Look Law cautions against casually accepting measurements as ?the truth?. Consider the following project status report: ?The project is 50% complete.?

50% complete can mean the following:

• We?ve spent 50% of the money.
• Half of the project time line has elapsed.
• 50 % of the functionality has been developed and tested.

And which 50% is complete? It could be the easiest half or the hardest half; the most valuable half or the least valuable half, and so on.

This demonstrates the need to ask the following questions:

• Are they sending what they?re seeing?
• Are you receiving what they?re sending?
• Is what you?re receiving a surrogate value from which you must infer the information you really want?

Pertinent Positive
As you look at your metrics program?s data, what do you expect to see? Are things going smoothly? The next iteration of the company flagship software product should (hopefully) display fairly consistent metrics with previous iterations.

Pertinent Negative
Should they be going smoothly? Occasionally ?all thing going awry? should be expected. New product development using new technology should have different metrics than an incremental release of an existing product that used existing technology.

Pertinent Possible
What aren?t you seeing that you think you should see? On a recent project my client mentioned the software wasn?t working because the value he was watching wasn?t changing. I pointed out that the difference between the systems was two orders of magnitude, and that one system SHOULD take significantly longer to show a change.

Pertinent Plausible
Finally, do the measurements agree with other information about the project? ?Hard numbers? tend to make us feel like we know the project status. The meaning of the ?hard numbers? directly relates to our diligence in applying the Look Law. Do the numbers agree with more important (but less concrete) information you collect during walk-abouts and status meetings?

The Looping Law
?Round and round she goes. Where she stops, nobody knows? ? A Carny Cry.

The Looping Law points out features of measurement programs:

• Measurements from a single development cycle can help.
• Measurements from multiple cycles reveal patterns.
• Patterns reveal structure that can be modified to improve software development.

Software impinges on our reality. From microwave ovens to antilock brakes to magnetic resonance imaging to software on our computers, software (and its quality) constantly impacts our quality of living. Better software benefits society.

Measuring the analogous values over multiple projects can reveal behavior over time characteristics. One ongoing project I?m involved with has measurement data for four releases. We compare current measurements to the previous cycles to track our status.

You need to pay the Lunch Law costs, and practice the Look Law while paying. The benefit of doing so leads us to the

The Last Law
?Without visibility, control is not possible.? The Cybernetic Rule⁴

Measurement programs should answer the three big questions:

• How good it is? (Bug counts and severity)
• Is it done yet? (Ship and functional criteria)
• How did we do? (Time and cost)

We can better estimate future projects of similar scope and difficulty if we have measurement data from previous projects. Historical data provides the base line for observing the effects of software development process change. Managers monitor measurements evaluating the change?s nature.

Software metrics is a double-edged sword. The societal and financial reward can be enormous. The overall cost in terms of developer satisfaction and output can be devastating. If you decide to implement a measurement / metric program, carefully consider the following.

Communicate Early and Often
Clearly define the measurement program in advance. Know and share:

• What will be measured.
• Why it is being measured.
• How it is going to be measured.
• Who the measurement will affect.

You need to anticipate the Lunch Law will bias the results if the measurement affects performance reviews. People systems are self-directing and goal seeking. Tell me what you want, and I?ll do my best to deliver. Even measuring for measuring?s sake skews effort and could become dysfunctional.

Collecting Data
Consider ways to collect data without burdening the developers. Mine the data from existing documents and reports. Automate the collection, rollup and reporting processes as much as possible. This reduces the Lunch Law?s impact. Consider getting information from:

• Status reports
• Bug Counts
• Client input

Measurement data has many attributes. These include:

• Value. Some number, hopefully between the expected minimum and maximum.
• Quality. How much do you trust the value? Use the Look Law.
• Timing. Values should be ?here and now?, not ?then and there?. The more current the value, the more useful it can be.
• Relevance. What does knowing this value accomplish for me? If nothing, the Lunch Law suggests quit collecting it.

Recognizing the difference between the words we use when talking about measuring software helps keep information straight.⁵

• Measurement is a number, created form observation that allows ranking and comparison. 5 granks is both different from and bigger than 3 granks.
• Metric is a ratio of a measure to some other number, placing the measure in a context. ?granks? is a measure. ?granks per module? is a metric.
• Indicator is the result of comparing one metric to another. ?granks per module this build? versus ?granks per module last build?.

Consider Value

Project managers, developers, QA staff, and the clients and customers benefit from knowing the answers to the three big questions. Managers need to estimate the quantitative and qualitative costs due to the Lunch and Look laws. Determining how the new information benefits the company and the clients provides the go/no go decision for implementing a measurement program.

¹ Measuring and Managing Performance in Organizations, Robert Austin, ©1996 Dorset House Publishing

² DeMarco?s Law as cited in Quality Software Management, Volume 2, First Order Measurement © Gerald M. Weinberg 1993, Dorset House Publishing pg 29

³ Austin, op. cit. pg 15

⁴ Weinberg, op. cit. pg 48

⁵ adapted from Jim Bullock’s post Metric Vs Measurement

Despite the best efforts of the project manager and the project team, organizational forces may work against project success, especially on projects with tight time constraints.

This column normally deals with issues of applying Total Quality Management (TQM) to Information Systems. A recent consulting assignment, managing a system development project on a very tight time schedule, afforded an opportunity to experience organizational forces which worked to defeat even the best project management efforts. Therefore, this column will discuss the organizational pitfalls and obstacles which a Project Team may encounter.

In the Winter 1994 issue of Information Systems Management, I wrote an article entitled “Productivity Through Project Management — Controlling the Project Variables.” The article discussed project management methodologies, directed at controlling the work to be done, the resources assigned to the project and the schedule within which the project was to be completed. These are all factors directly under the control of the Project Manager.

Other factors may determine the likelihood of project success or failure. These are not under the control of the Project Manager and are not factors dealt with in Project Management methodologies, books or training classes. They are organizational factors which must be overcome in the course of the project effort.

Observation of these factors comes from many projects which I have managed in all types of organizations. They are present to some degree in every organization. Tight schedules, or “crunch mode” projects, will focus their effects. Even though the Project Manager may not be able to control these factors, awareness of them and appreciation for their effect will provide an increased chance of project success.

Project scope and objectives

Project objectives are never communicated to all parties who will be affected. Top management usually feels that the decision to undertake the project should be sufficient to get everyone behind it. They feel that they don’t have to “sell” the project, to explain why it is important or what it will do for the organization.

Many times individuals who feel that they should have been consulted on the decision to undertake the project, or whose point of view was not heeded, will not support the project or will continue to actively oppose it.

If the Project Manager finds that he or she has to “sell” the project or explain it to individuals who are affected by it, then the project is probably already in trouble.

Project scope is not understood by all parties who may be affected. Management does not even recognize who all these people might be. Individuals who are unaware of the project cannot be expected to support it.

Sometimes, when difficult scope questions are raised, they are simply ignored. The attitude is often “we’ll worry about that later.” Failure to deal with fundamental scope questions out front is another sure sign that the project is in trouble.

Requirements are not fully known. Decisions are made based on partial understanding of the project. The impact is not fully appreciated. Surprises are the rule rather than the exception.

Requirements may be stated for which there is no known solution. If you can’t express how you are going to meet a requirement, the chances are that you won’t be able to meet it. For every requirement, there should be a definition of acceptance criteria — evidence that the requirement has been met. If this cannot be clearly stated at project inception, then the project is in trouble.

Lack of business rationale

The business rationale for undertaking the project is almost never communicated and is never given wide dissemination. This is often true because many “crunch” efforts don’t make good business sense if given close scrutiny. They represent efforts to correct some gross oversight or major mistake (usually at or near the top of the organization).

Crunch projects are typically ones which could have been accomplished as a normal part of the business if management had been sufficiently far sighted to plan effectively. They are reactionary in nature, meant to address a problem which already exists, usually a problem that is severely impacting the business.

Project budgets and approvals

If there is a project budget established at all (frequently not the case with crunch projects), that budget may be grossly insufficient as major items may have been overlooked in the rush to start the project. When the budget is exceeded, this could cause problems in getting expenditures approved. If there is no budget, the same problems can occur at any time someone chooses to look at expenditures. Funding is always an issue after the fact.

The decision to approve the project is not necessarily a decision to approve what it takes to do the project. Many separate approvals may be needed and these are often poorly coordinated or communicated.

Often approvals are held up to make a point. We once experienced a chief executive refusing to approve an expenditure for four days on a project with an extremely tight deadline “just so everyone around here remembers who the boss is.”

Mistakes can be made when attempting to rush things through, causing requests to be held up or denied. Delays are to be expected. Without extraordinary management action, some requests may be denied or delayed indefinitely. Extraordinary management action is not always forthcoming.

Project Support

The project may not be taken seriously in some quarters. There may be an unstated but generally held belief that the project will not achieve its objectives nor meet its schedule. This, of course, damages the credibility of the project team and inhibits cooperation. Project team members may share this view as well, reducing their commitment or level of effort.

Look at the history of the organization in this regard. If crunch projects are common, how many of them succeeded? How many projects of any type actually achieved their objectives on schedule and within budget? When managing one such project for a large client, I was told that implementation on schedule would be impossible, even though development was on schedule. The client manager told me that never in the history of the organization had any project been completed in “less than two years behind original plan.” Of course, nobody believed that the system would be ready for implementation so nobody was prepared.

The project will not have unqualified support. Members of management may continue to oppose the project long after it has been approved. This opposition can be vocal and active or it can be simply refusal to cooperate in small ways which delay the project or damage its chances for success.

Given the structure of most organizations, these problems are impossible to deal with unless all involved parties report to the same individual. This individual must be committed to the project and be willing to demand cooperation.

In one organization I was involved with, absolutely nothing ever got accomplished unless one senior vice president insisted that it be done and commanded all the resources necessary to accomplish it. Cooperation across departmental lines was impossible — this was due in part to the fact that rivalries between vice presidents were at least tacitly encouraged by the president.

In another organization, the structure was such that no one person had the authority to make and implement even the most mundane decisions. The organization structure limited span of control. Members of middle management did not get ahead by making decisions which affected others (these decisions were simply ignored anyway) or by bringing issues up to vice presidents who generally did not have the power to deal with them effectively anyway.

Organizations are structured to allow, and even encourage, individuals to pursue independent courses of action. Where the organization does not have a clearly defined strategy and agenda, and feedback mechanisms in place to ensure that the agenda is followed, employees at all levels will adopt and follow their own private agendas. The organization may have many agendas and conflicting priorities. It is then left up to the individual to decide which course of action to pursue.

Politics is the name of the game in these organizations. Employees form temporary alliances and engage in horse-trading to get what they want. Cooperation is often secured by threats of exposure of errors or negligence.

The ability to accomplish anything in these environments is looked upon as “resourcefulness.” Individuals who are successful in spite of all the obstacles the organization presents sometimes reap benefits — usually in the form of an assignment to take on another project and go through all of this again. A danger is that in accomplishing things one may gore some sacred oxen, incurring lasting animosity and limiting future effectiveness.

Issues will arise of both support from upper management and freedom to act. It is wise to test this early but don’t feel that the results will be the same on every issue.

Other Priorities

Employees outside the immediate project team have other priorities. They will not be responsive within the requested time frames. Management may be unable or unwilling to deal with these issues.

Personnel may be asked to assume duties outside of their normal assignments in support of the project. They, or their management, may resist or give these duties very low priority.

A sure sign of trouble is the necessity for the Project Manager to negotiate agreements among these individuals for support.

Project Control Control is not firmly established, at any level. Several individuals may attempt to wrest control or test the limits of the Project Manager’s control. They may be unwilling, however, to also assume responsibility.

Attempts at control can be insidious. In one instance I was forced to deal with, an individual assigned to the project team on a part time basis set himself up as a conduit for communications between the project team and user management. He proceeded to provide both parties with false information about project activities. When this became known he then refused to cooperate further in performing assigned duties on the project.

“Turf battles” are common, often over seemingly small considerations, such as the control or use of a tool. Some individuals will insist that all communications go through them, restricting access to subordinates or other groups.

The assignment to perform a task, no matter how small and insignificant, is viewed as authority to withhold or delay performing that task. As an example, a clerk was assigned to enter contractor rates into the organization’s Payroll System. This was part of her normal job, she entered all employee pay rates as well. The clerk’s manager decided that he would “approve” contractor rates before allowing them to be entered, thus delaying the ability to hire contractors on a critical project.

Some individuals will insist on rigor when there is clearly no time for the desired level of rigor. While rigor may be waved in some quarters to meet the schedule, other areas may insist on following procedures or preparing voluminous documentation or justifications. Insistence on rigor may be viewed as lack of support, lack of confidence in the project team, or deliberate attempts to create obstacles for the project.

Project Management Approach

Every person has his or her own approach to project management. They feel free to criticize a different approach. Very rarely will anyone say, “What do you need?” or “How can I be of help? “, but many will feel free to say, “You’ve got to do this or that,” or “Unless you do such and so, the project is doomed.” The worst case is that management, through fear or lack of understanding, supports these views. Beware of instant experts, doomsayers and hip shooters.

Some members of the project team may be uncomfortable with a given approach, to the point where their performance suffers or the morale of the project team is undermined. This may be especially true of highly specialized disciplines, such as Data Administration or Quality Assurance. The Project Manager must be sure to “sell” the approach to the team. Good project team orientation is essential. Even so, there are some people who will not perform well on crunch projects. If possible, they should not be made part of the project team.

There will be pressure to proceed before sufficient understanding is obtained. Some people, usually members of management, will insist on a plan, schedule and estimates before the work is fully known. Or, they may insist on starting development without adequate design. You can’t plan what you don’t know, and you can’t accomplish what you don’t plan. The Project Manager must insist on adequate time to plan the project and top management must support the Project Manager in this regard. If this support is not forthcoming, the project is almost certainly doomed to failure.

Dealing with Outside Vendors

Outside vendors and organizations not under the direct control of the project team may not be responsive. They have their own way of doing business. Many vendors are not able to effectively alter their mode of operation on short notice. This may cause disruption and/or lack of cooperation. “An emergency situation on your part is not necessarily a crisis situation on my part.”

Vendors may also attempt to assume control of the project. They may wish to use their status to obtain additional work. Lack of responsiveness may be used as a tool in this regard.

Project Execution — Changing The Rules

Project requirements which should have been known out front creep in later. Ground rules have not been clearly set, and so they keep changing.

Standards which should have been established at project inception are imposed retroactively.

Staffing, equipment, work space, supplies, training, security access and support are poorly coordinated. The Project Manager can insist on certain things but execution is dependent on individuals and organizations outside the Project Team. Idle time is to be expected, and cannot usually be planned.

Personnel who are assigned “part time” and/or are not located contiguously with the Project Team may be unavailable even if promises are made. “Vanishing resources” are common on crunch projects. The Project Manager can carefully document these problems but may only reap enmity and further lack of cooperation.

There may be resistance to frequent status reporting. Feedback and control mechanisms are not always in place. Frequent status reporting is essential to the success of projects on a tight time schedule. Small adjustments to the plan are needed throughout the project if the overall schedule is to be met. Feedback must be timely and accurate throughout the project. Resistance to status reporting cannot be tolerated if the project is to be successful.

Informal agreements may be made to expedite progress but then may not be honored later. Lack of formal agreements may cause discomfort for some individuals. However, insistence on formal agreements may needlessly delay progress and create hostility and lack of cooperation. There is just no way to balance these issues with any degree of certainty.

At project inception, many short cuts may be taken, especially if individuals believe that success is problematic. Later, when success seems imminent, standards may be imposed which could jeopardize the very understandings that brought the project to the brink of success.

Summary — Project Success or Failure?

When the project is successful, those who did not believe it would happen and those who were unaware of the scope of the effort will not be prepared for implementation. This may cause significant delays and necessitate changes to the system. Political considerations can play a major role in determining when and how the system will be implemented. The Project Manager may still have to “sell” the project at this point.

There will always be those who will feel that their own interests (or the interests of the organization) are best served if the project fails. Failure is always possible if the Project Team is not diligent. Even the best systems can be undermined well after they have been implemented.

There are no easy answers for these problems, and maybe no answers at all. The best a Project Manager can hope for is to be aware of the problems and to make management aware of them as well. Management support in dealing with organizational issues will always be a major determinant of project success, especially on projects with tight time schedules.