Why Projects Fail: The Island Problem

Projects fail. Some are completed too late, some cost more than planned and some produce results that are not used by anyone. The project members are motivated and the world’s best tools for Requirements Management, Project Management or Bug Tracking are available, and still it happens. Sound familiar? The conditions are excellent, but operations do not run smoothly. Communication is difficult. It feels like you are rowing and rowing, or rather flailing about in desperation.

The Island Problem

Imagine a “traditional” project. A number of colleagues, different roles, some existing specialist tools for project planning, Requirements Elicitation and Management, Test Management or Time Recording. Of course there is the management requesting constant status updates on milestones.

You begin to plan the project. What requirements are already there? A colleague provides you with the necessary information or goes over the information together with you. Did the client already submit changes? What about the Risk Analysis we talked about? By the way, where is the project proposal? You begin to look, to ask, to coordinate and to compile data.

Change of scenery. For each field you use a well-proven software tool. For Project Management. Requirements Management. Change Management. Reporting. Time Recording. Image that each of these tools is an island. You row from the Island of Project Management to the Island of Requirements Management. On your way back you make a detour to Change Management. But wait, new information is available on the Island of Quality Management. You are already exhausted, but well…

Now imagine there are a lot of boats.


I, rowboat. I may not injure a project or, through lack of flotation, allow a project to come to harm. – First Law of Rowboatics¹ ² (altered)

The Expensive Approach

An infrastructure created from a variety of tools is not uncommon. The question is: How is data transferred from one system to another? Another one: Who takes care of the interfaces? A variety of tools means a variety of tool manufacturers, each with their own release strategy. And using more than one tool by a manufacturer does not guarantee efficient interfaces. The result: Updates have to be installed carefully in order to ensure that everything works as it did before the update.

Your users are faced with the task to master different operating concepts. Oh, right, testers only use one single tool. Off to the Island of Test Results, are we?
Another tiny detail: Individual software tools have to be paid for individually. Maintenance of interfaces has to be. Effort for the compilation of information on states and all other relevant project information has to be.

Leaving the Rowboat

Are there ways to solve the Island Problem? Yes, there are.

Processes make operations consistent. You are still rowing, but with a plan. The distances are still vast, but you are more focused and communication is easier.
It is, therefore, particularly important to improve aspects that are not primarily the focus of projects but that are essential for the success of projects: an integrated infrastructure for all project contributors, and processes that support each and every one in their work.



[1] http://www.theonion.com/articles/i-rowboat,10875/ last retrieved August 28, 2014.

[2] Asimov, Isaac: The Three Laws of Robotics last retrieved August 28, 2014.

Michael Schenkel believes in useful tools, that support users in their work and that provide a common working environment for all types of roles in a project. He became a member of the microTOOL family more than fifteen years ago and took over the position of head of marketing for about half a decade. In October 2017, he moved on to a new adventure and we wish him all the best on this new path.

EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *