“So much of what we call management consists in making it difficult for people to work.”
Figure 1.2 How to Win Friends and Influence People?
But there is some good news out there. There are some ways for you to calibrate yourself with the datum of reality in the work place. Some companies are really very good at it. A colleague of mine who worked for a large supermarket chain in Europe described to me a fantastic model that I would recommend to anyone. Each year, all the senior managers and executives of the company up to and including the Chief Executive are obliged to spend more than a week of their time carrying out relatively unskilled tasks in the company's retail outlets or distribution centres. Some even got to meet real customers. This laudable act was intended to keep the feet of the anointed firmly on the ground. It also gave the executives a chance to understand what working at the sharp end was really like. Finally it was a great morale booster for the checkout staff as they watched their hapless leaders struggle to weigh a pound of apples or puzzle over the pricing of a kumquat.
When my friend returned from his short sabbatical, I quizzed him on his experiences. First of all, I noticed that he was limping and he had a bandaged hand. “It's a lot more physical than you would expect”, was his response when he noticed me staring. “What did you learn?” I asked. He narrowed his eyes and looked at me threateningly. “Doors!” he cried, “I never realised how impossible doors can be.” I was taken aback. The only software package I had heard of that had “doors” in the name had nothing to do with retail warehousing. “Well” he continued, “the way that my people designed the warehouse systems means that anyone using it had to walk through at least three doors for every single transaction they did. That's how I damaged my hand. Someone was coming the other way at just the wrong time.” With rising emotion he continued. “When I get back to the office the very first thing I'm going to do is to remove all the doors in our warehouses and make a great big bonfire with them. Then I'll make the project team redesign their system from scratch. This time we will really make sure that things work smoothly and reliably. Finally, we'll put the implementation team to work in the warehouse in real life for a good few weeks. When they complain, we'll make them work a few weeks more. That'll teach them.” With a disturbing glint in his eye, he hurried off. It had definitely been a formative experience.
“Great Spirit, grant that I may not criticize my neighbour until I have walked a mile in his moccasins.”
On the other side of the coin, an example of how to do this “process thing” really well also occurred in a warehousing project. The particular warehouse in question was critical to the company as it shipped over £120m of material and spares each week. The project team had found out that there was an industry-leading package to do this type of work, but unlike everyone else in the industry they curiously decided to use the package as it was designed. After they had installed their un-customised software, they took over a small warehouse building where a simulation of the proposed system was built. Each process was developed and tested exhaustively. Many, many members of the real workforce were intimately involved throughout the whole exercise. When the team was satisfied that it would all work, they proceeded to the implementation phase. They then carried out three full dress rehearsals with real data before the system went live. The last of these involved complete and full parallel running of both the old and the new systems. This was done with production data from the full, burgeoning databases of dirty data that comprise “real life” usage. This approach meant that each transaction had to be carried out twice, once in each system. They had, of course, to roster two sets of shift teams (comprising hundreds of people in each) to adequately staff the expensive parallel operation.
When the system did go live, it was notable that performance metrics did not fall away as expected – in fact they improved. A few very minor glitches did appear in the days that followed (largely through data integrity issues), but the project team and the workforce swiftly dealt with each of them without undue impact. The parallel running regime meant that customers would not have been impacted anyway. In fact, the cunning inventory-building program that the Stalinist project manager had introduced in the preceding weeks to buffer the inevitable unexpected problems meant that he was well insulated from any transition glitches. The project team also stayed in place, watching as well as participating. After three weeks and one full business cycle of live use had passed, a number of improvements were identified together with one or two minor howlers that needed to be corrected. These were swiftly implemented, regression tested and released. The result was a happy workforce that was considerably more productive than they had previously been. Unlike most IT projects however, the celebrations only started once the new warehouse was stable and transacting at the higher volumes stated in the business plan, rather than when the code was “delivered”. The key point here is that it was the business outcome that was celebrated, not the IT project.
The outdated concept of projects being celebrated when they go live, rather than waiting until they have actually delivered benefit to the organisation is a nasty and dangerous practice. It should be consigned to a list of “bad things we promise we will not do any more”. Imagine a situation where a surgeon and his team down tools, whoop with joy, crack open the champagne and start celebrating a few moments after they'd cut out your tumour? Mercifully for us, they do bother to sew us back up again. They also continue to monitor us with professional aftercare to make sure the problem really has gone away. We really could do with a great deal more of that sort of TLC in the IT world. Any IT project teams who toss a lemon of a project over the fence onto the heads of the defenceless user community and run away deserve everything that they get. Having a warehouse door slammed in their face would be a good start.
The Joys of Middle Management
Just who are the middle managers in an organisation? What do they do, where do they come from and why are there so many of them? Well, we could enjoyably argue about the definition until the end of time, especially if we let any middle managers join in the discussion. However, let's just for the purposes of this debate define them as people in the organisation who report to a manager, but also have managers working for them. In other words, they are not directly connected either to any real work that goes on, nor to the leadership who are making strategic decisions at the top. This insulation from reality means that these creatures can sometimes live in a strange and wondrous world of their own, where the skills of managing meaningless meetings and enduring endless emails have risen to the status of high art.
“Meetings are indispensable when you don't want to do anything.”
Much fun is poked at middle managers, and they are often parodied as being faintly ridiculous. However, they are creatures of nascent danger to any IT leader. This is not because they are bad people, but because they are managers. As managers, they will feel that they are able to make things happen, not only on their patch but elsewhere in the organisation as well.
Middle managers who use computers often feel that they have a right to both demand and get a shiny new software application to help them do their job. This “right of entitlement” is an unusual concept in corporate life that seems unique to IT. Managers certainly won't dare ask for new carpets