Free Article By Paul Glen of C2
Consulting
Every month we add to this collection of articles from the free monthly
newsletter IT Professionalism.
You are also free to print these articles in your newsletter or magazine if
you follow our Reprint Policy.
To subscribe to it, click here.
Getting to Done
(This article originally appeared in
Computerworld USA.)
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.
