3 tips to avoid your project crashing in the "IT Bermuda Triangle"

The Bermuda Triangle is a part of the Atlantic Ocean that stretches from Bermuda in the north to the southern tip of Florida and Puerto Rico in the south. Aircraft and ships are alleged to mysteriously disappear within this triangle – victims of some unidentified force (or so the legend goes).

Every corporate IT project passes through its own version of the Bermuda triangle. This is where even the best projects can crash and burn.

This triangle consists of cost, timeline and scope. In many cases when these forces intersect – for instance, when scope is sacrificed for cost or timeline - IT projects end up being rolled out and deliver less value than expected.

Here are a few tips to navigate through the triangle and ensure the best in class processes you have developed survive this turbulent environment.

Don't let your IT project end up like this...

Tip #1: Don't buy the dream:

In the beginning most projects focus on scope. Project approval requires features to deliver enough value to create an attractive ROI. This is needed to justify the cost of the project.

It's also a false promise.

The expected ROI, feature set and estimated costs are all required prior to starting the project. This means they are compiled with limited funding and an even more limited understanding of actual implementation costs.

In addition, these projects are almost always replacing a legacy tool which means there are minimum standards that must be built before you can even consider enhancements. The minimum requirements usually eat up most, if not all, of the costs.

To combat this, be pragmatic. Identify 3-5 key pieces of functionality that will truly add value and go deep to ensure the scope of the project can cover the technical costs. It's likely only 2-3 of these will be possible but as long as you have them in hand and ensure they are implemented you will keep some semblance of value when the project runs up against inevitable cost and timeline pressure.

Tip #2: Set clear expectations with stakeholders:

Companies like to lock in the cost of their projects at the beginning which is challenging because you don’t understand true costs until you get into the details. The trouble is that, not surprisingly, leaders hold tight to budgets so it's likely what you were given up front is all you are going to get.

For that reason expectations are extremely important. Large projects are problem magnets. The longer they last the more solutions get attached to them. Pretty soon the project is curing world hunger!

Fight hard to keep expectations in line, or at least a little lower than what you know you can deliver. Replacing legacy tools is painful for everyone. You need people to go in with the right expectations if you're going to succeed in the long term.

Meanwhile, big tools require massive organizational change, which is hard as most people are naturally averse to doing things different. Don't give them a reason to say "I told you so". If anything, have them expecting extreme pain and then make it a little easier.

Tip #3: Sacrifice preparation for iteration:

Keeping to agreed timelines for large IT projects is always a challenge. To make the most of your time, focus attention on the right segments of the project.

For instance, too often teams spend months putting together massive documents covering every aspect of the tool. If you are doing this you should stop. Now!

I've seen companies spend a lot of energy putting these documents together. Then they lock the specification based on documents they created years ago only to have the processes no longer valid.

Spending less time up front and more time iterating will ensure you deliver a relevant tool. AGILE, done correctly (i.e. not used as an excuse for avoiding any specification of any sort), is a great method for developing in this fashion. Usability is the key to a successful tool and that only comes through iteration. If there's anything you should fight for, this is it.

New tools allow for much more flexibility because they are cheaper and take less time to develop. However, big projects are still the norm in business today so it makes sense to be prepared. Also, many organizations who have not adapted to the simplified workflows enabled by new tools will implement them using overly complex legacy methods.

Focus on these three things and I hope they will help you navigate through the Bermuda triangle and successfully deliver your project.

But what do you think? Is there an IT Bermuda Triangle? What are your tips to keep your IT project on track?

[eventPDF]