You’ve got processes and documentation that prevent work being done.

You should not enforce documentation and processes that prevent the project being successful.

What is the point of a project failing or being unsatisfactory and you saying that
you have followed all the processes and have all the correct documentation in place?

Talk to your team, all of them; get them to tell you what parts of the process are
causing failures in the development life cycle.

The trouble is they may not tell you the problems. Your company culture and processes may have grown in to such a monster that it will discriminate against anyone that tries to challenge it.

Unhappy users

You have delivered complex functionality that is difficult to use, buggy, slow response times.

You MUST keep your end users involved at all times.

If not daily, then at least weekly.

Unable to respond quickly to changing conditions in your market.

This relates to several other points that I have already mentioned. Far to many people in meetings, common sense has left the building.

If you have got clean code that is automatically testable, it becomes quite straight forward for a Developer to add new functionality.

Unfortunately, before the decision gets anywhere near the Developers, people in higher places with little or out dated technical knowledge have decided that it is to risky to make any code changes.

When a business opportunity arises, have a quick chat with a few relevant Developers and get a real feeling of what is possible and what the risk is.

Don’t spend thousand of pounds having top level meetings and getting a Business Analyst to write a spec that the Developer then has to give estimation on. If you do that then the business opportunity may have passed. This links to the common theme of communication. You have got to involve everyone.

Changing existing functionality and adding new functionality is now really easy and safe if the software has been developed to be automatically tested.

Smaller companies are taking your business.

Smaller companies naturally know that they cannot afford to do the money wasting things that large companies do. Large companies seem to lose a large amount of common sense when it comes to software development projects.

Create small units, teams, departments. Give them a budget and let them develop the software as if they were a small company.

The project does not meet it’s expectations

You deliver a project and the end users are reluctant to use it, don’t like using it or say that the old way was better.

What? You’ve just spent £2,000,000 on a project and the end users say the old way was better! I think that’s a good indication that your existing development techniques need a complete overhaul.

I don’t care that you are following some prescribed system, following the rules. If your end users do not like the system them you have messed up in a big way.

Unhappy developers

Developers can be un-happy because the project has somehow got into a state where they are not even asked to contribute how to solve problems. They have somehow become second rate citizens in the project. If that has happened in your project then don’t expect a very successful outcome.

If developers are just turning up for work to do what you tell them to do so they can collect their pay, then you have big problems. Successful software development depends on having people who care about every aspect of the process.

When an unhappy developer spots a problem he will keep quite. He’ll say why should I bother about it. It will only create more paperwork, more reviews, more blaming. So the problem remains in the system.

A happy developer who cares about the end product will do all he can to resolve all potential problems.

Silos of knowledge

Set up a knowledge sharing system that is easy to you. It must be quick to use, and be used by everyone in the team. (Unfortunately there are many cumbersome systems that end up being partially used, which is a waste of time).