Keep It Simple, Simon

Stakeholders of the project often make things more complicated than they need to be. This a common cause of software project failures. The team members of the project must have the ability to completely visualize the objectives of the project and complete actual work. Stakeholders, however, can accomplish the project in several simple, magical steps in their own minds. They imagine achieving the end solution quickly and easily, no matter how complex it is.

Stakeholders should not build a software project as a monolithic, gigantic, inflexible monster; instead they should allow the Information Technology (IT) team to build it like an onion with each layer enhancing its maturity. There is no other alternative in the world of reality. Regardless of the completeness of the requirements, there will always be change. If your software is not flexible enough to quickly adapt to changing requirements, the project is dead even before it has begun.

To keep things simple, following are the key points that need to be kept in mind:

• Keep the requirements simple. The business analysts often confuse a particular solution that came to their mind with the actual customer requirement based on a business need. Although the real requirement may be something very simple, there may be a communications gap between business analysts and programmer/developers since they don't really understand what each other do.

  Business analysts should write requirements using a simple tree-based imagery. The root requirement is the simple objective of the overall project. Small twig sets of child level requirements are grouped together to form a branch representing a parent level requirement. This process repeated on the diagram until each requirement is crystal clear. Software mind mapping tools could be used to document the requirements using this approach. Once even a small set of requirements are crystallized, development can begin.

• Follow agile development processes. As soon as a small set of requirements are identified, the development team can start prototyping immediately. Once the prototype is available, stakeholders can test and provide feedback. Customer feedback ensures that requirements are accurate and also helps identify any gaps that developed in the requirements as they were relayed from the actual customer through the business analysts to the project team. Allowing the customer to see the prototype also checks that the corresponding solution imagined by the developers is, indeed, what the customer envisioned.

  Gaps are translated into new requirements, developers re-prototype, and the cycle continues. Each cycle should be as short as possible, typically not more than 2 to 3 weeks.

  This cycle of defining a small set of requirements, producing a prototype of the stated requirements, and obtaining feedback, ensures that all stakeholders of the project are always on the same page and everyone is comfortable about what is going on. By religiously following these simple techniques every software project can reach a successful conclusion. Especially if success is defined as a happy customer and working software that provides the useful business function for which it was created.