IT Fundamentals – Werner Roth

Bureaucracy and rules away, correct?

At the moment, people often say that bureaucracy needs to be reduced. That’s a good idea in general. However, in one interview I heard an entrepreneur throw away the baby with the bathwater. He demanded that many of the rules that he believed had been invented by politicians and the EU should be abolished in order to finally be able to work properly. These included important rules that, in my opinion, do not create bureaucracy, one after the other.

I actually think it’s important to have rules in the form of laws or internal policies. I don’t want hotels to store my data for as long as they like or for companies that are particularly careless with IT security to get off the hook if they lose my data in a ransomware attack. It is also damaging for the economy if we have no basis for security in these areas.

However, it is crucial that wherever regulations cause effort, this is minimised as much as possible. If in doubt, data collection should be avoided. Processes must be analysed for waste and what remains must be automated. Rules also need to be reviewed for their value every few years. Perhaps other rules have changed the situation. The same applies here: if in doubt, throw the rule away.

In companies, but also in public administration, I would like to see pragmatism; there must be an authority that can interpret and change a rule. I remember an occasion years ago when I was responsible for part of the IT operations. There was a major incident and we really needed all hands on deck.

Finally, an external technician came to the data centre for a repair and a member of the support team asked me who we should now detach and send to the data centre with the technician. According to the regulations, the trainee I suggested, who had been employed for 3 months, was not allowed to go with him. In my opinion, this was simply not foreseen and the wording in the regulations was unfortunate.

We briefed the trainee and let her take on this task. I informed the IT management in writing and a few weeks later we amended the policy. That’s what I mean by pragmatic. Understanding what was meant by the rule and courageously taking a diversion. Rules have a purpose, they have to be simple, practical and adapted.

Just ask how you can improve

Following the principles of lean management, we have discussed with many customers over the last few weeks. By asking them what they personally feel about the work we do. Their opinion of how we work as a presales team, not about the company’s performance as a whole or the level of customer satisfaction at the present time. And who could answer this question better than any line manager? Our customers!

Fortunately, we’ve had quite a bit of practice at this now. Doing this for the first time takes some arm-twisting and it feels daft on both sides. Customer surveys on products or services are familiar to us. Consultants asking to be criticised feels rather strange.

After some initial irritation, customers realise that we as a team are concerned with improving. This understanding is enhanced by a method based on Lean. Time again, all the conversations were great. There was compliments, but also some insights that are hurting, which is precisely why we are doing this.

This year, I have to say, I’ve been amazed at how rapidly our business is changing. We started an agile presales approach “Agile Business Accelerator” in 2018 with the expectation that about 25% of the market would demand iterative approaches. However, during the customer interviews, we discovered that all the customers we interviewed required an iterative, business-generating approach.

Customers presented this in their style and the culture of the companies rather differently. Oftentimes, they don’t even use the word “agile”. I consider this to be very valuable, business values are needed, and we find a suitable methodology together.

Thank you for your commitment and openness!

About transparency

Some years ago, I attended an inaugural lecture by a division head in which she analysed current figures from her reports, identified discrepancies and resumed. She concluded that these discrepancies indicated deliberate cover-ups. A circumstance that she will change. Because only a transparent system is able to provide people with the opportunity to act in a purposeful way.

I endorse the last sentence with all the knowledge and experience I have. Cheating, estimated figures or sloppiness combined with an 80s “management by objective” apparatus are the best possible nursery ground for mismanagement. At the very best, they cause frustration in individual areas, when everything fits according to the specifications, but the overall result is poor.

My own example above, by the way, did not end well; a new system was created that was consistent above all. This could be observed closely in the defects that were subsequently closed. I cannot say whether the original intransparent system was created intentionally. But I am very sure that the new system which was created aimed at concealment.

Now, there are certain areas where transparency is not permitted. Reasons for designated restrictions on transparency are, in my experience, Almost always fabricated. “We can’t give you the current figures, as you know one of our parts of the company is listed on the stock exchange.” When systems strive for transparency, it usually has a very different ring to it: “We want to better understand how our services are viewed by customers, so we compare x-and-y. The listed part of the group can only be included in the analysis in such-and-such way. But we are continuing to work on possibilities here as well.”

It’s about what you want to measure and what you can measure. People who understand Lean or Agile know that it’s a journey. Establish metrics which really move you forward, and in the best case these are lead-measures. Not forgetting to use the existing possibilities of “what you can measure” creatively and to create better chances.

In my experience, real good transparency is always a journey, not something you can finally achieve or even set by decree.

Why I like visions

Often, visions come with a bad name. Some even see them as irrelevant decoration. This is true for many visions. You can find global-galactic versions, all-encompassing more-beautiful-further-faster editions to preposterous visions that are essentially meant as a kind of misleading advertising.

In my experience, managers who don’t think much of vision can very rarely say in a nutshell what direction they want to take. When asked about the direction, they typically say something about making money in the industry in which they work. But customers don’t buy from me so that I can make money. Money is the compensation for something that is worthwhile.

Having visions can be a particularly good North Star. In programmes or projects, a half-day vision workshop is definitely rewarding, especially if the project is under time pressure. The people involved then know where they stand and have fewer wrinkles on their foreheads. They decide more often in a concerted direction. When problems arise, the alternative options for solving them are usually properly pre-sorted.

Visions are directional for every kind of team. Newly formed teams find themselves together more quickly. Teamwork has fewer friction points. Especially when the business is in transformation, people find anchor points.
Even visions that are too specific and too near prove to be helpful. Especially because dealing with the destination together contributes to team-building. With some guidance and time, dealing with vision, mission, company purpose, values, etc. becomes more and more professional.

For practice, it’s best to think about yourself: What do you want to achieve? How do you want to succeed? Why do you want exactly that? Just like above, the first answer to such questions will be a solid “Um, uh”. And that’s a start!

A matter of blame

In my professional experience, I had the chance to work for a while as an escalation project manager involved in several projects that suffered from substantial imbalances. I was usually called in, at very short notice and had to get a clear picture of the project and the current situation in just a handful of days. It often disturbed my work when my time was wasted in initial meetings with mutual finger pointing. The topic of “blame” never got me any further, because it is more likely to cause losses for the projects – and yes, I am talking about blame eats real money.

The most remarkable instance was a project in which three providers had to implement a long overdue migration for a customer. One of the providers was our company. Several milestones had been missed, we had to pay contractual penalties and the go-live date seemed hopeless because almost nothing was done.

The project was managed by an external project manager who explained to me in great detail that the three providers were not working together and told me many stories. After the third or fourth anecdote, I asked him what he had done to remedy the situation, but he did not give me a clear explanation. Which was not a good omen.

Together with the representatives of my own team and the other two providers, there were massive finger-pointing disputes. Within the team as well as outside of it. These discussions went on and on. I hardly managed to find a way to discuss the most important next steps with the parties involved or even to draw up a battle plan for the next few weeks. Again and again it was a matter of blame. At some point the idea crossed my mind, which I actually said out loud, “OK, I’ll make myself available as a scapegoat, I’ll take all the blame!”.

The next 4-5 accusations – which of course came up – I accepted and said, “Stop, I’m the one to blame, that’s what we agreed” and such discussions came to an end. I did the same with colleagues from the other providers who were typically our competitors in other bids. This enabled a bit more focus to the large project group. So we had enough material and discussed the most important issues in a smaller group on the next day.

Apparently, a crucial obstacle had not been addressed in the project, the customer’s contribution was lacking everywhere. That’s why even the teams that could have worked independently were stuck. It also seemed strange to me that contractual penalties were paid even though there were almost no contact persons named on the client side.

The project manager told me that he was not responsible for this, he explained to me in many words why this was not covered in his mandate. I was already fed up at this point, so I met with the other two providers and went to the client. With the help of sales we had high ranking contacts who were shocked and provided (slightly) better support as well as stopping the penalty claims immediately. This was actually due to a bit of luck, a moment of surprise and, above all, the well-connected sales department.

The next day, the project manager entered the office with a bunch of papers – which turned out to be his contract – and wanted to explain to me in writing that he was not responsible. I was sure he was in for a bad surprise already. I asked him if he really wanted to explain, that he was not responsible for a monthly saving of a lower 5-digit amount on behalf of his clients.

All three of us providers were able to reasonably save the project together. Somehow a good esprit de corps evolved quickly in the project. We dismissed the project manager in unison from his contracts and – each in his own organisation – replaced some team members to the best of our ability or filled them in with freelancers. After that, we worked jointly, took care of each other’s tasks, provided test systems and managed to get the project done almost on time. The necessary approvals were obtained just in time, mostly on beta releases, version 1.0 could only do the most essential tasks and the final version was 6 weeks late.

An initially very upset head of department from the customer eventually helped to ensure that the 6-week delay was probably only noticed by a few end customers. Everyone was proud of the work and competitors thought it was sad to wave valuable colleagues good bye at the end of the project.

However, I wanted to write about blame. The blame game didn’t help us at all. And when I think about it, the people who fighted on blame the loudest were those whom we had to exchange. Not being guilty and blaming others often translates in not willing to take responsibility.

I have used this line “OK, I’ll take all the blame!” many more times. Because I never experienced in any of these problematic projects that there was really that one person or department to be blamed. The closest thing to “blame” I have experienced is incompetence. When companies send people into projects who don’t have the necessary professional competence, that make massive mistakes, then again we’re not talking about blame, but a lack of professionalism.

Blame almost always leads to unaccountability, which is often combined with financial harm. There is actually a type of employees who don’t care that their company is losing money. The problem is not their fault, after all, but someone else’s. End of story for the mindset of such persons.

Projects and organisations that cultivate blame as part of their culture are in fact zero maturity in most maturity models. There is a good reason for this, not only because it sucks to work there, but also because blaming is like an anaesthetic for progress. Striving for efficiency or even innovation is not wanted in those organisations because exploration always brings risk, errors and failure.

You do indeed find this kind of culture in projects more often than you think. Usually as a kind of senseless scapegoat principle, the blamed parties don’t actually have to fear any serious consequences, in the next project they sit on the other side of the table and then they nominate the scapegoat.

If people need a scapegoat, that is perfectly understandable, but it is simply a lack of culture.

What did I take away from that time?

Blame is neither productive nor does resolve problems.
A scapegoat culture encourages non-responsible behaviour, which always costs money. Lack of efficiency is also expensive.
Unfair blaming is a gigantic demotivator for project workers
A history of ignoring or killing the messengers is a huge burden for projects. Problems never disappear, but messengers get quiet. Late phase problems cost a lot of money. Try to get their trust back.
In complex projects or in projects that progress empirically, mistakes are inevitable and must be used as a driving force. Blame has no part in this.
If you succeed in looking at the big picture, many a “not responsible” party will turn into a quite capable project worker.
Winning trust can even motivate an employee who has been beaten and kicked by his management as a scapegoat. I succeeded once, this good man was 15 months short of retirement, which made me very happy.