IT Fundamentals – Werner Roth

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.

Boy, is IT complicated! Really IT?

„You do IT” or similar beginnings of conversation are very common to me for years now. After those opening words colleagues and friends tell me about their adventures with IT. How complicated it all is and that IT was meant to simplify life, etc. An example story goes like this, names and roles were intentionally left out.

User: “I change to the purchasing department on December 1st and have to apply for a user in the EiKaSys42 system”.
IT: “That’s what you should do in the UserPortal, I’ll copy the link in the chat for you”
User: “I have already searched there”.
IT: “Ah, okay, I’ll take a look… You can find it at Misc→external→purchasing→process→role”
User: “OK, Thanks”
…10 minutes later
User: “I cannot submit the form without the entry in the fields AssKeyU, EiRoMan and HerNoMo. Also my employee ID does not fit into the field.”
IT: “That’s where you enter your international employee ID, which is 6 digits long. AssKeyU stands for the key user assigned to you and EiRoMan for the division. I don’t know what HerNoMo is either, I’m just IT”.
User: “But I don’t know a key user or division, nor have I ever heard of an international employee ID”.
IT: “I can’t help you with this, I am only responsible for IT”.

You probably also know such a famous relay race, especially as a new staff member or with new procedures. Sometimes it takes days to gather all the information or users simply guess entries which leads to a lot of trouble later on.

Another common scenario is a business department provides an automated process that users must perform once a year or even less. This machinery then queries similar cryptic entries, temporary results cannot be saved and help fields contain very luminous entries such as “In the HerNoMo field you must enter the HerNoMo of your division without leading zeros”.

Who is really the problem there? From the user’s point of view the problem is often “the IT”, because otherwise they wouldn’t tell me these stories. But this is not quite accurate. Yes, a decent IT could be more consultative. It would be very nice if a consultant team in IT didn’t dump all nonsense into portals and workflows without involving affected end users and extensive user stories. Often such a procedure is rushed in as the last action before a new business application is introduced, without much trial and error.

However, it is also the responsibility of the departments to keep entries to a minimum. To provide a docket and a contact person for new employees. In my opinion – at least from the point of view of the company as such – it doesn’t make sense to throw non-specialist employees into specialist processes. The working time wasted there due to ignorance of the processes, the (non-intuitive) operation of specialized applications and incorrect, misplaced entries could easily be put into a back office that asks the user appropriate questions and serves him courteously.

So do me a favour and build systems and portals that are user friendly even when it comes to non-IT processes. The users will thank you.