I was reminded recently by a number of articles on two topics:-

• the Agile approach to software development and
• the ‘rise of the robots’

of the preface to Jerry Weinberg’s book ‘Quality Software Management – Systems Thinking’ – first published in 1992.

Jerry mentions in the preface seeing this Time magazine cover from 1950 about computers or “thinking machines”.

When Jerry started working for IBM, the company motto was THINK. For some time afterwards, Jerry took IBM seriously – until he noticed that although they honoured the word, they didn’t practice it. When he moved into an independent consulting career, he discovered that IBM’s managers were no different from the rest.

Fundamentally, despite the passing of another 25 years since Quality Software Management was published, the situation is much the same.

I’ve written previously on some of the problems of methods and Agile taken in isolation falls into the same traps.

The solution is to investigate systems thinking  – which has been applied to all sorts of circumstances not just software – and start to practice it yourself.

In addition to Jerry’s Quality Software Management series of books, if your interest is more generally business oriented, then “The Fifth Discipline: The Art and Practice of the Learning Organization” by Peter Senge is a great starting point.

As the 1950 TIME cover also hopefully demonstrates – although there are more opportunities now for automation by the application of technology – this is hardly a new theme – and the one thing that robots cannot do (and we don’t always practice as humans) is think.

Every project has risk.  Frankly, if they didn’t, perhaps the project isn’t worth doing in the first place.  It’s a difficult balance though – you need to talk about risk, but the word has negative connotations.

So, how do you keep things realistic without sounding like you’re looking for reasons why the project might fail?  Here are some of our recommendations:-

• Keep communication (especially to stakeholders) of risk down to your top 10 risks.  They should fit on a single side of paper or presentation slide. You will have other risks to manage, but as a communication tool, your top 10 risk list is sufficient.
• Standardise the way risks are worded.  Poorly worded risks are a common problem, so use a format like “There is a risk that….. <followed by what might happen> because….. <followed by why it might happen> which could result in….. <followed by the consequences if it did happen>”
• To counter the negative perception of risk, ensure that mitigations and progress are worded in a positive way.

Some of the most important lessons have to be learnt the hard way, and when it comes to realistic expectations, there are many lessons! It’s a delicate balancing act at times between ensuring everyone involved in the project is being realistic, whilst also being (and demonstrating) that you are confident in your ability to deliver. More than any other element, risk management is the trickiest. The paradox with risk management is that as Tim Lister says:-

“risk management IS project management for adults”

In other words, everything we do on a project should be from the perspective of managing risk.

BUT…..

Taking Tim’s advice literally got my fingers burnt on a project some years ago, so I decided to research more into risk management. One line of investigation was to see if others had taken Tim’s statement literally, and had designed entire methods from that perspective. Surely, if you’re designed a method – for managing projects, for example – then the order in which you introduce different processes should reflect that. One such method (the Capability Maturity Model) has 5 levels from Initial through Repeatable, Defined, Capable and finally Efficient. As you move up maturity levels, there are key process areas to implement. If this was designed from a risk management perspective, then perhaps you might suggest implementing processes to address the highest probability and highest impact risks first?

This is precisely NOT what happened with the CMM, and I haven’t seen much evidence of it with other methods either – from the Project Management Institute or the PRINCE/2 method in the UK, for example.

In the case of the CMM, I asked one of the lead experts why this was the case. He agreed that the ‘risk management’ approach was entirely logical…… and then dropped the bombshell. The reason key processes were where they were in CMM was because that’s where stakeholders wanted them!

By Antonio Nieto-Rodriguez, published in Harvard Business Review.

Every organization needs what I call a “hierarchy of purpose.” Without one, it is almost impossible to prioritize effectively.

When I first joined BNP Paribas Fortis, for example, two younger and more dynamic banks had just overtaken us. Although we had been a market leader for many years, our new products had been launched several months later than the competition — in fact, our time to market had doubled over the previous three years. Behind that problem was a deeper one: We had more than 100 large projects (each worth over 500,000 euros) under way. No one had a clear view of the status of those investments, or even the anticipated benefits. The bank was using a project management tool, but the lack of discipline in keeping it up to date made it largely fruitless. Capacity, not strategy, was determining which projects launched and when. If people were available, the project was launched. If not, it stalled or was killed.
Read more….

https://hbr.org/2016/12/how-to-prioritize-your-companys-projects

I’ve spent most of my working life in international environments, and it’s always been an aspect I’ve enjoyed. It’s what I would describe as ‘essential complexity’ rather than ‘accidental complexity’ – one that can’t necessarily be reduced but it can be better understood.

Talking of complexity, you can draw some broad generalisations about cultures within a region. A prime example is ‘loss of face’ in many Asian countries. The generalisations can be useful to remind non-natives that we need to approach situations differently. They are generalisations however, as there are subtle differences between different countries in a region and parts of the country!

I was in Singapore with an English Chief Technology Officer who needed some information from the Singaporean Asia Pacific regional Chief Information Officer. He had initially approached this in the same way he would in the UK – by asking a direct question – and not getting the answer or information he requested. I think he had tried this approach a few times over the course of a day or two.

We were chatting over lunch the next day, and I had suggested he asked the question differently – what I describe as the ‘show and tell’ (for example, rather than asking ‘Do you have a disaster recovery plan?’ why not ask ‘Can you show me your disaster recovery plan?’ or ‘Can you demonstrate what actions you would take in the case of a flood?”

The CTO briefly had a slightly puzzled look on his face, then got up, went to find his colleague and asked the question in the way I had suggested. He got the response he was hoping for.

The other key thing to keep in mind when working with colleagues from other parts of the world is to not ascribe motivation to their way of answering a question or behaving. Remember, it’s you that’s out of the water, not them.

magniloquent |maɡˈnɪləkwənt| 

adjective

using high-flown or bombastic language.

ORIGIN 

mid 17th cent.: from Latin magniloquus (from magnus ‘great’ + -loquus ‘-speaking’) + -ent.

Magniloquence is a good example of using magniloquence itself, but the high-flown language I want to talk about is the hierarchy of the terms methodology, method and process.

Process

The word process defines nothing more than a way of doing something – or, if we go back to our dictionary “a series of actions or steps taken in order to achieve a particular end”.  It’s sometimes questionable what the ‘particular end’ might be, or for that matter, ends might be.  In project management, take project planning as an example – you might suggest that the end is a series of documents.  Is that really all the output should be?  How about those documents being agreed, accurate and complete?

Method

In a way, where process is concerned primarily with the outputs, a method is concerned with the inputs or approach.  In project management we tend to think of PRINCE2®,  PMBOK® and associated standards and frameworks as being our method.

Methodology

The term methodology is used, most often in my experience, to make  what we’re doing sound rather grander than it actually is.  We use methodology when we mean method, and sometimes when we we’re just talking about a particular process.

Methodology should be reserved for what it truly means, the systematic, theoretical analysis of methods applied to a field of study utilising qualitative or quantitative techniques.

Why does it matter?

It matters because the term methodology is used consciously or subconsciously to dissuade people from questioning whether the process or method is right.

It’s a topic for another article, but if you ever talk to people who develop entire methods you’ll be surprised why particular processes are given the relative importance they are.

So, here’s a plea for:-

• keeping it simple
• questioning why we do things (at all, or in a particular way), and
• looking for evidence that the individual process or a method delivers the results we require.  Where that evidence may be physical (in the form of a document, for example), qualitative and quantitative.

If you’re interested in some of the ideas in this article, and want to find out more, please reserve your FREE space on our next Project Management Masterclass webinar.