If the project team of business and technical people reach consensus in the fist step (Define step) and sketch out the conceptual design of a minimum viable system that can be built in the time available, then they move into the Design step. There are seven days in this step to work out the details of the system design and create a set of graphical spec documents that both business and technical people can understand.
The tight time constraint is actually an advantage because it sets limits on what can be done. Otherwise there is inevitable scope creep as more and more investigation is done and more and more complexity gets designed into the system. Tight time constraints keep people focused on the most important features so the design that results is something that can then be built in a couple of weeks (13 days are available for the Build step).
Four Core Techniques Structure Work in the Design Step
IT members of the project team use four core techniques to produce a detailed set of system design specs. The first technique is group facilitation (known as “joint application design”) to pool ideas from two half day sessions when business and technical people meet to design and review system specifications. The second technique is process mapping (I like dataflow diagramming but other kinds of process mapping can also be used) which is used to draw out workflows the system will support. Then logical data modeling is used to capture the structure and relationships between the data entities identified in the process mapping.
The fourth technique is system prototyping. System prototyping has two parts. One part is the user interface (UI) and the other part is the technical architecture. The UI has to handle the data in the logical data model and support the functionality described in the process maps. Then the technical architecture shows how selected hardware and software and operating systems will be combined to support the user interface and system functionality.
The design documents produced by these techniques provide the detail people need to produce a more detailed project plan for guiding and managing the work to build the system. By the end of the Design step the project plan is composed of a set of tasks and their durations and dependencies. Each task should be between a half day to two days in length with a specific deliverable and people assigned to it. As much as possible, the dependencies between the tasks should be finish-to-finish relationships, not finish-to-start relationships so that work on the tasks can run in parallel and not sequentially (see my earlier article “Agile Development, Project Management and the [Evil] Gantt Chart” for more explanation). The figure below shows how these four techniques and the project plan all fit together.
Graphical Specifications are Much Better than Lots of Words
The specification documents produced have the advantage of being graphical in nature. Because these specifications are graphical in nature, they don’t require people to read through lots of wordy documents. People can look at the diagrams and see at a glance what is going on. Words are then added as notes where needed to clarify points in the diagrams. This means people actually do look at the system specifications and they are understood by both business and technical people.
The storyboard of screens is the most important specification from the system user’s point of view because they enable people to visualize what it will be like to interact with and operate the system. And the technical architecture diagrams present all the information needed for technical people to put together the development and production environments needed by the system.