With all of the wonderful technology and increases in software development tools, why is it that IT departments still often fail to deliver quality systems to their clients? More often than not, the problem relates to inadequate time and resources being spent in requirement gathering, analysis and documentation.

The problem is simple: most software developers didn't become programmers to spend all their time writing requirements for their clients. They want to program. We understand that. However, there is a missing link between the need of an organization for a system and the system itself - it's a complete understanding of requirements. Can the client departments themselves document their own requirements? Unfortunately, this often doesn't work because they need to give a level of detail to software developers that is outside of their control. In the end, requirements are usually gathered by reluctant IT staff, and this results typically in an inadequate amount of time spent in requirements, with programmers being directed to develop the wrong functionality.

No one wants this situation. Developers need to walk away from a project with a success. They want to feel that their work has had a positive impact on the organization. And when they find out that their clients won't use their systems because they built the wrong functionality, they get upset. And of course the clients themselves are frustrated as no one really demonstrated an understanding of their world either. So much money, time, and competitive advantage is lost - often a major problem in business today.

Back in the 1980s, the term JAD (or Joint Application Design) was invented. This technique takes representatives of both the client and development communities and places them in a room for a period of time with the intention of uncovering the true requirements for a system. It has been our experience that this technique is the most successful way of eliciting requirements for a system for a number of reasons:

• The multiple representatives of the client community represent a cross-section of them. They are all in the room at the same time. This means that requirements are validated by all affected members before being assumed. This removes the possibility of one person driving the requirements and favoring their own needs rather than the needs of the group.
• Representatives of the development community are there to validate that what is being asked for can be accomplished. They takes into consideration legacy systems in the organization and what they require. Also, suggestions can be made for different ways to view a problem in light of available technology.
• JAD facilitators are external and act to maintain the group's focus on the problems and to ensure that all information gathered is documented and modelled. This 'scribing' facility allows the group to build their requirements and capture them during the session. The result is a documented requirement set upon which all parties agree.

JAD is the quickest and fairest way to obtain requirements. And the partnership between Software Engineering Consultants, Inc., and Tech Solutions, Inc. is the team to facilitate this process in your organization. Whether it is to introduce this concept to you, or to offer our services to implement JAD in your organization, Software Engineering Consultants, Inc., and Tech Solutions, Inc. can deliver what you need. Our training seminars in JAD techniques enables your people to learn how to use this technique. Or you can choose to outsource the entire JAD process to us. We will ensure that your requirements are captured and that this part of your project's pressures is relieved.