Language Timothy!
Wednesday, January 20th, 2010 by David MaliziaEach time my wife returns from the hairdresser the first thing she asks as she walks in the door is “well, how does it look?” It took me years to realize it but: “Oh, Just Gorgeous!” isn’t always the right answer, especially if the look on her face is anything but excited. I have been know to answer something like “did you ask for… That?” and the answer is usually no. So how did it happen? No matter which side you are on, providing or gathering requirements is a delicate and crucial point in every project: the point where most future disappointments are conceived.
In my career I have come across countless complex projects. If ERP is concerned complexity is expected and a lot of work is put into aiding project teams to steer all efforts towards a successful port. Prior experience and a general infrastructure are condensed and thoroughly documented into a methodology, a map to guide projects and project leaders and avoid everyone having to wonder what is to be done next. Most “technical” experts will find methodologies tedious and having to follow courses to use them utterly boring. I say so because I was one of them. Having said that, sooner or later you understand why they were written in the first place and why ignoring all methodologies is like trying to cross a street gagged and blindfolded. You may be lucky but if you are not it’s not going to be pretty.
I guess you might be expecting me to say that methodologies are the key to understanding you client’s needs but I am not. I have compared Oracle methodologies to other similar ones and they all go as far as telling you what you need to find out but not how. Indeed having nice tables and templates to fill in may even trick you into feeling over confident (while having none may expose the fact that you are clueless, which is surely worse). So how is it that you go about defining requirements? I feel the best place to start is by becoming aware of the most common pitfalls, the trickiest being language.
I live in Italy, I speak and have spoken Italian all my life. Most of my clients speak Italian and yet language is a problem! People working together, people doing the same or similar jobs are just slightly affected by language barriers and the common jargon becomes part of their everyday language. This is actually very useful since it keeps interaction simple and all information which is obvious to everyone is just omitted. Things get more difficult when you interact with people from different work communities, which is what consultants tend to have to do. But resourceful people are found in every corner of the world and many people really dislike having to tell someone else they don’t understand what they are talking about. Better to reach out and try to blend in! Without wishing to generalize, this “open minded” approach may have disastrous effects which I’ll try to explain with an example. My field of expertise is Datawarehousing and Enterprise Performance Management. It does sound fancy but the core of it is reporting and budgeting which doesn’t have the same ring to it. Oracle EPM applications have almost exclusively been built on multidimensional databases, staring with Oracle Express Server and currently on Hyperion Essbase. Again “multidimensional” sounds complex and elaborate and it also carries along another set of appealing words like dimension, cube, hierarchy and many other commonly abused terms. I feel a sense of wonder when I walk into a client’s for the first time and they have already worked out the list of the dimensions their system needs, having no idea how the technology works. Why did they do that? Between physics and mathematics there are over a half dozen definitions of the word dimension and none of them apply to my work and there is even something worse. Everyone knows what a cube is and so what is wrong with wanting one with 14 dimensions? Defining requirements on Oracle projects is or should be quite different to taking orders for fish and chips, but it is easy enough for things to go in that direction.
In most cases my clients have a lot of experience working with Excel. They run reports and create amazing and enormous spreadsheets. My job starts very often just going back to that. Their company is getting a multidimensional system and a datawarehouse with state of the art ETL and a slick front end. This is enough to throw them off their balance and make them forget why I am there in the first place. It’s often a hard news to break but they are not going to be given new jobs, I am only there to improve the way they do their current jobs and give them better tools. So how do you avoid language problems? I like to keep in mind some of these points:
• Set expectations early and clearly, especially about what is obvious. Clients may not know what kind of system they are going to get but you should. New systems mean change and change can be difficult to take. It is reasonable for clients to expect that all that was simple on the old system will remain simple. So reasonable that they might not even think about mentioning it. Reasonable or not, this is rarely so. Prepare your client as soon as you can by explaining in detail what will be more complex and what will be simpler and what will just be better.
• Start from the end. Clients will find it simpler to explain how they work rather than on how they want your system to work. Yet they might feel you are interested in the later. Focus on what is pertinent to their job rather than on the features of your products.
• Make sure you have it right. Even after you sign off specifications you may find that something was not stated with sufficient detail or clarity. Realistic examples and scenarios can help both consultant and client. Make sure that both are involved in test planning and test case definition. If client and consultant believe a functionality should work in different ways, there is surely a problem that needs to be looked into.
• Use common sense and a little intuition. You will occasionally find yourself being asked questions which sounds like “will we be able to do this or that?” “can we add this or that?”. If you know the request is something the client will regret some time in the future then say so very clearly. Usually, if not always, adding unnecessary complexity will cause the end user to have to do more unnecessary work. It may be cool to have a house the size of the Louvre but it’s not as cool if you have to clean it on your own.
