More IT projects are considered a failure then that are considered a success. We know that for a few decades now.
It-professional published an article from Jan with the title it-failures what are we doing about it?
I’m personally convinced that not Technology but Communication is at the root cause of most of the failures.
No Communication, Bad Communication, political games (Yes I call this also communication.)
I agree with Jan that some stakeholder have a (personal?) gain to some of the failures. On top of that, it is easier to make something fail then to make it succeed. For me this is also a communication problem. At the start of a project we should take more time to make sure that all the different stakeholders share a vision about the project. Yes it takes time. Yes it is expensive. A failing project is much more expensive.
LinkedIn I asked “Does a team need a shared Vision?”. There were some cultural difference about the meaning of “Team” and “vision”, but I think most people agreed that a shared vision is Crucial for the success of a project.
On top of that I believe that the “agile way of working” (I’m reluctant to use Methodology here, because of the connotation a lot of people have with the word methodology) has an answer to most problems Jan is talking about.
Small iterations: We deliver working software every X weeks (Typically X= 2 or 4)
At the end of these 2 weeks every stakeholder can (and should) have a look at the software to see if the software is moving in to the right direction. If the features that were agreed on, are writing the way they are expected.
Retrospectives: At the end of an iteration we take the time to look and see what went good, what went bad. So we have the possibility to correct.
(In most It projects we have a post mortem at the end. To see what went wrong, without a possibility to correct. )
TDD: Test Driven development/design: Developers first write a test, and then only write the code. This is the only way to know that all the features that were working last week, still work.
Deliver the most important features first: We ask a project owner, proxy customer to make priorities. And most of them don’t like it. As it is very hard. I tell them that it is as hard for the developers as for them. But if the developers make the selection, they have a different selection criteria. (They might select on newest technology, easiest, hardest, best for their CV, working together with a colleague, avoiding a colleague, fun, …). The team will typically work on the most important features for the next iteration. This way it is possible that at a certain iteration, management decides that delivering the next points down the list delivers less value then the cost of the development. And we stop the project as a success.
Plan for adapting: Jan gives an example of a project that was build within budget, delivered as planned, but totally not used. For me that is a bigger failure then a project that did not follow the project plan but is used a lot. Most people I know that build a house have NO idea what they want. And that is after living in houses for at least 20 years. Why do we keep thinking that software end-users know any better what they want? Almost all the people I know that have build a house have changed part of their plan while building. Sometimes these changes are expensive. The people know that and find it OK, as they know the result will be way better. The people that have not done the changes have regretted it.
I still want my developers to work in peace and not having to deal with changes every day. Scrum offers a nice mix for both sides.
During one iteration we do not allow changes to the plan. If it is something big and important we can give it a high priority next iteration. (And even there we have rules for the exceptions.)
The agile way of working will NOT solve everything, actually it will make existing problems much more visible. And based on that visibility one of the possible decisions could (and should) be to stop the project. Again a failure, this time a less expensive one.