Guiding Principles 1: Business Value

The 'Executive Board' website has a list of 10 guiding principles for project management.

Over the next couple of months I plan to comment on them. The first is below.

Business value: The goal of all project work is to deliver business value.

How does a company move from project lip-service to project commitment? In my base expertise area of construction, its pretty easy: a new retail centre is tangible. More difficult in a business project where the result might be changed processes, a different perspective on the business environment, the approach to planning, product development, market engagement, etc.

But even where a company touches the construction industry, if it is a rare experience, the business must be self-aware about the project it embarks on.

How would it do this?

It needs to provide a project governance structure that connects the project to executive information and decision making systems (you do have those, don’t you?).

The investment-value equation has to be managed carefully, to get the business results from the project, and that will enable the decision to abort a project that has become a ‘good money after bad’ experience.

Interfaces with other parts of the business have to be managed to support the project on the one hand, and sustain and develop the ‘business as usual’ commitments on the other.

Just Do It!

In the brave lands of TV shows, Hollywood cinema and advertising the world is easy. This is famously captured in an old Mickey Rooney film where a particular financial crisis is dealt with by the exclamation "Let's do a show!"

Its that easy.

In the world of business and projects the same type of thinking makes its way, chillingly, across board room tables.

It pops up in seminars and the structured enquiries that we like to call 'workshops'.  It happened to me yesterday.

The moderator of the session ('facilitator') attempted to break an impasse by a Mickey Rooney moment. He asked why didn't we 'just do it'?

I could tell that it wasn't his money on the table.

Just do it? Without a clearly stated business purpose, without an assessment of the scope of the action or the definition of the subject of the action. No mention of costs, resources, or even a structured appreciation of risk or competitor reaction...no, the Mickey Rooney way was was the best. Leave your mind at the door, toss your experience out the window and just go broke. Not go for broke. But without passing go...go broke.

Best Practice

This is becoming a habit: my turning over of meaningless business jargon with the reality of projects.

"Best Practice" is the next on my list.

All I can ask is "Who is it 'best' for?"

If its best for this project, let's test it and find out; but better, let's work up the project delivery team to produce processes that will be the 'best' for the project through educated critical process checks, system refinement and check again on the results.

That is, we engage the intelligence and experience of the people doing the work, informed by others, but not slaves to what someone else in some other circumstances thinks is best for my project. A project they've never thought about, let alone seen.

Design Thinking

The Multidisciplinarian has a post on 'design thinking'.

It covers a lot of good ground, including having a stab at the 'fadism' that pollutes business discourse. A short time ago...a few years...'design thinking' was the beaut new thing to boost the revenue of consulting firms who are ever eager for solutions to their declining revenue opportunities as the last beaut thing fails to deliver. It often fails to deliver because it fails to deal with the interests of the customer, and prefers to pander to the needs of management, but that's another story.

In the building industry I meet and work with architects and engineers all the time, so encounter 'design thinking' and design talking, as well as design doing also all the time.

There are probably many varieties of 'design thinking' but the factor that I think may connect them all is the discursive use of resources to meet the requirements that will give life to an opportunity.

Note I avoided the word 'problem' and the phrase 'problem-solving'. I doubt that design is fundamentally a problem solving exercise. To characterise it as such is trivial, although architect-instructors at university use it all the time:

Practicing architect: "I'm designing a library."
Academic architect: "What's the problem?"
Librarian: "The problem is that there is no library!"

See? It gets us nowhere.

Rather there's a need and an opportunity.

Design occurs when resources are marshalled to meet the need. It entails meeting a set of criteria that may be changed as they are explored and challenged during the design process. It entails varying the 'power' of criteria as the work proceeds. This might include solving problems by employing tradeoffs and compromises, but that's on the way, not the object. The object is to realise socially useful shelter that meets the need, speaking at the broadest.

As the Multidisciplinarian points out that 'design thinking' is not magic, but usually proceeds when there is no obvious means of meeting a need or taking an opportunity, or realising a return. A parametric envelope is created by user requirements. As the response to the requirement set is developed, the parametric envelope, and the options available close in on a result. At bottom there is probably no strict algorithim to do this, although architects and engineers do have algorithmic-like behaviour as they develop their designs.

That's part of the craft of design in the building industry.

The Sensible 12: No. 12!

12. The project must deliver the expected value to the customer.
We all know a project is measured by successfully delivering the scope on time and within budget. I believe the true measurement is successfully delivering value to the business or customer. Value
encompasses all three of these components: scope, schedule, and cost (as well as quality). The value to the customer will not be realized unless the vision of the project is met.

This is the only reason for the project; if it doesn't occur, then the customer will not be back.

ASAP 2

In a previous post on this noxious abbreviation that pollutes business conversations, I decried the imprecision of its use.

I had another encounter with it today. The rational explanation for the fool hardiness didn't work, so I replied:

"OK, my 'possible'. I'll let you know when."

Kind of like the so-called 'reverse brief'; the document you give to a client when they don't know what they want (all quite legitimate in the world of the unknown). My rejoinder drove home the point that in a project where schedule sets the tempo of activity, dates have real meaning, measured in $ of value produced in NPV terms. Muck up my dates unpredictably and that will muck up your project returns unpredictably.

So, as a good PM, I'll let you know the date that is possible while maintaining the project tempo to produce the value you've hired me to produce.

The Sensible 12: No. 11

11. Issues and risks must be addressed quickly and openly.
Every project has risks that are associated with the venture, and every project will have issues that surface along the way. The fact that they occur is not unique, however, how they are addressed is unique to a successful project. It is critical to identify risks at the initiation as well as throughout the project. Immediately upon identification of a risk, develop a plan how you will manage that risk. As issues occur, address them quickly and provide the appropriate visibility to shareholders. Providing
transparency of risks and issues is an important principle of managing a successful project.

This along with communication is the meat of project management. But let's be sensible and approach risk management particularly with an understanding of the probability of risks, from analogous cases, and how to meet the potential cost on a 'diversity' basis. But fundamental is that the project is designed to eliminate as many risks as possible; and that shows up in the schedule!