"If you don't have time to do it right, when will you have time to do it over?" I internalized the message on this sign in my high school chemistry class. Cutting corners and skipping steps saves you time today, but often you pay a much greater price farther down the line when fixing the problems caused by haste.
This is especially true in our industry. Overworked software people often push back against suggestions of actions they might take to improve their chances of project and organizational success. They protest, "I'd really like to do that and I know I should, but I don't have time." But what's the real message? Let's see what the refrain of "But I don't have time!" might really mean.
"But I don't have time to hold a retrospective," declared the manager of a recently failed project, when my colleague suggested that it might be a good idea to reflect on what went wrong before they launched a second attempt. You could realistically interpret this message as, "We must get started on the next project immediately because it will take us so long to recover from making those same mistakes again."
"But I don't have time to identify risks and decide how to control them," another manager complained. He might have been thinking, "None of the bad things that happen to other people will happen to us." Hey, the risks are out there whether you choose to look for them or not. My personal preference is to fill in those parts of the map that are labeled "Here There Be Dragons."
I know someone who begins every new project by studying his organization's "lessons learned" repository. Then he charts a course based on the footsteps of those who have passed before. A project manager who doesn't have time to peruse the lessons learned has opted instead to wrestle with some of the same problems that previous managers have experienced.
You might have heard a manager say, "We don't have time to write a requirements specification." This person is relying on a mind meld to substitute for oral and written communication of the new system's requirements. The translation might be, "We need to start coding immediately so we have time later to change the system to really satisfy the users." This just doesn't seem efficient to me. Similarly, some customers resist participating in requirements elicitation, proclaiming that, "I don't have time to talk with you about my requirements. You should already know what I need." The clear message is, "The developers can use telepathy and clairvoyance to understand my business needs. If they miss the mark, I'll straighten them out after I see what they build as their first guess." You're going to get the customer feedback eventually. It's a lot less painful to get it before you've actually delivered the product.
"I don't have time to do a technical feasibility evaluation," argued the harried developer. What he meant was that he would find plenty of time to rearchitect the system later when he couldn't satisfy the performance requirements. "We're doing rapid development here, so I don't have time to document my designs and code," is another developer mantra. Amazingly, maintenance staff (who are sometimes also the original developers) always seem to have time to reverse-engineer the design and requirements from the code when they have to make a change.
I get nervous when I hear a developer say, "I don't have time to do a bunch of design work. I need to get something running right away!" Could she really be