Top 6th

Letter to the Business Sponsor from an IT Professional

Congratulations. You will be sponsoring the next big project for your organization.

The business of creating systems has been in a crisis for a long time and is showing no signs of improvement. The Standish Group reports that 84% of development projects fail to deliver on the desired objectives. Career Russian roulette with 5 of the 6 chambers loaded!

Like Tolstoy’s unhappy families, every project failure is different. The media have been documenting horror stories of the more spectacular failures. There are blogs who compile the more public failures. They make compelling reading if your project isn’t the one being written about. For every project that is publicly noted, there must be perhaps 20 that are not. The costs are measured in dollars, of course, but also in careers and, most importantly, in lost opportunities. The FBI Virtual Case File project, for example, cost money and careers and we can document those costs. It also jeopardized our ability to counter terrorism – how do we calculate that cost?

I have been fortunate to have been associated with both kinds of projects – successful and not. Here are some observations that may help your project be among the top 1/6 that do. Take it for what it’s worth. As a professional, I find it unacceptable that our odds of success are so low. I have a responsibility to try improve them.

A number of the horror stories document changing requirements, poorly understood requirements, scope creep. The creation of functional requirements is the first challenge. For a successful project, the functional requirements have to be SMART. It doesn’t matter if they are in the right format. It matters if they are Specific, Measurable (or testable), Achievable, etc. Yes, that means detailed but if the description of a proposed system is nearly a thousand pages long, who can tell how SMART they are? Even so, writing functional requirements is something that many a project has mastered and still failed at delivering.

The creation of non-functional requirements – performance, scalability, security, availability, service levels – is a larger challenge because they are not always articulated or understood. Most organizations have well defined processes for signing off on functional requirements. Not so for NFR. The business side wants 24×7 availability; the technology side knows that can’t be achieved but the project hasn’t been developed yet so they don’t know what can be achieved. The result? It’s not discussed. It’s not in the requirements at all!

Dear Business Sponsor: you will have to ask for performance goals, security goals, availability goals. You will have to make sure the goals are SMART. There will be much resistance:

• How can we say how fast it will be – we don’t even have the requirements yet.
• We don’t know how the users will use the system – how can we predict how heavy the usage will be?
• We don’t know how much staff we will need to service the system – we don’t know how often it will fail.

Projects sometimes succeed without paying attention to non-functional requirements but only if they are very lucky. And we know, luck won’t put your project in the top one-sixth. The creation of the right organizational culture is perhaps your biggest challenge. How prepared is the organization for dealing with setbacks? There is an insidious quality to bad news: it’s not definitive in the early stages. Your architects can give you their conclusions but they will be ambiguous. The system won’t have been built yet and it won’t be provable that there is a problem. By the time it is fully built, it will be too late to take corrective action.

Will your organizational culture allow you to get early warnings? Will you be able to act on them? The success of your project depends on it.

Copyright © 2008 J Singh