JAD is a sophisticated process that must be done well to work. Here are the main problems it can cause.

Unrealistic expectations following the JAD session. The JAD session can generate so much excitement that development can't possibly meet the demand for the new system fast enough. Participants in the session see how quickly developers can create a prototype, and they don't always understand why it takes so much longer to create the real system. The positive momentum generated during the sessions can turn against developers if they don't deliver the real system fast enough.

You can mitigate this risk in two ways. First, part of the JAD-design session should be spent setting realistic expectations about how long it will take for development to create the new system. The whole group should commit to a development schedule by the end of the design session.

Second, you should choose an incremental development approach to use with JAD. This allows for relatively quick signs of progress after the JAD-design session as well as garnering the other advantages of incremental development approaches.

Premature, inaccurate estimates of remaining work following JAD sessions. In standard JAD, a target date for completing implementation comes out of JAD planning, and the estimate is not revised as part of the JAD-design phase. That creates an estimate far too early in the development cycle and contributes to the risk of unrealistic expectations. You'll know much more about the system after JAD design than after JAD planning. JAD participants will probably want an estimate after the planning phase, so make a rough estimate after planning and a more refined estimate after design. I've modified the standard JAD-phase outputs in this chapter to use this two-estimate approach instead of the standard approach.