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

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.