Eddie Obeng taught me about four “types” of projects:
“Paint-by-numbers” projects are the kind you can approach with most confidence. You know what to do and how to do it. If you follow the method defined by the problem, you should succeed. But it’s hard to innovate.
“Movie projects” occur when you’re less certain of what to do but you have a good understanding of method. You can explore goals, identify stakeholders, refine and then agree goals. Then you build a team matched to your requirements. With the team you storyboard out the actions and then execute the plan.
“Quests” are the type of project where you know what you want to achieve but you’re not sure of how to get there. Imagine collecting a band of knights to go in search of the Holy Grail. You know your goal. You need to build commitment. You need to share a definition of the goal. Then you select options and get going. You then review and repeat until you succeed in achieving that known, shared goal.
The fourth kinds of projects are “foggy” — you don’t know what to do or how to do it. We know there’s a problem or an opportunity out there but it’s shrouded in uncertainty. This is the type of project that’s complex.
Recognising the kind of project you’re doing isn’t always straightforward. Information architects can help with the definition.
I like Eddie’s definitions. They help me think about the type of challenge I face. Then they give me a shortcut to some well-matched strategies . I like his focus on the relationship between the ‘what’ of project definition and the ‘how’ of our methods for delivering success.
When we “architect” we naturally interrogate problems and opportunities to find out what they’re asking of us. We do this before we try to solve them. This is what information architecture is about, working out the “why” and “what” before jumping to a “how.” The first act of most projects should be defining the kind of challenge you face.
When we set a problem, we select what we will treat as the “things” of the situation, we set the boundaries of our attention to it, and we impose upon it a coherence which allows us to say what is wrong and in what directions the situation needs to be changed. Problem setting is a process in which, interactively, we name the things to which we will attend and frame the context in which we will attend to them” The Reflective Practitioner, p. 40
This early definition is vital. But architecting shouldn’t be limited to the problem setting at the start of projects. Different projects need different things. When you confine IA-thinking to the first box of your double diamond, you don’t make best use of the IA-mindset. Architects belong in both boxes. Architecting is a way of thinking during design and delivery.
“The architect seeks a joint problem–solution pair and understands that the problem statement is not fixed when the architectural process starts.”The Art of systems architecting, p. 8
Information architects try to match a solution to a problem. Good IAs knows that their real power lies in building a strong foundation — a problem definition. From that foundation you can begin to manipulate both sides of the equation. Architecting doesn’t just concern itself with the ‘solution’ side. Architects can look backwards too, considering the constraints and assumptions that have shaped progress to date. Design teams should apply this type of thinking strategically as they design.
Sometimes in a project you need to make a decision to give you a fixed point around which to design. But projects fail when we fail to recognise that we’re in the fog. We fail when we treat all projects as paint-by-numbers. We fail when we jump to solutions before we understand the problem and opportunities a project contains.
We fail in projects when things change and we fail to notice.
In reality it’s rare that the problems I face are fixed. It’s even more rare that I’m presented with problems or opportunities that aren’t interconnected. Most projects are dynamic situations that evolve, change and interact with each other. Many projects have more fog about them than we sometimes admit. Most of the time we’re dealing with systems, not static problems.
Systems are collections of things, they’re a mix of different things that together produce results unachievable by the elements alone. The Art of systems architecting
The interconnectedness of systems means that ‘things’ in projects are likely to change. Architects try to match solutions to problems — we create those ‘problem:solution’ pairings. But not all problems stand still long enough for you to solve them. And the interconnected of elements on each side of the equation means that both problems and solutions are systems in their own right. When either changes we need to update our architecture.
Some problems will remain intractable until you find the right framing and definition. Other situations will develop and alter. Other projects will see you learn how the actual situation differs from the template you’d used to understand it. Change one element and you change the system — you alter the equation. That’s why it’s so important that architects remain involved in projects as they develop and are delivered.
Projects with and without IA-thinking remind me of the difference between single-loop and double-loop learning. Single-loop learning is the repeated attempt at the same problem, with no variation of method and without ever questioning the goal. Single-loop learning is attractive to our lazy brains. We see a problem, think we recognise it and apply strategies that have worked well in the past. This is perfect in some circumstances, but not all.
During Double-loop learning ‘an individual, organisation or entity is able, having attempted to achieve a goal on different occasions, to modify the goal in the light of experience or possibly even reject the goal’. Managing Uncertainty: Strategies for surviving and thriving in turbulent times
Double-loop learning is more rigorous, flexible and adaptive. It requires more effort. But sometimes it’s the only way to succeed.
IA-thinking helps you learn. In some ways information architecture can be the lowest cost and lowest risk iteration of delivery. Good IA is like delivering a minimum viable product. It enables your MVP to be a thought experiment. It doesn’t need interface and interaction design, but it has a sense of where it will occur and how complex it might be. It can play and adapt with constraints. It can flex to find the most appropriate ‘problem:solution’ pair.
But it’s a mistake to think information architects only make plans, schematics, abstractions. If IAs aren’t around to ask questions or have an input when the real thing is built, you can miss the undocumented assumptions that formed part of the architecture. You also deny your architects the chance to learn from their mistakes and successes.
Matching solutions to problems, forming definitions and making decisions depends on our ability to form useful hypotheses. Architecting is a reflective practice based on experience. Without experience of the outcomes of projects and the challenges faced during design, development and delivery an IA’s work is likely to remain theoretical.
“Organisations that care about successful architecting consider designing their program portfolios to generate experience.” The Art of systems architecting
Architecting can be useful throughout a project. We take the unstructured and apply structure to it. The ‘inspired synthesising’ is the hallmark of great IA at the start of project. Then at some stage we need to change gear and commit — we need to move from descriptions to decisions.
“Architecting has been accomplished when the fundamental structural decisions about a system have been made, regardless of what sort of architecture description document has been produced. In contrast, many “architecture” projects currently being conducted are description-centric.” The Art of systems architecting
The strategic application of the IA-mindset is one way to unlock innovation and find your way through the fog of discovery, definition, development and delivery. IAs should be involved throughout. IAs do need to swtich mode and do different flavours of architecting at different times. In the early days of a project an IA is there to define. We build order from disorder. We help to define and focus on the problem at hand. This is where the art of architecting lies. Then we must shift and move over to science. We move from description to decision-making as we converge around the feasible and desirable in the project.
Architecting is always useful. Design teams should make space. Architects should rise to the challenge. We should always focus and execute the right kind of thinking. And sometimes we should encourage other disciplines to think more like an architect.
Leave a Reply