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).

Lack of Communication

You all need to work closely together on a day to day basis.

You need to have feedback, ideas and constantly change your decisions.

When people have to communicate via telephone or email you will have introduced another layer of weakness into the project that may contribute to the project failing.

Relying on Business Analysts

To all BAs, I am sorry about this observation. It’s not personal, but you have been given an almost impossible job.

As an IT Director or Manager, you may think that your Business Analysts are one of the most important links in the whole software development phase.

You allocate a large proportion of the budget to them to produce highly detailed documents. But these details can only be as accurate as the customer has been able to describe their needs at the time the requirements were gathered.

What you may not be aware of is that it is quite often left to the Developer to finalise and correct those business requirements and business specification documents.

Let me just repeat that you spend a large proportion of your budget on Business Analysts, yet the Developers frequently have to correct the documents.

When a Developer has read one of these highly expensive documents, he will quite often find mistakes and anomalies in them.

“Do you really mean this”, the Developer will say, “oh no I don’t” says the BA.

The Developer will point out that certain scenarios have not been considered.

The Developer will point out that there are better ways of doing things at a far lower cost.

The Customer will say, “That’s not what I wanted”.

Manually testing everything

You have got to have some sort of automated testing. I find it totally unacceptable that a bug is fixed, but unknowingly another part of the application has been broken.

Your Developers must have some sort of mechanism where they can fix a bug, change existing functionality or add new functionality and be 100% confident that some other part of the system has not been broken.

Suffocating your users

Stop being obsessed with users not being allowed to request or suggest changes.

OK, you’ve got to have an overall goal, an overall plan. But let the users and Developers deal with the actual detail of how your goals are achieved. For example, it is sufficient to state “that you want the public to be able to securely log into the system and view past orders.” Don’t start created long winded documents.

Don’t put a change control mechanism in place that stops users thinking of ways of improving your products.

Insistence on implementing 100% of the features before doing a release.

Work on the top 20% features. Quite often these features will give 80 % of what the end users want. They can get using the system far quicker and start adding to the profitability of your company.

What’s amazing is that these top 20% of features are often well known, easy to describe and test. Concentrating on these features can kick start your project. Keep the users closely involved as each feature is developed. When a useful set of features is fully ready do a release. Yes that’s right a release as soon as possible, let the system be used in a live environment. Design problems can then be caught at an early stage in the life of the application.

Develop some more features then do another release in a month or two. Doing this means that the users and business community do not get big surprises. More importantly they are not left with an unusable and unwanted system that cost you millions to produce.

When you have completed the first set of 20% of features, move on to the next set. In all probability, feedback from the users will cause the features to be altered in priority or not required at all. You’ll have saved a great deal of time by not have written a detailed set of requirements.

You also avoid the situation where so much time has been spent on gathering requirements, documenting and reviewing them, that they must be implemented no matter what. So even though the user has discovered that a feature is no longer needed, the momentum of the project means that it must get implemented. That really is stupid.

Trying to fit a square peg in a round hole

You can do it, but something will get damaged in the process.

Price, Features, Quality, Time. Something has to give. You decide which. But please do not add more features and then expect Price, Quality and Time to remain the same. You need to give and take

If you add more features, extra time will be required, unless somehow you can reduce the quality. (Don’t even think of that!)

If time, price and quality are fixed, then the number of feature you have in the product will be reduced.

Failing to let the application evolve

The end users of the software do not have a perfect idea of what they want. They have a high level idea about the main feature that they need. Stop trying to get the users to specify every little bit of detail. It is very hard to do that and for very little benefit.

Just gather the top level requirements. Let the Developers build something that the users can experiment with. Quite often the users will then think of new features of greater benefit to the business, and also they will discard other ideas that in the beginning they had though were of high importance.

Big teams mean communication is more difficult

Big teams mean communication is more difficult.

Associated with smaller projects are smaller teams. Small teams make communication far easier. Decisions are easier to make. Let the small teams work in a fashion that suits them. Do not impose a 'one size fits all'. Success does not come from being constrained to walking down the same path as everyone else. Let teams wander off the path and take responsibility.

Don’t read that as a recipe for chaos. The team can still work to company standards and procedures.

The team can still work within CMMI if that is your company policy.

Having a process that does not allow people to make mistakes

Mistakes are a way of learning

There are software development techniques that are focused on getting it right first time. This is really difficult to do. Very expensive in terms of time and the people in your teams are always triple checking everything so that they do not get the blame some something.

Why not aim for nearly right first time? It will be quicker to get to that point. You’ll make a few mistakes. But these so called mistakes are a great discovery process and will lead onto a superior solution. If you start blaming people, they will clam up, they will suppress their creativity, they will be clock watchers, and they will be looking for work elsewhere.

Big projects lead to failure

Big projects turn into NASA type projects; you just do not have the size of team and infrastructure to support that sort of project.

Make your projects smaller. Instead of the big bang £10,000,000 projects that usually go wrong, concentrate on smaller projects. Obviously these smaller projects are done with the bigger picture in mind. These small projects can then be completed in two to six months. From concept to completion.

You’ll need to allocate a business and technical roles to manage the big picture, particularly technical interfaces.

Delivering real useful benefits to your customers. You could do projects that deliver the top 5 business features that are needed right now. These features will have an immediate effect on your profitability and move you ahead of your competitors.

A small project means that you will probably complete it satisfactory. This gives a great deal of team satisfaction and this enthusiasm feed into the next project.

Big projects are difficult for people to associate with.

Not involving users in the development process

These may be external users of the application, or end users within your business.

Keep the end users constantly in the picture. Do this by involving them on a day to day basis. Do not do the insane development technique of working for 8 months and then finally introducing the application to the users. They will not like it, whatever it is.

Show them early versions of the software. Let them use it. Let them give you feedback, and above all, let them change their minds without being punished. Look this is about making your company profitable. Trust your end users; they know what works and what does not. Keep them involved and allow them to contribute to the design.

Requiring everything documented to smallest of detail.

Stop trying to document every miniscule detail in an effort to prevent failure. You are guaranteed failure if you try and create documents that describe everything, quite simply you run out of time to do any high quality development work. You discuss the project, you document it, put in controls, discuss it, document it more, prioritise and re-prioritise, then at the end you want your Developers to finish the whole project in just an impossible 2 months.

In a lot of cases, a high level description in just a few paragraphs is sufficient and gives you the flexibility to change your requirements. When a task is allocated to a developer, the developer can discuss the detail with the users and business owners.

Here’s an analogy. Many large software projects often have more parts than a car. And certainly the parts in a software project will have more complex interaction than the parts in a car.

Suppose you were asked to document all the features that you needed in your ideal car. You also have to describe how all the parts fit together, describe the material and metal to be used. Specified the size and type of every bolt. You would probably take a very long time, then end document world probably be wrong and lack many of the feature that you want.

And because of your complex and rigid change control mechanism you cannot accommodate changes along the way.

A car is fairly simple to understand compared to a complex business application. Yet you regularly try and produce highly detailed requirement and specification documents. That’s crazy.

How about specifying some top level requirements?

So going back to the analogy of the car.

Needs it to run on green fuel.
Needs to be four wheel drive.
Be good if backseats folded forward.

Those brief descriptions are enough for everyone to understand where the project is headed. It means that actual work of creating the application can begin far earlier. Just imagine if you had to produce all the detail of how a seat folding mechanism should work. It would take weeks. Weeks that could be used in getting the project started.

The actual detail can be thrashed out at the time that it is needed. Perhaps you can call it “Just in Time Design”

This Just in Time design technique allows for something that always happens on Software Projects. Users changing their minds and thinking of new requirements. It always happens, it’s good, so why not cater for change? In the case of the car, the user may decide that he know longer needs the rear seats. Thus you have not wasted any time in doing a detailed design.

To many people in meetings

You have meetings where quite often eight or more people are invited to attend and discuss and make decisions on a wide range of issues. That is a complete waste of time. Usually nothing gets decided and the meeting ends with even more problems being raised and confusion from people who are not directly connected with certain issues.

There are a lot of issues that can be quickly discussed and resolved just by 2 or 3 people. If it’s a technical issue, then have that meeting at a Developers desk.

If it’s a usability issue then get to the desk of the user for a demonstration of the problem.

Introduction

In this blog I will be describing practices in Software Development Processes that appear to be damaging to the project.

I'll also be describing any solutions that I know for those mistakes.

Please contribute your own thoughts. I am not a Guru, just a normal Developer who observes that lots of money is being wasted in many software projects.