It’s an all-too-common story in modern software development. Someone had a good idea for a piece of software that would provide real value to a business. The programmers are working hard on the code. They are implementing what they believe will best suit the users. And yet, while they know they’re going to ship some software in the end, they also know the project will fail because that software doesn't do what the business needs it to do. It reminds me of Tennyson’s “The Charge of the Light Brigade.” See if you can tell why in this stanza:
"Forward, the Light Brigade!"
Was there a man dismay'd?
Not tho' the soldier knew
Someone had blunder'd:
Theirs not to make reply,
Theirs not to reason why,
Theirs but to do and die:
Into the valley of Death
Rode the six hundred.
The poem is an account of a Crimean War battle in 1854. The commander of the British forces gave an order for the British light brigade to attack what was supposed to be a retreating Russian artillery unit. But because of breakdowns in communication, the light brigade ended up mounting a frontal assault on an entrenched Russian artillery unit instead. It was a suicide mission—and the soldiers must have known it. But they charged anyway. 
As with many software projects, the charge did not fail due to any incompetence on the part of people on the front lines. In fact, it was the soldier's valor that inspired Tennyson's poem (and an Iron Maiden song). Nor did the charge fail because the command was bad. The charge failed because the cavalry attacked the wrong position.
Software projects staffed by talented developers have failed for a similar reason. The software solved the wrong problem. In addition to developers who produce good code, a project must have good communication and proper visibility if it is going to succeed.
Sometimes programmers think that a project will be successful if they fully implement what was prototyped or specified in the requirements. But the truest measure of success in a software project is the value that it ultimately provides to the users.
As Fred Brooks writes in The Computer Scientist as a Toolsmith:
"If we perceive our role aright, we then see more clearly the proper criterion for success: a toolmaker succeeds as, and only as, the users of this tool succeed with his aid. However shining the blade, however jeweled the hilt, however perfect the heft, a sword is tested only by cutting. That swordsmith is successful whose clients die of old age." 
The main cause of failure in the Charge of the Light Brigade was a breakdown in communication. A great distance separated the commander who ordered the charge from the cavalry that carried it out. He gave a vaguely worded message to one of his assistants, who relayed the verbal order to a messenger who took it to the divisional commander of the cavalry. The divisional commander then gave instructions for the charge to the leader of the light brigade.
The commander gave a command that may have been obvious to him from his vantage point. But it was not detailed enough for the other officers to execute properly. The lack of clarity isn't the only reason for the failure, but if the order had been more explicit, the failure would have been avoided.
Software projects can also falter when there is a lack of detail. A user story or requirement that is obvious to a stakeholder might be misleading to a developer. This is especially true in cases where there are industry-specific meanings to certain terms. In the same way that software developers have a specific understanding of the word “release,” other businesses have specific terminology as well. The team must take steps to ensure the requirements are clear to all members of the team, not just the person who wrote it down.
The lack of detail was the first part of the problem, but the failure could have been avoided if there had been good two-way communication.
Maybe the biggest problem was that all of the communication was in one direction. There was no chance for clarification. That was no opportunity to question the order. There was no chance to refine the objective. There was only a vague directive.
Many software projects have the same flaw. Written documents are a classic form of one-way communication. Some projects operate by having a requirements engineer talk to a stakeholder and then generate a huge Word document. The developers receive the document and implement it as they interpret it. In theory, this could work. In practice, it rarely does.
I'm not saying that written documentation is bad. I'm saying that collaboration is also necessary. Allowing developers to meet with the end users can be very advantageous. I have benefited, for instance, from touring the manufacturing facility of a client. It helped me understand how the software would work in its natural setting. On healthy projects, each requirement is the beginning of a conversation.
It’s important that the team establish what communication tools they will use on the project. They must do this early in the project. I said "tools" because it is important that teams have multiple communication channels and that they use each when appropriate. Using email to converse works well when the information is long and it doesn't require immediate attention. Using email to chat with a group is painful. This isn’t a problem with email per se any more than it is the hammer’s fault that it can't turn a screw.
Your team should evaluate all your communications options upfront, from chat to email, to voice, video, and documentation.
In the Charge of the Light Brigade, the soldiers in the cavalry must have known that the charge was a suicide mission. All too often developers know the flaws in the software, but they don't say anything about it. Maybe it is hard to use. Maybe there are gaps in the functionality. Maybe it depends on another system that is unreliable.
As Tennyson said of the soldiers:
"Theirs not to make reply,
Theirs not to reason why,
Theirs but to do and die:"
As developers we must be willing and able to get clarification when necessary and to ask the "why" questions. It is our responsibility to make sure the client gets software that solves their problem. If we don't, the project will die.
One of the reasons why the Agile Manifesto was such a watershed moment in our industry is that it put renewed emphasis on communication. Two of the four points are directly related to communication.  The Scrum process specifically puts emphasis on team communication, not only among the developers, but with the business users as well.
In addition to the communication breakdown, the other major reason for the disaster in the Charge of the Light Brigade was a lack of visibility. The overall commander of the British forces was situated on a hilltop where he could see the entire battle. He could see the retreating Russian artillery battery that was a perfect target for the light brigade. The divisional commander was down in the valley and could only see the entrenched Russian artillery position. The overall commander was too far from the cavalry to see that they were preparing to charge the wrong position until it was too late.
One of the challenges in writing software is that the client cannot look at the code and judge the progress. They must be able to see the software running in order to give feedback. This is why regular demos are so valuable. They give the client visibility into what the developers are building. If the feature they just developed does not meet the client’s need, it gives them the chance to redirect the developers. Seeing the client use the demo software gives the developers better visibility into the intended use. Demos also give the client a feel for how much of the project is complete.
Some other valuable tools for making progress visible are sprint burn down charts and release burn down charts. A good project management tool will be able to automatically generate these charts. The burn down chart gives the entire team visibility into progress made in the current iteration. The release burn down shows how much work remains before the next major release.
Software projects are successful when the end users are getting value out of the software. To achieve this, there must be good communication between all parts of the team, including the representatives for the end users. There must also be good visibility for all of the team members about what the team is building and when they will finish. All long as procedures and mechanisms are in place to cover all these areas, the project won’t be another Charge of the Light Brigade.
Also of interest: http://www.bbc.co.uk/radio/player/b008md8x#