After spending three months alone in a windowless-but-air-conditioned office, the business analyst emerged with a two-hundred-page document of business, functional, and non-functional requirements. A short time later, her contract concluded, the document was discarded because it was useless — it was useless and it was very expensive.
As part of understanding how to balance precision with effort, i’ve been trying to emphasis the need to use flexible and rightsized analysis and design techniques throughout the lifecycle of doing anything, though especially at the early-lifecycle stages. In this context, “anything” is a change arising from formal portfolio, programme, and project work equally as it is a change arising from an innovation, an experiment, or any other initiative. There are several reasons for why i’m keen on this approach:
- Energy-Efficiency #1: Environments that are even remotely innovative or innovation-feasible won’t be afraid to commission measured activities that don’t progress beyond an early-lifecycle stage. Committing the full raft and menance of the academic energies, economic resources, and opportunity-time needed to establish big-requirements-gathered-up-front guarantees either a lot of waste or a lot of bad initiatives going ahead for bad reasons like pride-protection.
- Energy-Efficiency #2: Even the most-staunch waterfall-process delivery shops understand that the big-requirements-gathered-up-front never contain actionably-guaranteed specifications for what will actually be created when the initiative is complete. Starting with high-level, with really high-level, indications of the business and functional requirements and the solutions design sets the culture and the expectation that not everything can be known up front, and that the final solution will be approached iteratively and collaboratively.
- Outcome Quality: When achieved in the open with multidisciplinary collaboration, design outcomes benefit from receiving input out of several perspectives. From an architectural perspective, this helps to ensure a suitably-wide context is maintained, and that the delivered outcome has a chance of being change-friendly.
- Social Efficacy: Early, deliberate, meaningful, sincere involvement of team members and stakeholders generates understanding and buy-in and reduces ramp-up time for later-scheduled activities such as development and quality-assurance. Kicking off a design process by dumping a two-hundred-page requirements document establishes a “there it is” perspective that sets a path-determined course of events in motion that disempowers everyone involved.
- Enjoyment Factor: Capturing requirements, defining processes, and designing solutions should be enjoyable, challenging, stimulating, fun. Increasingly, the ability to work together and communicate ideas using storytelling techniques is becoming a valuable domain skill for enterprise architecture.
Using photographs of sequence, context, container, and component diagrams hand-drawn on large whiteboards during discovery/design workshops the initial passes through the requirements and the solutions design can be captured effectively and enjoyable, and those initial artefacts are highly-consumable and serve to seed more-detailed representations that evolve as they are needed.
Taking this a step further, i’m interested in exploring the creation of an enterprise-architecture toolkit based on the snowboarder’s shared-experience mapping toolkit described by Luke Pittar in his post “Experience mapping – Design Research” at http://lukepittar.com/?cat=4
The snowboarder’s shared-experience mapping toolkit:
- …contains a range of magnetic icons and whiteboard markers, each representing an aspect of the skiing/boarding experience. The playful look and low-fi nature of these contents encourages people to interact and play freely with them, marrying them together to create scenarios that shape stories or represent their days experience.
…and i think this style of designing together can improve the experience, increase the participation, and make more fun from the current whiteboard-only workshops for design that i’ve been using — so i’m going to start collecting suitable component ingredients for an enterprise architecture design toolkit, and see what happens.