Archive for May, 2007

Should customer know what they want?

Wednesday, May 23rd, 2007

It’s an interesting question which occurred in my mind. Over the years, I have realized that it is unreasonable to expect the customer to know what they need. 

In IT industry when a customer decides to go for a customized application or implement a software solution for a business requirement, they look for partners to outsource the job. As part of the requirement gathering phase we often realize that the customer is not fully aware of what actually the need is. The Account Manager realizes this and hopes to offer the expertise the company has to the customer. When the project manager gets involved, he/she plans the project based on the initial knowledge and comes up project plan with resource needs. The expectation that this Project Manager typically has, is that the customer should know what they need and there are not too many changes. When the customer expresses that it’s not the case, that’s when the trouble begins and all the mappings of change control, resource needs and meeting the timelines & budget comes into picture. 

Let us look back and understand if we understand what we want, when we make a purchase. Let’s take Car as an example as typically its one of the major decisions like IT implementation for a user company. How many of us really look at technical details of the car before making a decision? Do we look at : 

  • Power (bhp@rpm) 
  • Power to weight (bhp/ton) 
  • Torque (Nm@rpm) 
  • Fuel injection method ( MPFi, carborator based … ) 
  • Bore (mm) x stroke (mm) measure 
  • fuel compression ratio 
  • steering types (Rack and pinion, … ) 
  • suspension type (MacPherson strut, Torsion beam and coil spring ) 

Let me ask a more core question … do we even know the meaning and significance of the above on the vehicle to make a decision? At best we would look at mileage, CC count of engine, power windows/steering, A/C, internal space, other people’s opinion, maintenance expenses, brand image and go for the purchase… 

Moral of the story is that rarely customers know what exactly they need and are able to make a decision based on the technical details involved. We cannot expect the customer to know his/her requirements of the system, rather customers look at us to provide them with a solution and offer a roadmap with our past experience. That’s the real value of an IT partner to a user company. 

In most of the cases the customer would have an idea of the end-result that they need and how the system is expected to solve their business problem. A lot of times it’s a long order to achieve the end result as their are a lot of back-end processing and business process change need. Once the project commences, customer is able realize this and then real requirements evolve. Then the project goes through the changes from the original scope.

Hence the development methodologies used for software development becomes very important. Water-fall model is tightly compartmentalized and rarely near to reality while other new models are Rational Unified Process (RUP), eXtreme Programming (XP), Agile Methodology, etc. All these approach focus on the iterative nature of a project from different angles because of the base reason which is ‘changes’ in requirement during the project development. 

In my career of 7 years till now, I realize that the companies, who understand this, succeed much faster and are able to position themselves well in the market.

official statement.


Monday, May 7th, 2007

Quote 1: Change is the only constant

Quote 2: Humans by nature are resistant to change.

Quite an irony but true. We are resistant to change around and within us. What is happening is OK and we just dont want to change that. I have seen this nature at corporate level as well when business users say that this is what our process is and we would not like to change anything. Even the big financial institutions of wall street resist a change in technology which can make system faster and better.

Everyone has their reasons for not changing. Some of them are:
1. Logical: The current systems works fine and serves our purpose so why change.
2. People Fear: Change may affect my job, it might expose me.
3. Management Fear: This change is good for the company but I fear the resistance from the people hence would not opt for the change.
4. Attitude: I am doing fine. Why should I change, evenif things improve, who cares … I am fine the way I am.
5. Ego: Why should we change our process, let them map their technology to the process.