Monday, May 22, 2023

Questions to run your project by.

From Mike Clayton:

1 What is getting in the way of each member of your team from doing their very best work?

2 Which elements of your project are not as well controlled as they could be?

3 What are you not thinking about that could have a material [effect] on the future of your project?

4 What is the question you are not asking? [This is the unspoken or avoided question you wish would not keep bubbling into your consciousness as you drift off to sleep]

Then Mike takes us on a trip of 'Solving Problems in the Grey area of Projects' care of 'Managing in the Gray', by Joseph Badaracco

Now, I'm not normally concerned with 'problem solving'. I prefer to think of options we have, their consequences against objectives and capabilities we can apply to them. Nevertheless, Badaracco has an interesting take on the question at hand:

1 What are the net net consequences?  What are the likely consequences of the choices before you?

2 What are my core obligations? Respect good governance and keep to your commitments.

3 What will work in the world as it is? Practicalities and realpolitik!

4 Who are we? Our values and ethical framework; our principles.

5  What can I live with? Your real bottom line based on your principles, but also what is the 'take home' you must achieve.


Thursday, March 16, 2023

On architecture and its training

Browsing in the local library I came across Francis Ching's Architecture (3e).

I think Ching started publishing very helpful books on the craft and practice of architecture when I was near the end of my degree.

I borrowed the book: I wanted to see his approach to architecture.

In a word: wonderful.

I reflect on the fumbling attempts in my course by most faculty to 'teach' architecture on the 'throw into the pool' method of fatal immersion. I guess, if you have no analysis of architecture, no theory of it, and no structured concept, that's all that's left. Let's all founder together. No wonder it took 6 years for the course to arrive at a degree!

Ching shows in deft and confident strokes of the pen, of words on a page, what architecture is, what it is about, how it is structured, and provides a vast repertoire of approaches to thinking about it.

I think of the years wasted! This degree could be taught in 4 years, with an optional 2 years for a cognate masters in it or a related discipline. We'd all be much richer for it.

His book is a manual that could be the core basis for the first two years of architectural education and exercise. Instead of a first year pretending we were in a Bauhaus art class, we could have been studying the formal disciplines of architecture, thinking about buildings in their multiple social and technical dimensions, and learning a systematic approach.

Oh, and that reminds me. In second year we had a subject 'Systems Analysis'. I looked forward to this subject as something that might teach us something about systems. Our lecturer even had an MBA from Harvard...so he must've been smart.

But no. He gave us a half-baked introduction to programming in Basic on teletypes hanging of an ICL mainframe. Collectively we learnt nothing! Certainly nothing about 'systems' or their 'analysis'.

Yet at the same time as he was waddling though a pointless Harvard MBA, he could have nipped over to MIT and worked on true systems analysis with the systems engineers there; the school Jay Forrester had done so much for. Now, that would have been a great way to frame architecture...we might even have come across a proper theory of architecture, as architecture, not as foppish drawing board decorating.

Friday, January 6, 2023

Project Breakdowns

Most of us are familiar with the basic project planning analysis: the Work Breakdown Structure, the document that shows the taxonomy of subdivision of the basic specialist product of the project into component work packages. It is used both to assign responsibility, in larger projects, and to check with the sponsor and users that all the required work appears to be included.

But, for a fulsome approach to project management a number of other breakdowns are essential.

Function Breakdown Structure

This analyses the functions that are required of the product into a logical hierarchy to ensure that all the headline functions will be acknowledged in operational functions.

This is then used as the basis for preparing performance requirements and acceptance standards for work packages and feeds into the design specification and performance parameters.

Risk Breakdown Structure

Same for risk. to ensure risks are understood in the most useful operational detail to enable proper analysis of hazards and effects.

Element Breakdown Structure

This breaks the product into its element hierarchy. This is a check on the FBS, but also provides a 'dimension' for keying project deliverables, specifications, inputs to elements of the final product.

Saturday, December 3, 2022

Learning from flying

I enjoy watching a TV series "Air Crash Investigations".

Initially, without having seen it, I thought it would be a sort of tabloid sensationalized program to attract eyeballs for advertisers; nothing wrong with that, of course, that's how TV works.

But it is not. It is a seriously crafted documentary series with excellent production values and carefully developed analysis of crash investigations.

From most episodes a project manager can learn, or use it to illustrate lessons about aspects of good project management practice.

Various episodes have taught:

Welcome Bad News

Importance of good crew communication (vital) with no member being unable to bring an error, a risk or a threat to the attention of the other crew members: bad news has to be welcomed by everyone.

Use Checklists

Checklists: make them, use them, and keep revising them as they are tested in use.

Communicate reliably

Before landing the flight crew does a landing briefing for the particular airport. Every time. One crew skipped it; confused roles on the flight deck, made a wrong decision and crashed into a mountain. All dead.

Disambiguate language

The famous Tenerife disaster seemed to arise in part from ambiguity in terms. The captain of the plane that crashed into the other plane on the same runway and the ATC confusedly used the term, 'clear for takeoff'. The captain appeared to interpret that as 'off you go'; the ATC meant it as 'standby for take-off'. He should have said 'hold for departure' as he know another plane was on that runway. The captain would have confirmed 'holding for departure', and awaited the clearance to 'clear for take-off' which would signal a clear runway as well as clearance for the flight plan post departure.

Use fail-safe markers

A couple of episodes featured problems with pitot tubes being blocked and giving altitude errors, leading to crashes.

One case was blockage by insects during storage, the other, covering by tape during a maintenance session. These are critical to aircraft operation. On both occasions the openings should have been covered by a large marker with a tag reading 'Remove before flight'.

Do not 'multi-task' because you cannot!

The futility (and fatal consequences) of 'multi-tasking'. In an environment demanding focused attention one cannot split attention between disconnecting streams of 'flow'. In one episode an air-crew broke the 'sterile cockpit' rule at takeoff. While working down the takeoff checklist, a flight attendant, a personal friend, entered the cockpit and they all chatted about dinner at the destination. Then the checklist was completed...but it wasn't; critical items had been omitted. The 'plane then proceed for takeoff without flaps being extended. It crashed with almost total loss of life.

Always use units when giving quantities

An aircraft was re-fueled at an airport during a transition from imperial to metric units. A flight requiring 1000 kg of fuel was provided 1000 lbs. No units were used on the documentation, leading to the miscommunication. Plane fell from sky.

Never assume/don't break the rules

A crew minimised fuel load routinely on a particular flight. They then defaulted to the risky routine and used the same load on a flight on the same route, but the reverse direction. Due to the altitudes of the airports involved, starting at a lower altitude airport than normal meant that more fuel was needed because of an increased climb height. Plane ran out of fuel and fell from sky. All dead.

Confirmation bias

Another fuel story. A flight lost its bearings due to instrument failure, but sought to regain them by trying to catch a particular radio station. The crew picked up a broadcast they took to be from the station they assumed and planned from that. They were wrong. It was a station hundreds of miles from where they thought they were. They didn't cross check the assumption, didn't have a 'devil's advocate'. They crashed into unexpected terrain: a mountain. All dead.

It's always the system/drive out fear

The aim of crash investigations is not to level blame, but to find causes. The fault needs to be found and eliminated; and the faults are one of:

  • technical: equipment or performance failure
  • systems: processes don't connect with each other adequately or are internally deficient
  • management: recruitment, training, coordination, resourcing

On only the rarest of occasions people are taken to court. The aim of investigations is to learn to increase safe performance, so while participants might be concerned that they will be responsible for an error, they seem assured that honesty is essential and only the most egregious personal negligence might bring consequences.

As Deming says: 'drive out fear'. Fear in an organisation or process leads to stifled communication, error, deceit, concealment, and inevitable failure. See the first lesson: Welcome Bad News. As Deming also says, if there's a problem in an activity or organisation, first examine the system that produces the problem...it is probably also its cause.

The Flaw of Averages

Never assume that an average multiplied by the number of units will be accurate. Remember the Normal Curve. Remember Standard Deviations. It can all go horribly wrong if you apply an average to a small sample/population.

One small aircraft was load assessed based on the average mass of a passenger and the average mass of per person luggage. That might have worked if there were 200 passengers, but there were only 16. The aircraft was overloaded and crashed on take off. Everyone died.

Another factor was that the average was out of date and didn't take into account the gormandizing tendency of too many modern Americans.

Fixation

If you concentrate too hard on the one thing (over-focus) you could die. One airline captain concentrated too hard on his altitude and forgot to pay attention to his airspeed. I think they all died too.

You  need a few systematic preventatives: one project rule: anyone can bring bad news at any time to anyone...and be rewarded for doing so (i.e. 'Thanks Kevin, I'm glad you spotted that.). Anyone who disparages bad news leaves the project. It could be fatal.

Similarly to Fixation error is continuation bias. With this a person is inclined, sometimes sub-consciously, to continue on a course of action that is indicated by objective signs to be the wrong course of action. The tip here, is when things change check all the antecedent conditions and consequential possible results.

Fatigue, lack of sleep.  No one can 'tough out' tiredness. Attention fails, reactions slip, critical evaluation goes out the window. Your are more useless than a drunk, because at least a drunk is obvious. In one episode fixation on the part of the captain, and attention failure by the co-pilot to even be aware of three separate obvious signs of danger led to a crash.



 


Saturday, January 15, 2022

Operations management

During my Christmas break, I've been exploring videos on operations management. Whatever your field: architecture, engineering, project management, construction, icecream distribution, you manage operations.

So, I went to the experts.

Lisa Bussom at Widener University, Eddy Witzel, and Inderdeep Singh at the Indian Institute of Technology.

I'm working through Lisa's content first.

In the second lecture, she talks about product 'attributes' and includes 'quality'. Quality is conformance to specification, in conventional conception. And sure, that's broadly an attribute of a product, but I think it is better to go to why the customer has an interest in the particular specification. They want a level of performance that will meet their need, their requirements, and give them value.

Performance is the attribute.

This then feeds into the process 'competencies'. Lisa has 'quality' as a competency. I would substitute 'design' for this.

Design is the threshold input to an effective process.

The genealogy of value is this: customer need/opportunity > performance to meet the need/take the opportunity > requirements to produce the performance > specification of capability > design to meet the specification, deliver the capability, produce the performance to deliver value to the customer!

Sunday, September 26, 2021

Braess's Paradox, of why tampering never works.

My comment on https://youtu.be/cALezV_Fwi0

And this paradox is why randomly adding more people to a process (project, workflow, etc.) often fails to improve performance or output. It amounts to what Deming calls 'tampering' with the system. To change the result of a system, e.g. produce more quickly, the system needs to be redesigned.


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 colleages still tend to do so. Engineers, bless them, solve problems, and sometimes very creatively. Architects go further. We organise 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.