Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Building Architectural Requirements, Bit by Bit
Ian Whittingham, PMP is director of Calixo Consulting, providing project and program management expertise from initiation through to implementation, covering business transformation, workflow process re-engineering, and enterprise data integration. He is a regular contributor to ProjectManagement.com. You may contact Ian directly at [email protected].
Popularized by Frank Lloyd Wright, it was the defining principle of Modernist architecture: “Form follows function.” But this pithy axiom--that the functional characteristics of a building dictate the design choices that form the building--also encapsulates the key constraint under which all architects labor. For every formal choice an architect makes is constrained by the need to solve a site- or system-specific functional problem.
One of the paradoxes of architecture is that while its finished products are available and visible to the spectator, the solutions to the problems it solves are--for the most part--hidden from view or when visible are not always readily apprehensible to the non-architect. Nowhere is this paradox more acutely felt than in the technical intangibilities of IT architecture. But why should that matter as long as the problem gets solved?
The successful creation of any complex artifact, whether building or software, depends upon documented requirements, because requirements formalize the incoherent wants and needs of stakeholders. (In this context, incoherent means ambiguous, disorganized and fragmented, not incomprehensible and nonsensical).
Formality creates the necessary objectivity to systematically analyze, categorize and describe the requirements in ways that enable wants and desires to be translated into …
Please log in or sign up below to read the rest of the article.
ADVERTISEMENTS
|
Don't be humble. You're not that great. - Golda Meir |