Keep It Simple, Simon

Keep It Simple, Simon

Krishna Kadali, M. Tech Kondapur, Hyderabad, India
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 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 to keep in mind:
?
Keep the requirements simple. The business analysts often confuse a par- ticular solution that came to their mind with the actual customer require- ment 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 neither really under- stands what the other does.
Business analysts should write requirements using simple tree-based imagery. The root requirement is the simple objective of the overall proj- ect. Small twig sets of child-level requirements are grouped together to form a branch representing a parent-level requirement. This process is
?
???????????????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 is crystallized, development can begin.
? Follow agile development processes. As soon as a small set of require- ments is identified, the development team can start prototyping immedi- ately. 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 two to three weeks.
This cycle of defining a small set of requirements, producing a prototype of the stated requirements, and obtaining feedback ensures that all project stakeholders are always on the same page and everyone is comfortable with what is going on. By religiously following these simple techniques, every software project can reach a successful conclusion. Especially if suc- cess is defined as a happy customer and working software that provides the useful business function for which it was created.