Comments on: Big Day for Project Managers Designers

By: Kathleen Elliot

Kathleen Elliot — Fri, 29 May 2009 18:37:12 +0000

Hal,
What a lovely manifesto. As an artist, I am inspired to read May’s book and have just ordered it. Thanks for posting.

By the way, I’m Kathy (used to be Yaholkovsky) from Logonet. I ran across your website link on Chauncey Bell’s website. I’m enjoying your writing.

Best,
Kathleen
http://www.KathleenElliot.com

By: Glen B. Alleman

Glen B. Alleman — Tue, 26 May 2009 03:04:36 +0000

David,
Thanks for the book. Construction is outside of sweet spot, but I like the network of constraints and opportunities. It fits well with the Monte Carlo simualation mandated in defense. Statistically developed schedule margin, placed in front of key deliverables to protect them with margin. Then finding the constrained path through the network and applying risk retirement activities to increase the Probability of Program Success (PoPS).

By: David Green

David Green — Sun, 24 May 2009 22:15:51 +0000

Glen, thanks for the link.
The book I referred to is Project Management in Construction by Anthony Walker. He characterises projects as networks of constraints and opportunities that the PM responds to to achieve the project objective.

By: Glen B. Alleman

Glen B. Alleman — Sat, 23 May 2009 20:42:16 +0000

The “frontier” management process is baked into even the most high ceromony of Program Management methods DoD 5000.02, http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf.
The Continuous Maturation process describes the increasing maturity of developmenal products over their lifecycle.

Once the “systems engineering” paradigm is adopted for projects, these types of approaches become the norm.

By: David Green

David Green — Fri, 22 May 2009 06:58:40 +0000

The comment on dealing with ambiguity reminded me of a book on PM I read about 20 years ago, that provided a model of a project manager’s role as running a project to ‘frontier’ of uncertainty where a choice could be made to stabilise the project for the next run to uncertainty. These ‘frontiers’ were decision points, but not where the alternatives forked off from the node, but were represented as a continuous fan of alternatives (hard to describe, easy to draw, I’ll send Hal a diagram to post if he things it would help). If I can hunt out the book’s bio details I’ll post them FWIW.

By: Glen B. Alleman

Glen B. Alleman — Thu, 21 May 2009 19:38:32 +0000

Hal, the very notion of failure as a learning process is the basis of all engineering processes. Whenin graduate school, one of the principle investigators on our particle accelerator as from Japan. He woudl ask before we started the machine if we knew what the outcomes woudl be. I was not brave enough to respond but a colleague said – “Dr. Gamo, if we knew that it wouldn’t be an experiment would it.” “That’s why we have a fire extinguisher handy in case something realy bad happens.”

But this search for informing failure must be guided be some structure otherwise you’re just hunting around in the dark. I’m build an Integrated Master Plan for a helicopter program. The Flight Test portion of the Plan has a standard set Significant Accomplishments and the Exit Criteria for what is essentially a test suite of work. Testing is a structured experiment. Only be defining the expected outcomes and the data gathering process can the test be productive.

Embracing uncertainty is fine and good, inside the framework of the broader “Plan” for what done looks like. Otherwise the project turns into a level of effort activtiy with no end in sight.

By: Hal

Hal — Thu, 21 May 2009 10:55:38 +0000

Glen, thanks for sharing the paper “On Failure.” It is quite consistent with Matthew May’s book, In Pursuit of Elegance. The act of avoiding failure or planning that doesn’t anticipate failure keeps us from learning. The child that never falls doesn’t learn to walk. Learning is just not possible if we don’t allow ourselves to fail. Without learning we have neither the chance for success nor elegance. The authors of “On Failure” introductory quotation summarizes it for me, “Try as hard as we may for perfection, the net result of our labors is an amazing variety of imperfectness.” Embrace it, just like we must embrace uncertainty if we are to succeed with our projects.

By: Glen B. Alleman

Glen B. Alleman — Thu, 21 May 2009 04:39:47 +0000

As a potentially interesting counter – or possibly supporting – to the “freedom to explore” came in the mail today
http://www.dau.mil/pubs/dam/05_06_2009/ward_may-jun09.pdf

By: Glen B. Alleman

Glen B. Alleman — Thu, 21 May 2009 03:45:18 +0000

I would wholey concure on the “power of incomplete ideas.” This notion is the basis of evolutionary, spiral, iterative, and emergent development mandated by by processes ranging from Scrum i the software world to DoD 5000.02 in the defense business.

In our NASA world the role of “project designer” is called Program Architect – a title I held on Crew Exportation Vehical – the previous name for Orion (the shuttle replacement). This is a Systems Engineering discipline, baed on the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) process for describing the strategy of the program. The Plan (IMP) is the strategy for the successful completion of the program. This is where the “design” orgininates. In the same way the solution “architecture,” the Space Craft – is “designed” by the Systems Engineers. Not designed in the nuts and bolts sense , but designed in the sense of the Concept of Operations. In the same way a building architect “designs” the high rise, and the deatail engineering is done to fit inside that architecture.

The same is true for “designing” the Integrated Master Plan. It shows the strategy for success, the alternatives along the way – the alternative decision points actually. The Plan starts with identifying the increasing maturity assessment points of the program.

Unlike like David’s conjecture, the “methodogies” of Program Architecture and Product Architecure in the Systems Engineering discipline are highly method-ized through the profession and processes of SE. The notion that “no one can have any experience in designing the next one,” is of course nonsense in the Systems Engineering business. This woudl mean we start from Robert Goddard’s first rocket everytime.

The core concepts of the current Orion program is based on decades of developmental programs – some successful, many utter failures. While at the same time using a wholey new concepts (untested, unproven) – is the fundamental principle of space flight systems engineering. Invent new physics, using the learnings of the past.

The Executive Director of Stanford’s Design Studio needs to meet the Program Manager and the 2 Principle Systems Engieering on Orion to see what they have to say about – “The last successful design has already been done, and is useless. The next great design has never been done before.”

Project (Program) Design was a class in my MS in Systems Engineering, 1980. An MS required to move into the Assistant Program Manager role at TRW, Redondo Beach CA.

Maybe those academics and “thinkers” need to meet the people who are inventing the future as we speak and have been doing so for decades.

By: David Schmaltz

David Schmaltz — Wed, 20 May 2009 12:28:27 +0000

Hal: This is an essential distinction. I usually see projects so focused upon their expected results that they hop right over deliberately designing their effort. They start by planning activities and “gathering requirements” and quite unconsciously skip design of the project. Methodologies, as theoretically useful as they seem, encumber design. Deeply ingrained notions that projects are strings of processes which themselves should be generally repeatable also squelch design. Getting out of this ‘industrial regulation’ trance is complicated by the fact that most of us are unaware that we are invested in and deeply influence by this trance; we’re in it. We know how to plan, track, and control, but no one can have any experience in designing the next one. As the Executive Director of Stanford’s Design Studio confided to me, “The last successful design has already been done, and is useless. The next great design has never been done before.” Great design means creating something well-suited to the context and does not obsessively focus, as industrial regulation has so often, on initial efficiency, repeatability, or magical planning.

I wrote about Project Design as a distinct discipline twenty months ago. Even offered workshops on it. Nobody showed up.
http://www.projectcommunity.com/PureSchmaltz/files/61f2c894b208a15bbf4355fc5070607d-79.html#unique-entry-id-79

Still wonder why.

By: Dave Garrett

Dave Garrett — Tue, 19 May 2009 17:22:37 +0000

I love this Hal. Project Managers are all about creating structure and certainty, but one of the best PM skills is dealing with ambiguity. Actually not just dealing with it – but using that gray space to produce an even better result. The ability to design and feel your way through things may be the greatest source of personal competitive advantage PMs have. Thanks for reminding us that its important!