The rule of 9: the 'enneagrid'.

My thinking about the structure of managing got a real boost from John Adair's work (link to previous post).

But it didn't quite do it for me.

When thinking about our practice as managers, we needs a more tangible and actionable breakdown of Adair's high-level triad.

My approach is to think in terms of three levels of manager attention:

 

1. Mindsets

Your basic personal configuration for effective sustained delivery. 

RESPONSIBILITY -- taken for mission, unit and members as a productive whole 

RELATIONSHIPS -- built and nurtured within the unit you are part of, peers, customers, suppliers and senior levels you are responsible to.

RESPECT -- given to all as the basis for positive influence. 

 

2. Actions

(from Adair)

Clarify the MISSION-- in terms of its strategy (as part of the overall strategy) current work and positioning for what's next.

Equip the UNIT -- with resources, training, protection (to get on with the job), and supporters  through advocacy with stakeholdrs (including your boss, customers, suppliers, and collaborators).

Develop MEMBERS -- as unit members, as individuals growing in skill and capability and as contributors.

 

3. Practices

The three practices that dominate and sustain your actions and their results.

COMMUNICATE Reliably -- Ask, Listen, Seek 'Reliable Promises", Welcome bad news, respond consistently for effective action.

ORGANIZE Efficiently -- Align resources, people, risk and schedule. Understand lead times and defend against distracting diversions.

COACH Constantly -- Every conversation a coaching conversation in some way. Coach continuously, feedback relentlessly and for growth, use errors for growth.

These are structured in the "enneagrid" below.

C A T W O E

From Mr AI

CATWOE is a mnemonic used in business analysis and Soft Systems Methodology to analyze complex problems and define perspectives, ensuring a holistic understanding of a situation. Developed by Peter Checkland, it stands for Customers, Actors, Transformation, Worldview, Owners, and Environmental constraints. 

The Six Elements of CATWOE

• Customers (C): The recipients, beneficiaries, or victims of the system who are impacted by the transformation.
• Actors (A): The people or groups performing the transformation process and implementing changes.
• Transformation (T): The core process that converts inputs into outputs.
• Worldview (W or Weltanschauung): The larger picture or perspective that makes the transformation meaningful.
• Owners (O): Those with the authority to initiate, change, or stop the system.
• Environment (E): External constraints, such as regulations, ethical limits, or resources, that affect the system. 

Purpose and Application
CATWOE is used to break down complex, messy situations into manageable parts, ensuring all stakeholders and factors are considered. It helps in creating a "root definition" of a system—a concise statement describing what the system is and why it exists. By identifying these elements, analysts can uncover potential conflicts early and ensure solutions are robust. 

 

The strategy review convocation

I conducted a strategy review a while back.

No waffle here. A view from each division manager on progress and challenges, a break for coffee, then next,

This is what we mulled over:

The circumstances of your division: market, staff, suppliers

A snapshot of the full picture (usually in Porters 5 terms)

Who are the players--in specific detail of influential people and their effect or how they are effected?

What is the objective of current action?

-- opportunities to leverage? 

-- constraints you face?

-- resources available/committed?

-- what is competing for them?

-- who is affected by these competition factors?

-- will oppose? 

-- effects on our mission: now? Later?

--  relations to corporate objectives?

Over all this is people understanding the strategy:  and strategy is action, not ambition!

What are we seeking to achieve?

What is the purpose of this (the "Why")?

What are our plans and their success indicators?

What is each person's role and are they (1) equipped for it and (2) gaining capability by it?

And how is this measured in terms of success indication? 

 

 

 

Architecture? That is the question.

I watched Stuart Hicks wonderful architecture channel a while ago on buildings in Chicago, specifically the Marina Towers. It took my mind back to my first year in my architecture degree. This project constituted on of my first assignments. Being 17, I had no idea what the buildings, the assignment or even architecture were about. Nevertheless, I did ok.

The first time anyone asked us what we thought architecture was, was when Micha Bandini fronted up as a guest tutor for a semester. She wondered why a chair might not be 'architecture', while, say, a factory might be...or might not be...she had the 'art' view of architecture. A view I didn't share. I took the 'craft' view. Still do.

But her question was right and did prompt some tepid discussion.

This should have been the first question in the first subject in the first semester. This course (let's call it "Architecture 1") would then have introduced us to a number of buildings for us to analyze as 'architecture', to produce measured drawings of some fine buildings, and so on...In fact we did mindless paintings and sculptures. Mindless and pointless. Better would have been visual art exercises with architectural intent: models of forms on sites, for instance. 

The answer to the first question would have been interesting, not including chairs, of course. I don't recall her suggestion or our conclusions...we didn't even get a few papers to read and write an essay on.

After decades of practice (as an architect) and as both institutional client and commercial builder/manager:

Architecture is the design of buildings to produce socially meaningful shelter.

Socially meaningful indicates that people in society (and even a hermit is 'in' society in a contra-positive manner) would be served in various dimensions: value for money importantly, buildings that were above all practical: good to use. Buildings that made life for the occupants or users a little more enjoyable. This includes weather protection, shielding from excess heat and cold, and emotive aspects. The building should be good to be in, even 'fun'.

These are physical and emotional dimensions.

Then we go on along the path of 'meaningful'  to a more spiritual dimensions, ones that transcend the emotive. The building should change your view of life in some beneficial way. It should 'uplift' you.

One building that did this for me was the Jyvaskyla City Theatre by Aalto. I was bettered by it. Not to be a 'better' person..that comes with the humbling experiences of life, but I grew in knowledge of self and 'people in spaces' as a result. I thought more about  the experiences of who used my buildings, in whatever role I was in.

The approach to architecture I was taught by my studies was the production of 'walk-in sculptures'. It was not about 'people in spaces', really. Not really. That aspect was a passing phrase here and there, but it never landed.

In fact it was not until I was engaged in the design of  retail centres, hospitals, and, oddly enough, custodial facilities that I had to really think about 'people in spaces'. I thought about it more when I took responsibility for operational results in large portfolio of special facilities (value c. $1b in today's dollars).

So, architecture is the organization of socially meaningful shelter giving joy to the occupants...even in prisons.

When is a risk not?

When someone pretends that an uncertain benefit is a 'risk'.

So, let's get this straight, risk represents the probablity of a threat to value and the cost of that threat materializing.

A risk is a negative thing. Not a positive, no matter what the Taylorist fantasy world of PMBOK says.

An unexpected beneficial effect may come or not, but action to absorb the benefit might be THE risk. Change of WBS, change of activity network, change of skills needed, change of procurement approach, change of finance/funding/budget. That's the problem with an unexpected benefit.

Then, what does the ConOps have to say about this new 'benefit'? What functions does it serve or enable?  What are its strategic/value implications? What is its net value? 

ConOps: Concept of Operations. or what the project is intended to enable for the user.

Risk: start the journey

Faced with a new project or undertaking, where does one start with the risk management process?

If your firm is in familiar territory, the RBS for another recent project might be the starting point for this project. But what if not?

Then one can start with the loci of risk within your domain.

Here's a generic start for the 'headings' under which a RBS might be formulated. 

1. Customer/user

Client/customer: familiarity with this type of project

Less familiar more risk, particularly in project definition cycle of :need/opportunity--functional requirements--Quality Function Deployment--performance requirements--product specification (in engineering detail).

Customer certainty

Is the customer good at developing a 'concept of operations' for the project and then the functional and performance components? Will customer immaturity lead to 'change' battles and threaten project value to the PM?

Customer maturity for project type

Will the customer be able to identify needs, functions, performance requirements, understand final specifications, cooperate with a Project Delivery System, participate in Project Boards, Change Management discipline, etc.

Business environment

Client's competitive environment, your competitive environment. This also leads to the customer and the project 'community', those who do, can our would have an interest in the project's success or failure: 'stakeholders' in common parlance.

2. You

Type of project: your familiarity with it, current market position of this project, supply side circumstances

3. Project

Location (not an issue for some types of project)

Nature of local conditions, site conditions, social conditions, local regulations, access, etc.

Technology

This relates particularly to construction, IT and engineering projects that are in a different technology environment from the project manager or employ technologies unfamiliar to the relevant members of the project team.

Type of project: what hazards does this type of project typically encounter, and how are they typically dealt with: managed, accepted, transferred, designed out?

4. Delivery

Team

Size, experience in domain, experience generally, familiarity with the project system used, familiarity with the applicable technology, worked together or not? 

Suppliers

Suppliers: who is there to do the delivery of the project (e.g. construction skills, installation/implementation/change skills for IT, etc.)

5 Your engagement

Contract terms

Do you and they understand the contract; is the risk allocation in the contract workable or acceptable to both parties. How are disputes handled? How are payments made? How are pre-payment acceptance points managed?

THEN

Each of the hazard areas can be considered against the C A T W O E framework to form a more detailed area of hazard vulnerability before reducing to a risk schedule, which tabulates:

1. the item
2. expected probability of occurrence (a range)
3. expected cost if occurs (a range in $) 
4. mitigating options
5. cost of any mitigating action (re-design, transfer, manage)
6. risk manager.

Four (or Five) Critical Project Questions

Mike Clayton has a short video on (the) four important project questions.

It's a good list for the PM running the project:

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

2. Which elements of your project are not as fully in your control as they should be?

[about 'control' of the project in its environment: where you can gain more control to achieve the sought value from the project's completion.]

3. What are you not thinking about that could have a material impact on the future of your project.

4. What is the question you are not asking? Obvious question? Question we avoid?

I thought one was missing, particularly in the light of project influencers (so-called stakeholders, who don't usually hold an actual stake in the project)

My 5:  Who is most likely to get in the way of the project delivering the value sought  by its owner?

I managed one project where a major contributor to the project made all the noises of support, but failed to connect his team properly with the project plan. The project sponsor helped, but not much. I had to 'go round the outside' to get things done.

This seemed to be a nice idea: bring the project critical questions to one place. I checked a few other sources.

Team Gantt had quite a good set.

Core question #1: What are the major deliverables?

This question forces you to be clear about what you want to achieve when embarking on this project. Moreover, you can use this question to check if you and your project team are working within scope and that each step you take leads you to those deliverables.

Core question #2: How will we get to those deliverables before or by the deadline?

This question requires you to think strategically to be able to create or achieve these major deliverables on time and on budget.

Digging deeper, you may want to consider the possible changes or risks that may affect your ability to meet these requirements. You can then devise solutions to work around these events and stay on track.

No matter the industry or the type of project you're working on, you need a project plan that will map out how you, your team, and your stakeholders will get from Point A to Point Z. Tools, like gantt charts, ensure that you complete projects on time, but also on budget. ?

Core question #3: Who is on the project team, and what role will they play?

This question addresses a crucial aspect of any project: who will be the people you’re bringing on board to help you complete the project?

You need to be clear on who your teammates are, how they work, and what role/s they’re to fulfill. A RACI chart can help you ensure each person is clear about their responsibilities during the course of the project.

Core question #4: When will the team meet milestones?

...and when will other members of the team play a role in contributing to or providing feedback on those deliverables?

Your project timeline should answer this question. This is where you’ll plot the deadlines for each specific milestone and decide when the team will come together to discuss progress and updates and who will either work on or provide feedback for specific deliverables.

Plenty Training had quite a good set

1) What is this project all about?
2) What does my project sponsor/client want me to do?
3) What are the implied tasks I am being asked to achieve?
4) What are the limits/boundaries of my authority?

You need to ask these questions so that you:

    Are given an idea of the project and organization context.
    Can find out what result the client really wants.
    Can find out if you are being given full responsibility and authority.
    Know exactly what power/authority you will have throughout the duration of the project, especially when it comes to decision-making.

After asking these questions, you should know:

    What your sponsor/ client is really after in regards to the project.
    What you are allowed to do and say.
    What authority you have for the duration of the project.

By asking these four key questions at the beginning of the project, you are also building a foundation of trust between yourself and your client/sponsor, which is absolutely critical!

Quay Consulting starts to tighten the question and heads toward the nub of the PM's concerns

Question 1 – Do We Know What Success Looks Like?

Sitting within a project that is under significant stress can ignite the initial ‘fight or flight’ response in all of us. It can be the prompt for a deep dive into the weeds, such as the schedule, to see where we can make up time or look hard at the dependencies that can be delayed to help the team re-establish the baseline and bring the project back to green.

Question 2 – Are we doing everything necessary to deliver on the success?

This is a critical question that the project manager needs to be able to answer. As they explore the issues relating to the project, it’s essential to revalidate that the scope can deliver the promise.

Question 3 – Are we listening to the right voices in the team?

It can be incredibly difficult to ignore the noise in a project to refocus on governance as a barometer for staying on track. When the PM and the team are under sustained pressure, then there will be a lot of noise being generated around the project, often from mid-tier management, related projects and field staff. PMs need all their energy to stay focused on the task at hand.

Question 4 – Are we really leading our teams toward success?

Leaders are born in times of crisis. When a team is looking for direction, a safe place and a common goal, it’s vital to not lose sight of the fact that the team is impacted by the noise and often without the full situational context.

Now, Glen Alleman takes us to the prize parameters for project management

1. What Does Done Look Like?

What are the Measures of Effectiveness (MOE), Measures of Performance (MOP), Technical Performance Measures (TPM), and Key Performance Parameters (KPP) of Done?

2 How Do We Get There? What is the Plan and Schedule for reaching Done?

3 Do We Have Enough Time, Resources, and Money to reach Done at the needed time for the needed cost, with the needed Capabilities?

4   What Impediments Will We Encounter Along The Way?

What are reducible (epistemic) uncertainties and irreducible (aleatory) uncertainties, creating risks resulting in implements to reach done as needed?

 5 How Do We Know We Are Making Progress?

What are the processes and procedures to measuring the Physical Percent Complete of the deliverable produced by the project? What is the confidence this progress to plan can be maintained and be assessed in the Estimate to Complete and Estimate at Completion for time, cost, and technical performance.

Conclusion

1. Start with Glen's set.

2. Apply Team Gantt's list

3. Use Mike's list to keep you on track.

The others are OK, perhaps for simpler projects, but keep these three in mind for all projects, particularly in the initial project collaboration symposia (a.k.a. 'workshops).

But of course, make good preparation:

Clearly set out and tested 'concept of operations' that the project has to address

Develop Work, Element and Risk Breakdown Structures to organize the project

Create a risk-adjusted delivery schedule, with stage acceptance parameters.

Ensure the Project Board/Sponsor is interested, attentive and supportive.

No more lift door bumps

We've all been there: someone dashes for the closing lift doors; a passenger jabs at the vaguely and ambiguously signed buttons, hits the wrong one -- as its a guessing game -- and the doors close on the person who wants to get in.

No one's fault except the adherence to a very poorly designed standard.

The ambiguity is created by a dominant centre line for each operation. It shows ambiguously the sought state of the doors (line indicating closed stiles) and the current state (line indicating the closed stiles). The only differentiator is the small and triangle 'arrow heads' that are positioned to show the direction of door movement. However, this meaning takes some working out, particularly for people with visual or vision impairment, and have just had their view of the symbols dominated by the strong 'closed' stile vertical lines.

The bad design

 

 

Good alternatives

Better

Best

All the alternatives are instantly and obviously differentiated and are clearly mimetic of the desired state to be achieved by pressing the relevant button.

The new manager!

Management is not a profession, it is not an academic discipline. It is at root a craft.

Many people drift into management with little or no guidance or real support. Firms do themselves a disservice by this. A new manager may one day be a great manager; give them the best start so real talent is not discarded by poor early experiences.

What is needed is not academic study, although that can help with the technicalities of the role, but as a craft, or a practice, it is best served by a combination of mentoring by senior staff and coaching in a group of people in a similar position.

This coaching setting thrives on the classic approach to adult education:discussion, reflection and guiding input. Where it touches on technical matters, it serves to introduce them conceptually and identify their applicability.

 Here's how the program goes.

1. The firm and its world

• The function of the firm, a model of the firm's activity,
• Why firms do projects, a model of the project
• The life-blood of business and its language: accounting and analysis
  
• Budgeting

2. Framing management

• The range of the manager's work, relationships and functions
• Based on work by Prof. Henry Mintzberg of McGill University

3. Modelling the manager!

• Introduction to a model for thinking about, doing and evaluating management
• Application of the model to the role

4. Getting action

• Structured approaches to identifying, planning and taking action
• Introduction to several planning and inquiry methodologies

5. Communicating

• Communication context
• Patterns of communication
• Communication effectiveness

6. Your own productivity

• Your own workflow
• Managing your activity
• Keeping track of obligations
• Meetings
  

7. Conducting the team

• Team dynamics
• Model of team action
• Working with teams

8. Operations

• The scope of operations management
• Production formats
• Manager's operations
• Statistical Process Control
• Lean and Critical Chain approaches.
  

9. Projects

• The nature of successful projects
• Projects in the business
• Project approaches
• Risk in projects: structured, probabilistic and qualitative
  

10. Decisions and change

• Making decisions effectively
• Decisions and the model of the firm
• Probabilistic and natural decision making
  
• Challenges in change

What could have been #2

Running back through my list of projects that never were, is Eveleigh North Rail Yard in Sydney, Australia (see also Kangaroo Point Resort and Marina).

This image is as in 2024. In the last years of the Carr government of NSW, I was project director for the rail yard redevelopment. The site is in the yellow perimeter below.

Eveleigh North Rail Yard Development Precinct

The site is about 12 hectares. The left hand end is a few small buildings and waste land. The middle is disused (or now underused) train stabling sheds. Maybe historical curiosities, but not worth keeping to obstruct major beneficial development: after all, life is not a spectator sport. We need to build for the future, not enshrine the aged technologies of the past as though society was stationary.

The far right hand 1/3 is some heritage buildings, which were to be rightfully retained and reused, some old 'non-heritage' buildings and a bunch of waste land and junk.

The development concept is below. Total estimated cost at the time was between $300m and $500m.It could have gone higher but we had some aviation restrictions along with the plan for a city heliport. The development would have been a fabulous counterpart to the Eveleigh South rail yard development which you can see in the photo below the development site.

Eveleigh North Rail Yard Re-development Concept

Grading scheme

I've recently run into a discussion with an accommodation provider on the gradings used in the review form provided by an Internet booking service.

A guest is invited to complete a few questions about aspects of the property: its condition, comfort, kitchen facilities, cleanliness, heating/cooling equipment, bathroom facilities and 'value for money'.

Such lists need to be calibrated so all parties are clear.

I use this set of criteria:

5 - exceeds expectations OR exceptional

4 - meets expectations OR completely satisfactory

3 - does not quite meet expectations OR largely satisfactory

2 - largely fails to meet expectations OR unsatisfactory

1 - does not meet expectations at all OR unacceptable

So, an operator would seek to have mostly 4s, with some 5s from guests who found the property to be superlative in that aspect. If there are too many 5s, over time this might indicate you can increase prices if you are operating at or near capacity.

A few 3s from time to time would be acceptable as people's tastes vary. If critical criteria get a 3 follow up and offer an inducement for a future booking as a gesture to make up for the disappointment. Perhaps a night at a 75% rate.

Once would expect almost no 2s. The operator should follow up guests who made 2 scores to obtain the detail, and perhaps offer an inducement to re-book, depending on the reason and if it gives helpful  information.

Any 1s should also be followed up, with no inducement offered as they are probably very unhappy.

In any follow up avoid recriminations or justifications. The customer is giving you valuable feedback which properly used can produce business benefits for the operator.

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.

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.

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 the course was 6 years 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. If a school can't achieve that, they need to move into the burger-flipping business.

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 off an ICL mainframe. Collectively we learnt nothing! Certainly nothing about 'systems' or their 'analysis'.

Yet at the same time as he was waddling though an evidently 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.

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.

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.

 

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!

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 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.

 

 

Leading?

I'm coming late to this topic I guess, but a couple of friends have recently been dragooned into participation in 'leadership' training by their employers.

The courses, from what I was told, were high on affect and light on actionable content.

So, what would be the 'actionable content' on leadership?

I find John Adair's triad of Team, Individual and Task useful, and Jans' model of  Representing (role model), Relating (the 'supportive' people manager) and Running (the team). Good in an Army context, but needs to be broken down into civilian life.

So, what is 'leadership' and what are its dimensions.

Firstly, 'leading' is one of the activities of a manager. A manager has formal authority to manage a business or activity unit to achieve its mission. This covers people, purpose and production.

One of the limbs to the manager's activity is influencing people to confidently achieve their goals. How?

1. Managing the context: this involves providing information, judgement and advocacy for the unit to direct and guide staff to understand the strategy and deliver the mission.

2. Coaching staff: ensuring the right match between job and person, with a good (this varies greatly) mix of relevant challenge and routine maintenance at the limits, with the core job well defined and connected to the mission with clarity and sufficient precision to enable goals to be achieved (providing necessary resources is a component of managing, along side the 'leading' component).

3. Managed genuineness. This doesn't mean a warts and all expose. We are talking context-relevant genuineness. Honest and sufficiently open with staff and colleagues, to enable frank (and polite) conversations that honour others and self to produce mission outcomes.

What 'leaders' don't say:

• 'don't bring me problems, bring me solutions' [sometimes you need to work up an approach with the person to help them come to new experiences]
• 'you've got to step up' [if 'stepping up' is not happening, check your own behaviour and demonstrated attitude]
• 'it's your baby, you fix it' [no, a team exists for mutual effectiveness, use the team both to build capability and support development - sometimes its a team of two: the manager and the staff member]

Finally, the core job of the leader: drive out fear. One of Demings 14 rules.

Manage the 'inner' stakeholders

Stakeholder management, like most things in popular literature, is often reduced to a set of rules of thumb. Often good as far as it goes, but there are some stakeholders that need extra care.

I call them the inner stakeholders.

Who are they, and how do you find them?

Easy.

First, find the project sponsor. That's probably easy, but not always. The real sponsor.

Next find who the sponsor has dependency or supply relationships with.

That's them, then. These are the 'inner' stakeholders.

Because of their relationship with the sponsor, they have a stake in the project in some way. Maybe even a way they don't see or fully appreciate.

It's your job as the PM to find out what their stake is and how they conceive it.

You need to meet them and ask about the links to the project, and the links to the things and people, functions and customers, the project is linked to. The relationship of the 'stake' to the 'holder' can be a second or third-order relationship, and those relationships might then have similar links to other inner stakeholders. They all need to be found, named, and analyzed.

This is the group you need to get in a room and identify the interconnections and how their influence can be useful to the project (and therefore to them). A 'rich picture' can help do this.

Then keep them updated. Maybe weekly sometimes, maybe monthly or quarterly at others.

But keep them updated somehow, and keep your sponsor in the loop as an ally, a facilitator and a power and information broker.

No matter what. Do it.