I’m frequently called upon to help figure out what to do with a project that might be in trouble. Of course, determining whether a project is in trouble is often not a trivial problem. We like to talk about troubled projects as if there were a single bit that visibly flipped from one to zero, but unfortunately it’s not that easy.
While the symptoms presented vary widely, there are a few questions that I always ask to help determine whether the project is indeed in trouble. Some questions are deceptively simple with surprisingly subtle answers. Perhaps the most important is, “How will you know when you’re done?”
One thing that all projects have in common is that they are (or at least are intended to be) temporary. They should have a conclusion. So theoretically, this should be a rather easy question to answer, but it’s usually greeted with blank stares followed by one of four standard responses:
Response 1: “We’re done when the quality of the product meets our standards.” This is the idealistic response, the “we’ll sell no wine before its time” approach.
Response 2: “We’re done when the product fulfills the requirements.” This is the legalistic response, the “we’re done when we’ve completed the minimum required by the letter of the law” approach.
Response 3: “We’re done when we reach the schedule deadline.” This is the schedule-driven, pragmatic response, the “we’re taking it to the trade show whether it’s ready or not” approach.
Response 4: “We’re done when we run out of money.” This is the budget-driven response, the “our CFO won’t give us any more money, so we’d better just roll it out” approach.
Unfortunately, none of these responses captures the subtle reality of IT work. We don’t have a simple answer to the “What does ‘done’ mean?” question. We don’t have a physical product with physical properties. It’s considerably easier to discern when a bridge is done. Does it span the gorge? Is it painted? Will it withstand the traffic we anticipate for it?
For IT projects, there’s only one real way to tell when a system is truly done. That’s when all the stakeholders in the system agree that it’s done. Each group must certify that the project sufficiently addresses its concerns. Among other criteria, they must agree that the project meets enough of the requirements, is ready when necessary, is deployable, is supportable and will be accepted by the users. In short, in the absence of physical evidence of completion, “done” is fundamentally a political decision, not a technical one.
A different yet related deceptively simple question is, “Do you think that the team has the skills to complete this project?” This one is usually answered with a list of the technical skills of the team members.
Of course, technical skills are important for getting to done, but clearly they’re not sufficient if we understand that “done” is defined politically, not technically. There are other equally important skills for building the consensus required for success. They include the following:
Listening. Do the team members have the ability to listen carefully for both technical and business requirements? Can they hear both the issues and the feelings that surround those issues? Can they confirm what they hear to ensure that they haven’t misunderstood?
Identifying interests. Do the team members have the ability not only to hear what the stakeholders are saying, but also to anticipate and interpret their interests? Can they understand what may be driving the requests and demands that they hear?
Managing constructive conflict. Does the group have the ability to engage in the constructive conflict required for building consensus? Can it deal with the conflicting demands of stakeholders? Can it reconcile the emotional needs of stakeholders?
Negotiating trade-offs. And finally, can the team manage the negotiating process required to build consensus? IT projects are now the gridiron on which corporate politics are played. As systems become integral to business processes, turf battles may be negotiated during the requirements and acceptance phases of projects.
So when you contemplate your next project, consider not just the launch of the project, but how the team will get to “done.” When you think about the end first, you’ve got a better chance of getting there.
Paul Glen is an IT management consultant in Los Angeles and the author of the award-winning book Leading Geeks: How to Manage and Lead the People Who Deliver Technology (Jossey-Bass Pfeiffer, 2003; www.leadinggeeks.com). He can be reached at info@c2-consulting.com.
