Seeing the other person’s point of view is important in any situation. Unfortunately in IT, seeing the business point of view is not something that always happens. In reviewing many private and public organisations, I have been exposed to many views from the business areas. Here are a few of those views.
The Big Five Lessons on Customer Perspective.
Having observed many transformations of somewhat inexperienced business people to highly competent project participants, here are the top five things they discovered. Selecting these five was difficult however after going over hundreds of hours of interviews with business people, and rereading many reports, I have narrowed it down to five. These are the things I would tell the Sponsor as well as key Business people
1. There is nothing like learning from experience.
Telling you what will happen is never going to have the same impact as living through a project. As a home renovator, I heard all the horror stories before I started, but thought I knew better. Those sorts of things could not happen to me. Well, they did. I don’t want to go on about the problems with builders but it is indicative of the human condition that we don’t believe some things until we have lived through the situation.
For a business person, becoming involved in an IT project for the first time, the situation is the same. No matter how much they are warned, they do not expect the situation to unfold in the way experienced people tell them it will. The discussions a business person has with IT types seem unreal. They believe IT people don’t know what they are talking about.
To be fair, if the situation were reversed, and for example a programmer was given a job in customer service, the situation might be equally difficult.
That is not to say we should not be talking about the likely problems. We must create the expectation with business that it is not going to be a bed of roses. There will be problems.
2. People are smarter than we imagined.
|A computer system is a dumb thing. It needs every decision to be programmed. That means we need to get inside somebody’s head and understand the nuances of how they make decisions. For instance if a piece of paper lands on your desk, what do you do with it, and what are the rules. The subtlety of reading meaning into a document that might not be evident to a machine that analyses bits and bytes is still beyond our grasp as programmers.
It takes time for business people to understand just how clever humans they are. Many times I have heard a business rule defined only to hear later “. it is true except where.”. It takes time for business people to think in terms of inflexible rules that need to be built into a machine.
3. The Sponsor is in Control.
IT is daunting. It is full of jargon and IT play on the jargon to build a wall around themselves. One very enlightening discussion I had with a Sponsor of a multi-million dollar project went like this.
“I saw the project slipping away. We were getting bogged down in detail and developing functionality that I thought was not needed. Fortunately, after asking you to look at the situation, you told me the critical point I was missing.
You asked me was I happy with progress. I said no. You then said to me that I was in control, so what was I doing? It had never occurred to me that I was actually at the helm. The penny dropped. You had reminded me that regardless of all the techno-babble, I was signing the bills. It was time to make myself comfortable with the progress regardless of how dumb the questions might seem to some technical guru.
I called the team together and told them where I saw they were drifting away from the direction we had set. We discussed it and to my surprise they agreed. They were as lost as I had felt. We stopped, reviewed where we were going, and changed course. After that, I felt more like a manager than an unwilling passenger. The project team started talking to me more about what was happening, and we suddenly started making progress.”
It is sometimes hard for the Sponsor to take control when it all seems a technical minefield. It is like being diagnosed by a doctor. You just hope the doctor is good at what they do because you don’t have the skill to know for yourself. From the very start, the Project Manager needs to reinforce with the sponsor that they are ultimately responsible.
4. Problems will happen
Another quote from a Sponsor was along the lines that the first time the team came to them with a major problem, they thought the earth was falling in. The nature of projects is that problems do happen. There will be more problems in a project than in a normal business environment.
The fact that there are problems to be solved is a positive within a project. If there are no problems to be solved, it means they are either not being identified, or they are being glossed over without sufficient consideration. It is difficult for business people to get used to the constant stream of problems.
Part of the business role is to identify the appropriate level within the organisation to solve the problem. Sometimes a business participant can solve it. Other times it needs to be escalated to the Sponsor. Part of the role of the project manager is to identify the correct level to escalate the problem.
Another key thing to encourage is to escalate the problem with possible solutions. The decision is the responsibility of the person to whom the problem is escalated. Coming up with ways to solve the problem is the responsibility of the team.
5. Uncertainty is a way of life
Projects are full of uncertainty. As project people living in that environment, we have grown to accept it. Perhaps it is the type of people who are attracted to projects, or perhaps it is the years of conditioning. Generally speaking we accept less certainty in our project existence then in a normal ongoing business existence.
Someone coming from a line management role is likely to spend their working hours strive for certainty. They want certainty about work input and output, roles, authority levels, and how to handle every situation that will arise.
The major difference is that in a normal business department, every situation that will arise is much more predictable than in a project. There is a significantly higher level of repeatability and hence predictability. In a project, our view into the future is much less clear than in an ongoing business role. The reason is that we are creating the future as we go. We are not traveling down a path traveled many times and created long ago. It is uncomfortable for some business people to both accept the level of uncertainty and then live with it.
This quote from a sponsor sums it up. He has just held a review meeting and I had explained that we could not predict the project completion date as we had not done enough to identify requirements.
“I accept what you are saying makes sense, but I don’t like it, I feel uncomfortable with it, and I find it hard to accept at a gut level. My biggest problem though is that intellectually, I know you are right. That really worries me because I have to go to the CEO and convince him to commit money to this project.”
Looking at it from the other person’s point of view could solve many of the problems between business and IT. Empathy is a wonderful tool for solving conflict. If you think where a business person is coming from, and talk to them about their perspective, it can only help.
Copyright Project Perfect