Are we practicing thinking, or just honouring the word……. still?

Time Magazine Cover, January 23rd 1950. Artwork by BORIS ARTZYBASHEFF, captioned “Harvard’s Mark III, soon to be delivered to the Navy”.

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.

Tactics and Strategy – Close Allies Or Not?

One area I find people (and consequently organisations) can get very confused over is Strategy.

People often talk about Strategy (and it’s always with a capital S) as if it’s something superior to Tactics (which never has a capital T), and indeed anything else.  In reality Tactics and Strategy are very closely related, and I’ve not found any better analogy for the relationship between the two than sailing!

I should point out at this point, I am no sailor, so if there’s any inaccuracy it’s entirely mine and not the person who related the analogy to me in the first place.

As I understand it, from a sailors point of view, the strategy is simply where you want to end up.  So, if you set off from Southampton your strategy is to get to New York.  So far, so good.  However, getting to New York in a straight line when your principal motive power is the wind is also impossible.  That’s because if you should attempt it, you’ll soon hit what sailors call the dead zone.

The Dead Zone is the triangular area from a point in front of you to two points either side of New York.  It’s called the Dead Zone because that’s where the wind will just disappear and leave you floundering.  So, how do you get from Southampton to New York then?  By a series of zig-zag actions known as tacking.  You weave yourself left and right, searching out the wind whilst keeping an eye on your ultimate destination.

Now, it strikes me, that actually figuring out of the strategy is very important, but the real hard work is in the tactics.  Strategy may change over time, a little or a lot, but your tactics will be refined on a pretty constant basis from beginning to end.  I would even go so far as to say that if your strategy is changing a lot, then it really isn’t a strategy, and if your tactics don’t change fairly frequently, they aren’t tactics.  This doesn’t mean that you change your tactics every time the wind changes, but it does mean you make a careful assessment of those changes and make an explicit decision on your response.  Do nothing is a perfectly acceptable response.

In project/programme terms, and depending on the terminology of the particular project/programme method you are using, the strategy is linked to your Vision and the tactics are how you are going to deliver that Vision.

Don’t confuse tactics though with requirements – requirements are in part the vision defined in a much lower level of detail. Requirements do in the vast majority of cases need be have a minimal level of churn, especially in later phases – it’s not much good after you’ve transitioned 1000 staff from London to Singapore to then decide it really ought to be Australia after all.  If nothing else, even if it’s possible to accommodate these late changes, the costs are always higher the later the change.

So, what can we take away from this sailing analogy? I think there are 4 key points:-

  • Strategy, put simply, is where you want to end up
  • Tactics are the method by which you deliver the strategy
  • Tactics change as other factors blow you off course
  • Tactics are not the same as requirements

Hopefully, this short article will also make you think whether you ought to have a separate team who are “responsible” for strategy or whether they ought to be part of a team also responsible for delivering on the strategy.

What everybody ought to know about rowing

Rowing Quad on the river at Henley-on-Thames

Based, as we are, in the beautiful town of Henley-on-Thames, Oxfordshire (about 35 miles West of London) we see rowers going up and down the river every day, come wind, snow or indeed blazing sunshine.

Henley is famous for the Henley Royal Regatta, and by by some strange coincidence I picked up a copy of Charles Handy’s book “the search for meaning” during the Regatta season which has an amusing analogy about teams.

 

Mr Handy likens teams to a rowing eight on the river:-

“Eight people going backwards as fast as they can without speaking to each other.

Steering is in the hands of the one person who cannot row, because you put a chap in charge who cannot do the job.”

Having subsequently been confronted by an Olympic oarsman who asked:-

“How do you think we can go backwards so fast without talking to each other, unless we know each other terribly well, unless we have total confidence in each other’s ability to do the job we are supposed to do, including the little chap who can’t row, who is steering, unless we are all absolutely dedicated to getting to the end of the course before anybody else, and to winning the race?”

I’m sure we’ve all come across the first scenario, and I know that the second scenario is certainly one that has been key to the most effective teams I’ve led or otherwise been a part of.

The other elements that these analogies allude to are visibility and steering. Without visibility, how can you effectively steer your team, organisation, projects, programmes and improvement efforts? Do you have true, objective visibility or are you dependent on individuals telling you everything is running smoothly and then suddenly finding yourself heading in the wrong direction or overtaken by the competition?

Let’s talk about risk

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!

How to prioritise your company’s projects

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

Like fish, we don’t know water. In order to know what water is, a fish must come out of the water – usually not very good news for the fish.

Like fish, we don't know water
Like fish, we don’t know water

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.

It’s 1920…. and IBM’s motto is THINK. Roll forward nearly 100 years, and we’re still not…

Peter Drucker, the management consultant and author,  is quoted as saying that taking action without thinking is the cause of every failure.  This strikes me as overly simplistic – failures can also be the result of not taking action, and surely we cannot not think?

What I’m interested in exploring is how we think, how we make decisions and, ultimately, what we can do to improve the quality of our decision making.  Particularly those decisions that have significant impacts on “business as usual” or through the delivery of change projects and programmes.

The IBM Think motto in multiple languages

Daniel Kahneman in “Thinking, Fast and Slow” proposes that there are two types of thinking – system 1 and system 2.  System 1 is fast and intuitive, system 2 is slow and and deliberate.  So, perhaps when Drucker suggests we don’t think, we’re employing system 1 when we ought to employ system 2, or we’re employing system 2 incorrectly.  System 1 wouldn’t have noticed the typo in this paragraph.  You’re now employing System 2 to work out what the typo is.

I think there’s another element we need to consider though, and that’s thinking styles.

Thinking styles are how we prefer to use the abilities that we have – a way of thinking, rather than an ability itself.  We will be more successful in an organisation if it matches our thinking style.  Organisations develop a culture and a way of doing things.  If we question the way of doing things, we can be viewed as disruptive rather than creative.

Ability tests, by the way, are a very poor indicator of performance – they probably account for 10% or less of the variation in job performance.  So, what’s the 90%?  Thinking styles may be one answer.

Magniloquence of methodology, method and process

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

Image is of a heating arrays in radiant heat facility which are individually designed for each test, can reach 5000° in seconds.
Image from page 244 of “Bell telephone magazine” (1922) illustrating the story of the Sandia Corporation and discussing the quality assurance and testing processes.

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.