The problem is?

Comment I posted on: https://youtu.be/u_JQs5CbP1U entitled The First Problem Every Architect Faces

Good review of the factors that go to siting a building. My practice has been that good buildings come from a thorough understanding of the purpose the client has, at a strategic level, the program (what the client needs/wants/is interested in) developed to achieve the purpose, the place and the people (client, users, customers, servicers, builders). Of course, what flows from this is the performance the building is to achieve. The 5 Ps of architecture!

But all that aside, I want to comment on the title: the 'first problem'. At uni my tutors always referred to architectural design programs as 'problems'. My colleagues still tend to do so. Engineers, bless them, solve problems, and sometimes very creatively.

Architects go further. We organize new potentials for people. So, the problem a city has is that there's no library in a neighborhood? Problem? The idea of 'problem' is reductionistic and turns architects into solution preparers -- like chemists?. This is a triviality compared to what we really do: find opportunities and make places for people to invent their futures.

We expand, we don't reduce. We create what has not yet been conceived. Doing that we solve a myriad of problems, or we avoid the problems, or we redefine them to exploit the benefits in an opportunity. A design commission is never a problem, it is always a challenge, an exploration, an opportunity, a desire.

Problem analysis

Systems such as the McKinsey system are good as systems in certain contexts, but they tend to be reductionistic.

1. Define problem - What key question do we need to answer?
2. Structure problem – What could be the key elements of the problem?
3. Prioritize issues – Which issues are most important to the problem?
4. Develop issue analysis/work plan – Where and how should we spend our time?
5. Conduct analyses – What are we trying to prove/disprove
6. Synthesize findings – What implications do our findings have?
7. Develop recommendations – What should we do?

A system better for architectural and many engineering projects might be modelled on Soft Systems Methodologies which start with the 'circumstance of interest', or the 'matter of concern'. General terms: there might be no 'problem' only options, or opportunities. There might be a better future than merely 'solving' a 'problem.

Analyse the circumstances using Rich Pictures and a 'CATWOE' study.

CATWOE is

Customers

Actors

Technology

World-view (or socio-technical context)

Owner

Environment (total socio-technical environment)

This can lead into a 'design' process that starts with outcome options, then works through constraints and pathways to develop options to create a new future.

 

 

Project as system

The ubiquitous model of the project is the static 'triad', either mine or the unhelpful 'time cost quality/scope' abstraction.

Projects are a set of flows of information and value (effort in terms of dollars). Below I attempt to demonstrate a model of this.

The real project triad

Projects are about investing to delivery a level of performance that produces value for the investor. Everything is about this, including all trade-offs during the course of the project. It means everything flexes about value.

Shenhar's project taxonomy

He calls it 'the diamond approach' to project understanding, and it has great ideas: at last, some thinking that lifts project thinking to the level of a workable theory, rather than just a set of practices (and therefore a 'craft').

I refer to Shenhar and Dvir's Reinventing Project Management, published by Harvard Business School Press.

Four dimensions are identified: Technology, Novelty, Pace, Complexity. There are four gradation steps for Technology and Pace, and three for the other two. There should be four for them too, which I'll suggest below.

Some of the terminology is less than precise and could be improved, but I guess it leans to a simple working project language to make its point.

For instance, take Technology: we range from 'low-tech' to 'super-high-tech', with parameters for classification brushed in the broadest strokes.

This is insufficiently objective, and different domains will understand terms differently.

'Low-tech' would indicate that components and production techniques for the finished product are predominantly conventional off the shelf items and/or require engineering that is ubiquitously available in the relevant market. 'Super-high-tech' on the other hand would be a product that relies on experimental development of unique processes or products not available anywhere in any domain.

The experimental definition identifies the risk to schedule, budget and performance instantly. Quanitification has its own problems, but historic cost escalation could give some leads: for example, Sydney Opera House, the Lockheed Lightning military aircraft (distinct from the English Electric Lighning of times past: a faster plane by far), The Apollo program, Polaris missile development...the list is long.
 
Similarly for Pace, which  runs from 'standard' to 'blitz'. These can be defined by additional investment to shorten delivery time. So 'standard' is the economical pace imposing no opportunity cost penalty on the promoter. 'Blitz' would be a pace that requires resources and working methods that represent a potential (and significant) opportunity cost penalty to a promoter. Sometimes this can be offset by a 'time to market' benefit, but not always.

Novelty needs a first step, prior to 'derivative'. Derivative implies that work is based on but not identicial to other recent examples. In the building industry this doesn't work. The prior step would be 'Repeated'. Many commerical buildings, most factories and most houses are 'repeated' projects. The large proportion of materials, techniques and skills required are identical to those required by the previous project. Nothing new but configuration and sometimes site conditions.

Similarly for 'complexity'. This dimension is quite difficult, but the there steps listed are adequately defined to be useful. I would add 'adapted' between 'assembly' and 'system'. Take a typical factory unit development. Mostly these are an assembly of known items by known methods, and represent a 'repeated' project. However, a factory for a specialist application (I think of a large printing works that I was involved in), which required fine-tuning to equipment and process, including the use of AGVs and automated paper warehousing and 'publishing' equipment, while not a 'system' in Shenhar's sense, was more than a mere assembly. The way things were brought together led to responsive interactions between 'assembled' components that amounted to an adaption that lifted the level of complexity.

The parameter that measures this dimension is the relationships between 'systems'. An assembly is work within, essentially, a single delivery or industrial system, adaptation is known systems in a novel or rare (to the project team) interacting arrangement. Shenhar's 'systems' represent a unique configuration of subsystems and require (some) specialised (not ubiquitous) processes to enable the product to meet its performance requirements and allow the customer to achive the mission for the product. Array is the most complex and has interacting unique systems or configurations.