Project Management Processes

In Session 10 of Pathways to Project Management (a publication of APM), we find a categorisation of the processes of project management:

1. Processes that define what need to be achieved.  Theses are what may be called problem and goal identification activities.  They are essential to clarify what we are trying to achieve, why we are trying to achieve them, and are they worth the cost involved?  Activities include business case and requirements development, as well as project management strategy and planning. 

2. Processes that plan the work required to achieve what needs to be done.  Once we know what we want to achieve, we need to think about the actual steps that need to be done to ahiceve the work.

3. Processes that monitor the work to ensure it will be done a planned.  Project need to achieve the constraints of scope, cost, and schedule.  It is critical to monitor the progress of the work to give us a good sense of how well we are going according to plan.

4. Processes that control change within the project environment.  These are the scope / budget / schedule change management activities.  All projects can expect change. Also included here are the Risk Management activities, which makes sense because risks are a source of project change.

5. Process that ensure the outputs of the project are fit for purpose.  In other words, quality assurance. It is interesting to compare how this differs from the ‘processes that monitor the work to ensure it will be done as planned.’ Does monitoring that the work is being done as planned exclude ensuring that the work done was fit for purpose?

6. Processes that ensure the outputs of the project are successfully launched in the business / customer environment.  In other words, handing over the outputs for the purpose of using the results of the project.

7. Processes that engage and motivate the stakeholders of the project.  Externally focused communication to ensure support for the project continues.  A project fails when it can no longer find support from its stakeholders.

How does this list compare with PMI’s Project Management Processes Groups?  The PMBOk Guide process groups are more abstract, and are not really at the same level as the Pathways process categories.  Cannot really do a useful comparison at this level.

Pathways	PMBOK Guide Process Groups
1. Define what needs to be achieved	Initiating
2. Plan the work	Planning
3. Monitor the work	Monitoring & Controlling
4. Control change	Monitoring & Controlling
5. Ensure fitness for purpose	Executing
6. Handover	Closing
7. Stakeholder management	Executing

Pushing Is Not Managing

A large multi-hundred-million dollar program, dangerously close to its deadline, is experiencing significant problems.

The final stages of testing reveals a large number of unexpected problems, building a mass of evidence that the product is not ready.  This is an unwelcome threat to the much publicised, long promised completion date.

What is the reaction of management?  Put pressure on those under them, as if the already stressed out workers will work better and more productively by application of pressure.  (If that were the case, then why not put more pressure at the beginning of the project, the middle... In fact, why let up pressure at all?)

Pressure shows up in the imposition of targets: You must deliver X number of tests per day! You must fix N number of defects fixed per day!

Incompetent managers have no conception that a process can only  sustain what it can sustain.  You cannot demand that a 3-lane highway accommodate 5 lines of cars.  Try to do so, and you get a mess.  And to fix that mess, you don’t try to ram even more cars. 

If a process cannot sustain a manager's demands, something will give.  The first casualty of pressure will be openness.  Fear will begin to creep and spread like an invisible fog in the project.  Fear leads to lies.  People will lie to save themselves, including from unreasonable demands.  Lies take the place of truth.  With truth gone, you cannot acquire facts.  Without facts, you lose control. Without control, you cannot manage. 

The managers will get their X number of tests, but they will be rushed and dubious quality.  They will get their N number of defects will be fixed. Some of the defects will suddenly become no longer defects. Some will be fixed  with duct tape mentality.

The manager will get the  numbers they want; these will have little resemblance to reality.  But maybe that's fine.  Maybe all that's needed is to maintain a semblance of success, just enough to get kudos and rewards for a job well done. 

There's always firefighters to put out the later problems.  But pity the people whose money is being burned up.  Pity the truth.

Ride Your Bicycle Forward

Organisations with a merit and ranking system are like bicycles being pedaled backward.

 

In the 1950s, W. Edwards Deming, then a relatively unknown statistician, conducted seminars among Japanese companies as part of the American effort to rebuild that country’s post-war economy.  

In these seminars, Deming reportedly used the process diagram shown below, to illustrate the systemic nature of a business’s processes. 

 

The diagram showed how the various parties: suppliers, production, ‘quality control’ (inspection), consumers, research, and others, fed into each other and back in one grand system of production. 

 

Despite the diagram’s deceptive simplicity, it was conveying a message that is both deep and shallow. It was a shallow message because everyone who knew anything about operations knew what it was showing. Yet the message was also very deep because the diagram confronted everyone by asking why they did not act as if they knew that. 

 

Deming made the point that because these functions depended on each other in a systemic way, they must be managed together, as a single system. To manage these functions separately, as if they were not dependent on each other is a path to institutionalised dysfunction.

 

In our modern world of systems thinking, processes management, and post the chaotic period of the 1990s ‘re-engineering’, the reminder Deming wanted to deliver can feel anachronistic.  Not only does the diagram look old, it feels old.  It would not be surprising if a modern audience today reacted to this diagram with a: 'Duh'. 

 

Duh indeed, because by this time we all should all know that. And yet it seems we  don’t.

 

So what is the big deal about Deming’s diagram?  While no one seriously questions its truth, many big companies – precisely the ones that really need to internalise this message – are still operating the business in a backward way.

 

We can illustrate the situation by imagining we were given a bicycle, and then shown how a bicycle should run, and yet we proceed to ride it backwards. 

 

In organisations where a merit and ranking system pervades, where an employee’s ‘performance’ is annually ‘assessed’ by their supervisor,  employees become forced to consider their supervisor as their most important customer.  Employees have no option but to direct all their actions and energies to figuring out what numbers the supervisor is tracking and make sure they meet those numbers, to the subjugation of other considerations.  

 

Supervisors themselves need to please their managers, and so treat their managers as their customer, always thinking: “how am I going to be ranked?”  The situation goes on -- the managers need to please their vice presidents; the vice presidents need to please their executives; executives need to please the CEO; the CEO need to please the board.  The board need to please the shareholders, often fund managers. Fund managers need to please their bosses, in a grand system of brown nosing.

Nowhere in all this is the poor paying customer, the source of the company’s income.  No, that's not entirely true.  The customer does sometimes pop up now and then, but only to the extent where they complain thereby represent a risk to the merit and ranking of employees, or where they give praise and enhance the merit and ranking of employees, or where they can be used to further please that most important of customers, the person higher up in the organisation.

This backward operation of the forward system cannot be undone without a transformation -- a deep, difficult, transformation that demands sustained struggle.  Initiating this transformation, and even more important, sustaining such a transformation will require an unbelievable level of courage, focus, and determination.  A constancy of purpose.

Organisations who are able to operate their forward systems in the right direction will eventually benefit. Once they do start moving forward, it will be easier and easier, kept in motion by a reformed cultural inertia,  to operate the system, understand it, speed it up, improve it, and even accelerate it.  They will have realised how far, FAR better it is to ride a bicycle forward.

The New Risk

In the world of risk management, even the most basic things can get confusing.  When it comes to basics, it’s hard to think of a notion more basic than what ‘risk’ is. 

One of these is the distinction between a risk and the event that triggers the risk.  You can see a little bit of the confusion through the risk management standards.  The AS/NZS 4360:2004 standard considers risk as ‘the chance of something happening that will have an impact on objectives'.  Clearly, risk is closely related to, if not actually, an event (‘something happening’).

Compare this with the newer ISO 31000:2009 standard, which is not only an international standard, but also succeeds the AS/NZS 4360:2004 (i.e., the next version of AS/NZS 4360:2004 is ISO 31000:2009). Here, risk is ‘the effect of uncertainty on objectives’.  It is no longer an event.

Now, this very succinct definition also manages to be very confusing -- there are various discussions in LinkedIn about what it actually is trying to say. 

What then, is the difference, between an event (or a circumstance) that brings a consequence versus a risk the brings a consequence? The key to understanding risk is to focus on the word ‘objective’. Start with the objective. What do you want to achieve? This is the starting point. Literally, without an objective, there is no risk.

Once you have determined your objectives (there can be more than one), think of the various outcomes that deviate from that objective.  The third step is to consider the consequences of those various outcomes.

Let’s work through an example.  Suppose you have a job interview, and you identified your objective to be: arrive at the appointment on time.  What are the various deviations?  You can arrive 5 minutes late, 10 minutes late, 30 minutes late, 10 minutes early, and so forth.  What is the consequence of arriving 10 minutes late?  How about 30 minutes?

You can the look at the different possible events, circumstances, or situations that can cause the deviations: traffic, getting lost, underestimating the time needed for travel, forgetting something and having to go back, running out of petrol, having a car accident, etc.

After identifying possible causes, analyse them and implement mitigation plans for the ones that might be more likely, such as traffic, or underestimating the travel time required.  By mitigating the various events, you are reducing the chances of not being able to arrive on time.

You can also mitigate the risk.  But since risk is not an event, you cannot mitigate it from happening.  Instead you mitigate its consequences. So you mitigate the possibility of the deviation from occurring by addressing the events that can cause the deviation, and you mitigate the consequence of the deviation.

	Old World	New World
Risk	An event, or situation, or circumstance	The deviation from your objective
Consequence	The impact of the event, or situation, or circumstance	The impact of the deviation (regardless of what caused the deviation)
Risk Event	An event that brings about the risk	An event that causes a deviation

Woody Allen’s Success Formula

How can you be successful?  How can you attain what you want?

According to film director Woody Allen, “80 percent of success is showing up.” What did he mean? Perhaps he meant that luck plays a considerable part in success (80%).

In my own life, I look back and I see many instances where a successful phase of my life can be traced back to being began at the right place at the right time.  It is not enough of course to be at the right place at the right time.  You have to be the right person. But let me focus on being at the right place.  The place does not have to be a physical location.  Being at the right place also means having the right qualifications -- being there.

For example, if there is a need for an experienced PRINCE2 lecturer, someone who has that experience is already at the right place, using my additional meaning for being there.  They only need to show up at the right place physically.

What am I trying to say?  Maybe it's that in order to be able to show up, you need to plan ahead:

• Determine where you want to show up.  Let's say you want to work for NASA as a rocket scientist.
• Plan how you will show up.  What can you do to achieve the status of someone who CAN be a rocket scientist.
• Execute your plan for being there.  Work hard.
• Show up. Be sure to present yourself at every opportunity for being hired as a rocket scientist

Remember:  It's not the most qualified who gets the job; it's the most qualified among those who show up.  It's not those who show up who gets the job; it's the most qualified among those who show up

Notes on Harold Geneen’s‘Managing’

Harold Geneen was the legendary CEO of the legendary conglomerate ITT.  He wrote a book many years ago, titled "Managing"

Far too often, the solution taken to solve performance problems is to restructure.  But the structure is almost never the culprit.  Basketball teams all have the same structure, but consider the disparity in performance between teams, even between teams whose members are individually comparable in talent.  Geneen has this to say:

“On paper, the structure and organization of ITT was not very different from that of most large corporations in the United States.  But an organizational chart is really only a piece of paper, a static dumb thing, that identifies a chain of command of people and functions.  True management begins only when you put all these people together, functioning together, in a vital, human interrelationship so that the company performs as a single team, driving onward toward the goals set by the chief executive.  These human interrelationships, in all their facets, are what differentiate one company from another..  On paper, one company can appear to be exactly like another, and in reality be completely different.  The important policies, decisions, and activities of a company are those which deal with people, not functions.”

On managing risk:

“Good management is more than solving problems as they arise. Good planning must include the anticipation of problems that are likely to arise and the steps to be taken to avoid them.”

A Better Definition of Risk?

I HAVE conflicting feelings about ISO 31000’s definition of risk.  This standard defines risk as ‘the effect of uncertainty on objectives’, a definition that succeeds at simultaneously being both clear and enigmatic. 

Witness the various discussions in LinkedIn about what the definition means.  Look around the web for many online blog entries, articles, and explanations of what the definition mean, and carefully note the certitude shown by those who wrote those online materials about what the definition means.  Notice how they differ in their understanding.

In light of the absence of any clarifying remarks by the writers of the standard (who seem to be non-existent on the internet) about what they meant by their definition, I have settled on my own understanding of what they meant. 

Their definition seeks to succinctly explain the nature of risk.  When they say ‘effect’, they mean ‘phenomenon’.  They don’t mean ‘consequence’ as many online writers seem to  think.  (Or at least, the standard writers should not have meant ‘consequence’ in sense of a risk eventuating bringing forth its consequences!).   The reason why I feel certain ‘effect’ is not ‘consequence’ is because risk is about something that has not yet happened.  If something has not happened, it has no consequence.  Had they said, ‘risk is the potential effect of uncertainty…’, then it would clear they would have meant ‘consequence’.

My current position is that the standard writers are attempting to explain in the definition what the essence of risk is. 

The best way I can think of of what they are saying is by making an analogy, comparing ‘risk’ with ‘shadow’.  I will propose a definition of the word ‘shadow’:

the effect of an opaque, solid object on a light source. 

I like this analogy because it almost perfectly parallels the ISO 31000 definition of risk.  If you have objectives, and you have uncertainty, the intersection of the two brings forth a phenomenon which we call ‘risk’

If you have a light source, and you have an opaque, solid object, the intersection of the two brings forth a phenomenon which we call ‘shadow’.

Remove either objectives or uncertainty, and risk disappears. No intersection, no risk.  Remove either the light source or the solid object, and the shadow disappears.  No intersection, no shadow.  

I have two criticisms for the risk definition though.  First, the definition, while strictly correct, is near to being useless.  It is an academic, technical definition, not an operational definition that can be acted upon by practitioners ‘in the trenches’.   How would risk practitioners explain risk to lay members or board members of the organisation using such a definition? 

My second criticism revolves around the use of the word ‘objectives’.  The Merriam-Webster definition of objective is “something toward which effort is directed : an aim, goal, or end of action”, accurately reflecting the normal day to day usage of the word to mean something that is being strived for, something to be achieved, something not yet.

But risk is not always (nor even most of the time) about something you wish to achieve.  It is often to protect what you already achieved. 

What you already have are also at risk. 

Strictly speaking, if you have good health and you have a desire to maintain that good health, then you sometime speak of such an objective: to maintain my good health.

But what about other things? People do not consciously state that their objective is to ensure that they keep on having a house. Or that their objective is to remain alive. They have an interest in ensuring they remain alive. They have an interest in ensuring their house remains liveable by them. But they are not objectives in the same degree as things they are striving to achieve, such as a job promotion, completion of a project, and so on.

Your health, your job, your finances, your properties, your relationship. your client list, your market position, your current operating efficiencies, your reputation, etc. are all at risk.  These are things you have already achieved; objectives you already attained.  You are interested in protecting them;  they are your interests.

Risk management is (far more) often used to protect existing interests, while also being used as an aid in ensuring we achieve our objectives.  It is in the former where risk management plays a more central role.  Risk management is key to maintaining what we have; it is the means there.  It is only useful in achieving what we do not yet have; here it is not the means.

My proposition is therefore to change the wording of the risk definition from ‘objectives’ to ‘interests’.   Thus risk becomes: ‘the effect of uncertainty on interests’  where interest refers to things we value, such as health, reputation, property.   But it also clearly encompasses as well as things you seek to achieve but have not yet -- your objectives.

I think this change would be an improvement to the definition.