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.

References

Strong's Lexicon: http://bible.crosswalk.com/Lexicons/Hebrew/

Published Sep. 1, 2002— Reads 18,396 — Feedback 4
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Jason Bell
Jason Bell is founder of Aerleasing, a B2B auction site for the airline industry. He has been involved in numerous business intelligence companies and start ups and is based in Northern Ireland. Jason can be contacted at jasonbell@sys-con.com.