I learned an important lesson in my IT career years ago, when I accompanied a veteran colleague to a project kick-off meeting. Someone else was in charge, but my colleague took advantage of a brief moment of silence at the beginning of the meeting.

"I thought it would be useful," my colleague said innocently, "if we could agree - before we get into all of the technical details - as to how we would recognize whether the project has succeeded."

Several people in the room cleared their throats in preparation for long soliloquies on the True Meaning of Success. But before anyone could start, my colleague charged ahead with another observation.

"Actually," he said, with the same air of innocence, "I think it would be useful to begin by asking who is allowed to declare success."

Another moment of startled silence, and everyone turned expectantly to the manager who had convened the meeting and who was presumed to be in charge of everything.

To his credit, this manager responded by saying, "I'd like to say that I'm the one who declares success or failure, but the truth is that if Fitzgibbons [not his real name] in finance doesn't like what we're doing, he can pull the plug on this project anytime he wants."

This was apparently news to several people sitting around the table, for the shock was evident on their faces.

"Well, what about Mr. Harrison?" my colleague asked, referring to the CEO with the respect and deference that indicated that Harrison (not his real name) was just as powerful as his title implied.

"Oh, well, Harrison can kill the project too," the first manager replied with a shrug. "But this project is a real hot potato, and half of the board isn't sure it's a good idea. Harrison doesn't have the power to defend this project single-handedly, nor can he unilaterally declare it to be a success."

After a little more discussion, it became evident that we had all signed up for a project whose success couldn't be guaranteed by any one executive, but whose failure could be decreed at a moment's notice by a half-dozen stakeholders.

And that led us back to my colleague's first question: What would be the criteria used by these people to decree success or failure?

It didn't take long to arrive at another set of political realities: None of the power-wielding executives cared at all about maintainability, portability, reliability, flexibility, user-friendliness or any of the other aspects of "quality" that the IT professionals cared about so passionately. None of them cared whether the technical work was worthy of the ISO 9000 and SEI CMM certifications that the IT department had worked so hard to achieve.

The system's functionality was important, but there was a consensus among the meeting's attendees that the key stakeholders were pragmatists in this area: If we remembered the Pareto Principle and delivered the key 20 percent of functionality that provided 80 percent of the system's benefits, we would be safe.

As for budget, our official-but-powerless manager explained, "If we go more than 20 percent above our budget, Fitzgibbons will pull the plug. Otherwise, it doesn't matter."

And on the all-important issue of schedule, we learned another reality: "No one believes we're going to come anywhere close to the official schedule; they keep talking about it just to maintain the pressure on us. But if we don't get this system finished by the time we go out for our next round of [venture capital] funding, then we're toast. Harrison will cancel the project, and he'll personally fire every one of us."

To manage a successful project, there's a lot of detailed, day-to-day work that must be done.

But you would be amazed how many intelligent, experienced managers never ask these two fundamental questions at the beginning of their projects: Who has the right to declare success? And what are the criteria that will be used to determine success or failure?

Your don is the editor of Cutter IT Journal, published by Cutter Consortium in Arlington, Mass. Contact him at www.yourdon.com.