According the Standish Group, 84% of all IT-related projects are not
delivered on time or within budget. Now when the world reads "IT-related projects," the automatic assumption is that the IT department is to blame.
Further investigation reveals the main reasons for failure: inadequate
requirements and lack of client/user input. I've worked both extremes: I've
written functional and technical specifications and the client has responded
(via the project manager) that the specs were like "a sledgehammer to crack
a peanut." If this is the client's mentality, you'll encounter trouble.
On the opposite side of the coin, I've received specs from on high that
were completely unreadable or made no sense at all. When it came time to
deliver, the client said, "Well, I actually meant this." My favorite was the
client who said, "I don't understand what I've written."
Are we programmers that unapproachable? Is it our armpits? No, it's a
lack of basic communication. Managers feel they want to try and talk
"techie" to us so we might understand what they're saying. What we really
want is an English (or insert your native tongue here) description of their
aim and vision and some basic requirements. Then we can come to some
agreement on functional specifications.
What worries me is that when managers of different companies talk
together, a common question will crop up: "Does your IT department deliver
on time?" The response will usually be, "No, we leave them to it; we dare
not approach them!" Have I hurt your feelings yet? No? Good.
Perhaps it's time to teach. The word teach is an interesting word. The
usual dictionary references are fine, but if you look at the Hebrew
definition it means, among other things, to "shoot arrows" (Strong's number
03384). You need to be pretty direct when trying to get your point across.
Not everyone is a teacher so it's always handy to have someone who can
present the idea quickly and concisely your managers will have more faith
in you and your team. Get to know your team, know each member's strengths
and weaknesses. Yes, they're all great programmers, but who communicates the
ideas the best? Who is the visionary? Who keeps everyone focused on the
light at the end of the tunnel?
If you don't use a software development methodology, you should start;
it doesn't matter if it's UML, Extreme Programming, etc. You don't have to
take the whole method as gospel, but the more you can plan out and see the
risks and communicate those risks to management, the better. Highlight the
major problems and sort them out straightaway.
Another thing I've found handy is to deliver the project to the client
frequently throughout the project's timeline. I started doing this after
talking to other developers. They would create the application with limited
or no functionality and keep delivering it on a regular basis. This creates
a sense of trust with the client that something is actually happening. The
client doesn't have to wait until the last quarter of the project to
actually see something half working.
I've had to look at my track record and say, "Hey, I could have done
that better." It's all about personal as well as team development. Over the
years I've made a mess of estimating projects sometimes it was due to bad
requirement specs and sometimes it was me. Our office now has a motto
"Woolly specs = woolly deadlines."
Feel free to let me know how you get on. Until next month.
The Standish Group:
Strong's Lexicon: http://bible.crosswalk.com/Lexicons/Hebrew/
Jason Bell is a programmer and senior IT manager for a B2B Web portal in
York, England. He has been involved in numerous
Web projects over the past five years, the last two of which have been