Category Archives: Projects

“mknoona” and Critical System Heuristics

It’s been a little quiet here on the blog for a while as I have been busy with OU course TU811, Thinking strategically: systems tools for managing change which has taken up pretty much every free moment & put paid to any thoughts of flying my little airplane.

Now that all our TU811 work is submitted, the course online forum is pretty quiet except for a small quorum of us discussing the course content retrospectively. Some felt the content was rather superficial, the course presents five mainstream systems tools in parallel with a stream about thinking styles. Personally I felt that the breadth was good as it presented diversity in methods, and I like being able to choose from a canvas when I’m problem solving, and then modify & apply the method, “praxis” as introduced in the previous TU812 module.

One tool presented at the end of the module was Werner Ulrich’s Critical Systems Heuristics (CSH) which on face value looks a bit like a checklist presented as a matrix, but what it actually does is to make you think comprehensively about a situation from four different perspectives as my paraphrasing below:

  • why is it that we’re doing whatever it is we want to do
  • where is the centre of control for this, in other words if we try & do it is there a barrier stopping us
  • who actually understands what it is we’re trying to do & can they help us
  • who could be affected badly when we do what we’re trying to do

A lot of this is used in a social context but I got thinking about a couple of electronics problems from my past and how the decision style represented by CSH actually played a part even without us knowing about it…..

We’re used these days to buying a computer, taking it home & simply connecting it to a high-speed network, usually wi-fi as delivered by our broadband contract. Back in the 1980s this “Ethernet” network thing was just emerging from the Palo Alto Research Centre at Xerox, and we used “serial” wires to link terminals to computers, or even computers to computers (I was amazed on a trip to computer manufacturer CCI in California that they had all of their computers linked together using serial cables). These links were slow, and implemented using pretty simple electrical cable. When I went to work for Systime in 1986, they had a huge serial switch so from my desk I could connect to various computers, albeit one at a time from my terminal, very high-tech.

One problem with simple electrical cable, and slow speed data signals, is that it is very easily affected by external electrical noise, we still get some of that today when you are talking to someone on a telephone and their Blackberry is sat close by on the desk, you can hear the Blackberry doing it’s data transfers and it’s very annoying. In a “noisy” environment it was definitely the case that what was sent from the computer definitely wasn’t received at the other end.

Back in 1982 at a development centre in ICL, some colleagues on a different project to the one I was working on had a bad noise problem. Being a group of software developers they decided to fix the noise problem using software, they simply read the data value being sent down the wire three times and if they had two or three matches, used that. Ironically it was an apprentice from the manufacturing plant up the road who saw what they were doing, metered out the cable & showed that it wasn’t earthed correctly. Using a correct cable stopped all of the faults.

It was towards the end of the 80’s when I saw a similar problem. This time it was at an installation at a builders yard near Oxford. A serial cable had been strung over to a shed from where they processed orders for sand, grit & the like. This time the problem was almost unearthly, the signal coming down the wire kept repeating, in digital form, “mknoona….mknoona…”. And, yes in this case the cable was correctly earthed so the factor causing the problem was something external & significant. We ended up putting up a strongly shielded cable.

So what do these two problems have to do with Critical Systems Heuristics, if anything? In both cases what we wanted to do was to stop the spurious signals from coming down the wire, and it was easy to measure success: either the extracurricular rubbish stopped or it didn’t.

It was in the second step, looking at the controls, where the first case failed & the second worked well. At the development labs the team simply looked at themselves as the source of control, and of knowledge, and simply coded another fault into the system. They didn’t look at all of the sources of control (what could be done to stop the noise ingress) or knowledge (who could help with noise ingress) which is why a 17 year old apprentice showed them up. Furthermore no one thought about who would be impacted by the software change, in years to come someone would find their daft “fix” and have to puzzle it out, or worse still remove it as a common sense action and then find that things crashed around them.

In the builders yard case, it was quickly decided that the control of the external noise just couldn’t be found, and therefore the decision was taken to employ knowledge to institute a fix through shielding. I still have my suspicion that the noise was coming from power lines nearby but we could never prove it. Nothing was altered other than the cable & no-one was affected.

Back in May I wrote about making System Design Systemic and concluded that I had taken a soft technique from systems and applied to something much harder. I raise this because that is what I am doing here again. So it is an old example, but it shows that we can take systems thinking ideas & methodologies, and apply them to our harder technology world. And if it helps to make what we do more effective, and more consistent then is that a bad thing?

Advertisements

Why did you do that?

One part of my day to day life is that I research into areas and try to make sense of them, often against the clock. I’m either good at it, or the fool, because I’m frequently asked to do it.

To be honest “making sense of them” actually means deciding if what I’m looking at is suitable & beneficial, be it a technology or solution that my organisation could derive value from, or on the OU module I’m currently taking it’s more about how I can usefully use what I am learning about.

The thing about trying to make sense of something of interest is that its not just understanding it and how useful it could be, its about being able to articulate that to others, and it’s only when you try to communicate your understanding that you actually realise how little you actually do understand.

It’s interesting when presenting to others to see the various prejudices that are carried along with peoples thinking, which is generally made visible in the challenges that come back. Geoffrey Vickers came up with the idea of the Appreciative System which really applied to understanding why people think the way they do, which in turn means looking at their past and what events and values have shaped that view (their “Appreciative Setting”). So run back in history & see the key events and learning that someone, or a group, has been through and you can start to understand why they are thinking like they are and thus why you’re getting the specific challenges.

I’d suggest the same methodology would be well applied to some artifcacts as well. When I analyse a solution or technology, I often find things that at first glance leave me asking “Why on earth is it like that?”. A good example here is a project I’m working on around a major ERP deployment. One option we have is very mature with a large market presence running into hundreds of thousands of sites worldwide. Look underneath the covers at the way it works in some places, especially the integration between modules, and you find a regular muddle that makes little or no sense at first glance, indeed it almost suggests a lack of architectural governance. And speaking of the architecture, it also looks very strange in these days of objects and service oriented architecture.

Of course, at that point trying to present this to colleagues I got the same responses from them, and these unanswered challenges leave a feeling that doesn’t help with trying to present a benefits case. You end up with a senior exec saying “How can it be good for my business when everybody around you has these questions (that I don’t actually understand) that you can’t answer?”

Now try to use something like an appreciative system and run back through history – the integrations didn’t all come about at once, they appeared over time and in some cases represent the state of the art at that moment. Secondly they were probably developed in phases, so some represent must-haves that had to delivered in a first wave as quickly as could be done, later phases probably had the benefit of more time. And when you have a global base of that size, the cost & risk of rewriting older technology code to a newer technology just doesn’t make sense. These are conjecture on my part initially, but I can now ask questions to confirm or disaffirm my thinking.

I had a similar experience looking recently at the C++ language, based on some technical developments being done at Microsoft that could impact our development team. As a BCPL man myself, C++ looks way OTT: types on variables? objects? the referential model? Yuk! But then I found a paper written by Bjarne Stroustrup about the background and the design decisions made when evolving C++ and a lot became much clearer, as did positioning why you would want to use C++ in soem case and not in others.

In both cases, knowing why something has been delivered the way it has helps me to put it into context. No longer am I looking at face value and making decisions on that alone, but by tracking the past decisions I get an understanding of what underlies how what I’m looking at came to be, and that way I can make more sense of it.

The problem then comes in making compromises, as a strategist I want to reduce complexity and go for purity wherever possible. Yet in understanding as much of “Why?” as I can, I then understand where and why I need to make compromises on that. Fundumentally I move the messy problem from the technical domain over towards the business domain which can only be a good thing

Vendors – a word from a poacher turned gamekeeper

Nearly five years ago I gave up working for vendors, having been on the supply side of the IT chain since leaving university in 1982, and moved to the “dark side” by joining an end-user organisation. To be honest, it wasn’t a difficult transition but it is also a constant learning experience.

In the past week the differences between the supply side vendor view of the world, and the demand side end-user world have been bought sharply into focus. As part of a significant project I’m involved in, we have taken out one option and I have had several conversations with a major software organisation and some of its business partners to explain the decision.

I’m not the first person to comment on this, James Gardner(*) in his blog wrote a couple of articles about his view of the vendor approach and especially what he called “Proof of value”. Pity a few vendors haven’t read it.

For me, the biggest issue that the vendors I deal with don’t seem to be able to get to grips with is how end-user projects are costed. Before we go anywhere on a project the rule of thumb we apply is that the vendor costs will be one-third of the total project cost, and that isn’t including cost of ownership. Yep, that’s right: you sell me a £250k licence and I’m looking at a project of about £750k, and as we do the detail to get to business case the rule of thumb tends to be on the low side dependent upon the amount of transformation around the project.

So what is it I’m trying to articulate here? Well, I’d say there are a few points I tried to get over in my conversations this week:

  1. Reducing the product or licence cost is always good, but it rarely makes or breaks the total project: As we move towards product selection, we frequently get into a price negotiation. That is natural, but understand that making a 10% or 20% gesture is welcome, it is only a small part of the total cost. If it’s going to take 500 man days to implement your project then you can do what you like with the licence, it’s not going to reduce the implementation cost. And that leads to the next point…
  2. Implementation does cost: My organisation, like many others, does have to put implementation and other services into the financial reports. I often hear of talk about “funny money”, in one way it is but as far as our accounting team are concerned, it’s not funny at all, it’s quite real.
  3. It’s not the base cost, it’s the options: If I’ve learned anything, it is that the little things around the project that add-up; just like putting the options on your new car. Powerful servers are not that expensive relatively speaking, but start thinking about how many you need if you are to provide a highly available service and the costs rack up….. and we do need to provide a highly available service these days, in fact we’re now having to specify for 24×7 on services that previously wouldn’t have needed that level of SLA.
  4. Proof of Value is crucial: Given the size of some projects, we have to justify them to our governance organisations. If I am committing to a large spend on licences & people, then I need to be able to have mitigated any risk. The larger the project, then the larger the risk, and I cannot offset any potential risk against slideware. I’m not saying that I need a vendor to jump through hoops of fire here, just to understand the size of the project and thus the level of risk their product represents as a proportion of that project.

To be honest I have some personal beefs as well, but I’ll save them for another time.

The conversations I had this week were all based around the four items above taken in-toto. Jointly, yes we do like to work in partnership here, we couldn’t prove the value of one proposition which is why we had to discount it. In every discussion I had, the vendors kept going back to the cost elements and not looking at the whole.

Guys, I’m here to discuss this further if you want to…..

(*) James also wrote about Crowd Sourcing Strategic decisions. I followed this up with him directly & he was extremely generous with his time & experience, a great example of how we should treat each other in business. I am very grateful to him for this.