Author: Neville Turbit

The Problem with IT Projects

In research on ERP systems, time and again a key point of failure is the difference between what was delivered, and what the users expected. User expectation, or change management, is continually raised as a top three priority for people who have implemented ERP systems. Even in lesser undertakings, it is a key risk area.

When you buy any major consumer goods, the product was not just developed in a lab, and delivered to the store. A major part of the development cycle is about how to package and present the product. What features are important and why. What are the key things people want to see, and what are those that will turn them off.

Market Research

Enter Market Research. Research is carried out on consumer goods using both qualitative and quantitative techniques. Qualitative techniques probe peoples perceptions about a new product. Where are they coming from, and where do they expect the product will take them. Quantitative research provides measurable results that indicate propensity to buy, satisfaction ratings, interest, likes and dislikes etc.

So why don’t we do it for IT projects.

Captive Market

One reason is that we believe in Corporate IT, that we have a captive market. The organisation needs a system. We deliver it. The users must accept it. We don’t think about the difference between accepting reluctantly, and gaining whole hearted support.

If however, we are able to tweak both the product and the project, to gain the whole hearted support, life is going to be much easier. Not only that, but it is going to be less expensive for the organisation in terms of getting people to own and use the system. How people make use of technology can make enormous difference to operating costs. Think of the number of organisations that have issued Palms to their sales force, and they have never even been turned on.

Cost and Expertise

Usually we don’t have the budget or expertise to do research. Budgets come about because you put up a strong case for funds for a specific component of the project. If you don’t know how to justify a research budget, think about this.

If everything goes well, and the users support you, how long will the project take? On the other hand, if users fight you all the way, how much longer will it take? Hypothetically, let’s say the if all goes well it is 6 months. If we have a fight on our hands with users, it will take 8 months.

If the cost of the project is $50k per month, the difference is $100k. A professional research study of users expectations and attitudes might cost $35k. In other words, if the research can identify how you can improve user support by 35%, it will pay for itself. Anything more is a bonus.

Benefits from Project Market Research

Carrying out a user survey at the start of the project, can have many benefits.

• Makes Users feel they are involved

Just the fact you are asking people about their views before you start can have enormous benefits. People feel their knowledge and experience is important. They are suddenly predisposed to becoming part of the process

• Understanding initial expectations

The research will identify any underlying expectations. They may be realistic, or they may be totally unrealistic. If they are identified up front, the cement has not had so long to set. To change expectations, you might have to dig up the foundations and move them somewhere else but it is going to be easier at the start than half way through the project.

Breaking the news to users on Friday, that the two year project going live on Monday will have teething problems, is not going to get a good reception. Telling them the project just starting will go live in two years but we should expect at least a month of settling in, is a better approach.

• Prioritising expectations

By researching potential benefits, you can find the most significant expectations that need to be promoted. In researching a mainframe outsourcing project, one of the key expectations was that because the mainframe was across town, response time would be significantly longer. Once this was identified, we focused on response time as a critical success factor.

In fact we had users measure it on the old system, and then on the new. One of the contract conditions became no degradation in response time as measured by the users. For example, we had users repeat name searches and average the response time. When they repeated the exercise on the outsourced system, times actually improved.

• Platform for Requirements Gathering

It is inevitable that requirements will be identified during the research. The line between requirements and expectations is blurred – as it should be. If we go into a hardware store, we might want the functionality of a tape measure but we also have to make some emotional decisions about the colour. If the tape is in a shrink-wrap package, we have expectations about the size of the numbers, and the clarity of the lines marking the fractions. Some people might find it important that it shows both centimetres and inches whilst others might not. These are both requirements and expectations.

Research provides a platform for the formal requirements gathering phase. Rather than start by asking people what they want in terms of requirements, you have an understanding of particular areas of emphasis in the requirements. In the example above, perhaps the colour of the tape is important to a number of people so they can identify their tape from those of others. It might be something that needs to be added to the requirements.

• Focus Early on Critical Requirements

In doing a package selection, we researched key players about their expectations. The CFO was not a supporter of the project. She continually talked about her expectations that the system would cause massive disruption during implementation. It seemed she had been through a very complex data conversion some years ago and had suffered from corrupt data for several months after the event.

When we started gathering requirements, there was a strong focus on quickly identifying business rules and how they had changed over the years, data quality issues, and problems caused by current functionality limitations. By working directly with the CFO to identify and plan rectification of any problems, we gradually gained her support.

By the half way mark, she was the one breaking down barriers for us. She became a project champion at the board level and certainly was largely responsible for the project success. All this because we spent the time to research the project and it told us to change our focus in gathering requirements.

• Broaden the Scope of Requirements

There are two ways to ask a question. The first is to put a closed question such as “What fields do you want on the monthly sales report? You can have up to 256 characters across the page.” The second is an open question such as “What would be useful to help you manage sales? What can you influence in achieving sales?”

Requirement gathering risks asking closed questions. “Give me a list of reports you want?” A skilled researcher can probe the person’s role and what technology could be useful. The answer to a proposed business problem might end up having nothing, or little to do with technology.

Market Research Expertise

Having stated the case for market research, we need to ask the question about bringing in a market research specialist, or DIY (Do It Yourself). It is the same as using a new technology. If you have the training and experience to implement the technology, and you have the time, you do it yourself. If not, get an expert.

• The skills required will vary by project however the following are relevant.
• Experience in researching attitudinal aspects rather than a purely quantitative background
• Understanding of IT systems, and the SDLC
• Not mentally locked into a particular path
• Preferably a background that has some aspects of change management

The person may in fact not be a professional researcher. They may be an experienced IT person with good facilitation skills, who has successfully initiated many projects,. Being able to interview either an individual, or group, is a key skill of a good researcher. There is a delicate balance between keeping the discussion to a predefined path, and following important threads that might emerge during the discussion.

Another aspect worth considering is the credibility of the work. If it is carried out by the IT Project Manager, it can be seen as a token exercise with an IT bias. If it is an independent researcher or consultant, it is seen as independent.

Conclusion

Any significant organisation developing a new product for their customers will not baulk at carrying out some research. It is seen as both cost effective and risk reducing. Within organisations over the last decade, employee surveys are being seen as an almost indispensable tool for the HR area to improve productivity, staff performance and corporate working environment.

Just as with a new product, a new IT system can have significant cost implications. It can effect productivity and staff morale. As has been shown in a number of organisations, a failed IT project can cause the demise of the company. It is worth spending a little time and money on researching any significant project.

Copyright Project Perfect