IT Fundamentals – Page 2

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.

Improvise good lighting for video conferences

I have been witness to a number of video conferences where participants were shown as a shadow in the blazing backlight of a summer day or wonderfully only jaw and nose were visible. Not pretty, even though uncombed video snapshots are currently becoming fashionable…

At present there are no professionally illuminated video conference rooms available, so I have some ideas for improvisation.

A large amount of diffuse light is a good start. A bright full spectrum health lamp pointing towards a white wall is great for the job.

White curtains are not bad, especially if sunlight could shine towards the webcam. Coloured light, through a dyed curtain or an illuminated painted wall, should be avoided. On some webcams, you can adjust the white balance, but that doesn’t really work out nice.

Place the main light source behind the monitor. A work lamp, desk lamp or table lamps behind the monitor are well qualified. LED lamps are especially suitable because of the low heat development with high light output. Please make sure that the LEDs are flicker-free. Either purchase new ones or check their fitness individually with the webcam or mobile phone camera.

In closing, a note about the nose position of your camera. If you have to use the camera integrated in the laptop, please place a pile of books, cooking pot, cardboard, etc. under the laptop for the time of the conference. The same applies to mobile phones and tablets. Build a stable base 30 to 40 cm high, depending on your seating position, so that the camera is at your eye level.

Lean Management for Consultants

At Fujitsu, a Lean Management methodology called Sense&Respond® is widely used for service delivery in many areas to achieve improvements in IT operations. Some time ago I was interested in this methodology, then it became fascinating and about 2.5 years ago the idea came up to use it in my area, i.e. for presales consultants.

We are a team of Presales consultants for End User Services, which means that we are many times on the road in different projects to advise customers, to explore the business value of Workplace, to develop solutions together, to submit offers or to solve problems.

Applying Lean Management encountered two typical answers. First, “Lean is old and obsolete, why don’t you do something agile?” or second, “Lean is for production, not for consulting.

If you agree with me, I might be able to stimulate you to read (and imitate) the following keywords:

In the key area “Blueprints” we have increased twice as much productivity
We have our training 100% under control, which is a real advantage in view of the current rapid developments in the Workplace area.
Overtime and travel times (approx. 30% of the time) are far lower than the market average, and
We actually know our value as advisers to the client, which means we know what to deal with and which is trash.

The problem was indeed all lean management methodologies and testimonials revolve around products or services. Usually an ongoing manufacturing process in which the entire team has a common task. For us, only the “consulting” approach is similar, the current “business value creation” products are very different. It was therefore quite a journey to apply Lean Methodologies to our consultants. I would like to tell you about this trip in the following article, but an important warning first.

A mindset like Lean unfolds its value, in such a way that team members themselves raise potential for improvement and one responds to it together, hence the name of the method Sense&Respond: Recognize something and react appropriately to it.

If you check out our methods, please take them as an example. It could be that they are useless for your area (but of course they can be sensational). Tools and methods are a construction kit that has to be adapted. Methods must not be a meaningless extra work, rather they must have a value.

Lean Management is a journey with errors and insights, I cannot switch it on by a switch or delegate it to a quality team. So you are warned.

My team is spread all over Germany, that actually worked quite well in the past, but the spatial distribution is not exactly conducive for the introduction of Lean Sense&Respond. For the first steps like defining the mission it took us a long time and the first problem Solving Sessons lasted forever. In fact, small sub-groups are responsible for speeding up the process, preparing and coordinating a measure for the most part. The preparing steps may seem like fulfilling a duty, but they create a sound shared understanding.

The most noticeable breakthrough for me was Quality Function Deployment (QFD). We asked our internal and external customers what they really wanted from us and why. So what do you want from a presales team, not what do you want from the services we help to sell. We already knew many of the points we found, but the QFD has put them in the right priority, also points have come out that serve for our further development. For example, customers prefer to have their costs reflected 1:1 on their cost center structures. The disadvantage, however, is that such a procedure changes the given price sheets. But this suggestion is absolutely vailde, because only so costs can be avoided really effectively. From the QFD we have created a set of orientation rules and consulting know-how, which allow us to estimate procedures well and also contain some No-Gos.

We have restructured our weekly virtual team meeting, this is now facilitated in turn and successes, such as concerns (Concerns) structured. Follow-up activities are derived from concerns that address the team or the organization. This can be a problem solving session, for example. The most important thing that has emerged is mutual responsibility.

When we started Sense&Respond I drowned in Concerns that were assigned to me. On the one hand because we are the first presales team at Fujitsu, i.e. our neighbours in the organisation didn’t know about it, on the other hand because we didn’t fully understand the mandate which Lean gives to each one of us and haven’t yet accepted the responsibility for it.

I have to admit that I was always uncertain during the whole journey to our own quality improvement toolbox. Many of the methods and procedures we invented turned out to be useless in version 1.0 after a few months. They started to smell like bureaucracy, were annoying or information graves. We have sharpened our methods for the third time in the last 2.5 years. Some of them were actually only polished up because they had forgotten over time that this method is valuable and others were completely rebuilt or thrown overboard. In general, one can say whenever we create a new methodology or approach: It typically takes a year or a redesign to get everyone’s fun going.

After months of experience with Sense&Respond, the main result is a team that works closely together to address shortcomings, improve quality and promote efficiency. Even if this has always been a very stressful time for an organisation and its clients. My team already was a great team, but now we have a deep understanding of our added values and shortcomings. We promote the added values, help each other with our imperfections, and that much more naturally than before.

I started this blog post as the beginning of a small series, because I am sure that lean methodologies will have a long future with us in the team and can also inspire other consulting teams. I will be happy to tell you more details here, but I will also be happy to talk to you at any time.