Keep It Simple, Simon
July 16, 2019STAKEHOLDERS 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, the following are the key points to keep 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 maybe something very simple, there may be a communications gap between business analysts and programmer/developers since neither really understands what the other does. Business analysts should write requirements using 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 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 requirements is 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 two to three weeks. This cycle of defining a small set of requirements, producing a prototype of the stated requirements, and obtaining feedback ensure 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 success is defined as a happy customer and working software that provides a useful business function for which it was created.
This article first appeared in the book – 97 Things Every Project Manager Should Know and has been reproduced here under the Creative Commons – Attribution 3.0 license.
