06.22.04
 By
Paul Glen
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:
| Convert
your keywords to sales! Try Urchin for free - Download
Now |
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.
(This article originally appeared in Computerworld USA.)
About the Author:
Paul Glen is the author of "Leading Geeks: How to Manage and Lead
People Who Deliver Technology" (Jossey Bass Pfeiffer, 2002) and Principal
of C2 Consulting. C2 Consulting helps clients build effective technology
organizations. Paul Glen regularly speaks for corporations and national
associations across North America. For more information go to http://www.c2-consulting.com.
He can be reached at info@c2-consulting.com.
Read this newsletter at:
http://www.itmanagementnews.com/2004/0622.html |
|
 |
|
