Feeds:
Posts
Comments

Posts Tagged ‘Service Provider’

Every interaction with a customer including complaints is an opportunity to build or strengthen our bridges with our customers.  Very often we find our customer-facing staff blowing away this opportunity that lands on our lap for free. To better understand this gift recall what we go through when we go out to engage a customer unsolicited.  

And how do we blow it away? Usually by keeping our interaction down to a crisp and a minimal response demanded by the context.  Technically flawless, business-wise not so wise.  Of course at the other extreme, we might have a loquacious rep overdoing it pushing the customer to annoyance.

What then do we do with this opportunity? Well, there are several avenues to be explored: we could gain useful insights into his decision making process (why or how did he settle on our product?), his experience with competitors, his post-purchase impressions, what else would he like to see as features, does he see enough of our brand publicity… If it is a complaint, information about events leading to the failure could be collected.  Did he have other issues/signals before the failure occurred?  Does he have thoughts on how this failure could have been possibly averted? Of course what would work depends on the temperature of the call.

All of these cannot happen without orienting our customer-facing staff adequately, constructing different possible scenarios and outlining avenues for enriching the interaction.  

Note outsourced call-centers are optimized to enhance calls handled in a day rather than quality engagement with the caller, at once totally eliminating this opportunity.

Incidentally all of the above apply to our interactions with prospects too.

Here’s a short well-written piece from Art Petty on this same theme exhorting us to have transformational interaction instead of transactional. A personal experience included. So why settle for less when its potential benefits could be dramatic?

End

Read Full Post »

you getting monkeys is not just with hires. Goes for vendors, contractors, third parties…

This is for the managers and executives priding on their ability to squeeze every freebie, concession and discount out of their beleaguered vendors.

Here we go:

The  headman from the painting cum landscaping company  was speaking with the hard-driving customer about the job awarded to them.

Laying-Turf  jokesoftheday.net

In the first room, she said she would like a pale blue. The contractor wrote this down and went to the window, opened it, and yelled out “GREEN SIDE UP!”

In the second room, she told the painter she would like it painted in a soft yellow. He wrote this on his pad, walked to the window, opened it, and yelled “GREEN SIDE UP!”

The lady was somewhat curious but she said nothing. In the third room, she said she would like it painted a warm rose color. The painter wrote this down, walked to the window, opened it and yelled “GREEN SIDE UP!”

The perplexed lady then asked him, “Here I’m telling you what to do and you keep yelling ‘green side up’?”

“I’m sorry,” came the reply. “them…are laying sod in the front and around.”

End

 

 

Source: Adapted from jokesoftheday.net

 

Read Full Post »

As English is not our mother tongue, we do not always worry too much about what we say or write. That’s how we promise our prospects/customers solutions that are the cheapest, fastest, most easy-to-use…If for a moment we translate all that we say into our native tongue I’m sure we would never be so generous with the superlatives, hurting our credibility in the eyes of our audience.

Along these lines is also the abuse of clichés. In recent times I came across two such instances bordering on the ridiculous.

value-added1 pmtips.net

In Udaipur, a restaurant chain claiming to hold Guinness record for making largest dosa’s, proudly talked about value-addition in its mission statement prominently printed on the menu cards. I thought they’re in the business of delivering value to their customers in the first place which is far from being convincingly established. As for the ‘additions’ to the arguable value, of course there is no hint to where these may be found.

Value-addition rears its head once again at a least likely place – a IES school on the Jogeshwari link road near Seepz. A large billboard outside the school main-gate claims value-addition through education. Here again, I thought, schools are meant to create values in the first place in their students that become deep rooted over repeated reinforcement.

Of course, I may have completely missed the points they were making. If so, my apologies are due to them.

End

Source: Image from pmtips.net

Read Full Post »

If you stay with me for a minute or two, you’ll know this is not the usual rant of an irate customer. Rather it’s an outside-in perspective of an interaction with your organization from some one who has been in the service industry for 30+ years. I’ve also taken the liberty of including some possible actionables (in italics).

Residing in Mumbai, I am an owner of Panasonic split A/C unit for a little less than a year now, recommended by the dealer. Happy to say it has been a trouble-free experience.

panasaonic

During this time I’ve had three interactions with the your company personnel (or those from your authorized service-center): during a no-fuss installation, the first service call within a month of installation (My friend, this call could have been avoided if they had shown me during installation when and how to clean the filters) and the third – the subject of this post – was a no-charge in-warranty preventive maintenance call offered by you.

As instructed, I called up the 800 help-line and registered a ticket. This was again hassle-free: a) every time, I was able to reach with the first try itself – may be you had equipped it with enough lines or there weren’t too many complaints flowing in:-) and b) unlike most interactive voice response systems that drive one crazy with a zillion buttons to be punched I was able to reach the person immediately after language selection. A great start to a user experience – all credit to you for a smooth process.

The youngster at the other end right away recognized the caller and was courteous in registering my request. I was told a technician would get in touch with me in 24 hours.

2-3 days passed, there was no call. I called up the help-line again to inquire. He – this was another guy, but mercifully there was no loss of continuity – assured me he was sending reminders to the service-center.

A few more days passed before I made another call. I was informed a fresh ticket was being generated now. The earlier one showed its status as closed for lack of complete information! I did not pursue with my line of sure-to-be-infructuous inquiry on what information was lacking and if so why did they not call me up to find out,

The next few days saw one more iteration of my calling up and being assured of reminders being sent. This time I expressed my wish to escalate the matter to someone senior in your organization – these friendly reminders were obviously not jogging memories in the field. The youngster was obviously not equipped to handle a request for escalation – my friend, please note. He repeated himself on those reminders and the 24-hour-call-back. When I pushed him, the poor fellow tried to be helpful by giving me the contact numbers of the local service-center for me to check directly.

So over the next few days my calls went to the local service-center. In the first call a senior lady at the other end sounded like being upset over my intrusion into the comfort of her daily routine. I dreaded at the prospect of running into her in every one of my subsequent calls. My friend, could you please ensure these customer-facing people are basically service minded (We all know not every one is) and trained for the job? Luckily for me it was not to be.

VOIP-Desk-Phone

And every time I was assured by the call-dispatcher I spoke to: the technician in the field has been informed and he would contact me. Apparently checking at the end of the day whether the technician had attended to the request or it was still pending for the following day was not part of the dispatcher’s job. She would know the job wasn’t done yet only when I followed up with her next day.  My friend, do they have systems in place to assist them in dispatching calls and track pending ones?

Coming back to my story, by now, I was in a fit enough to climb a tree. Before going to town with my story, I decided to give it one last resort try. I went to the dealer who sold me your product. To him, I painted your service-center in the blackest of inks suspecting sinister designs in those missed deadlines. He called them up and gave them a piece of his mind. A comic relief: in the same call the lady at the other end wanted to know my address from me. Why would she need it? She already had it as part of the registered ticket. Some address verification process in play? Well, it turned out quite unexpectedly: she did not have it with her presently to give the technician as her system was down!

The dealer’s call did what I couldn’t over the last week or two. Two lads turned up within a couple of hours taking address and directions from me after finding the dispatcher’s information to be incorrect.

I asked them if the management has changed hands at the service-center – why was my third interaction so difficult for me when it was not so on earlier occasions? I was told there was a severe shortage of field staff, this being summer vacation, hence the delays in attending to customers. In fact this duo was pulled from a different geography to attend my request. I promptly thanked them and the dispatcher in my mind for the initiative and explained: My request was for preventive maintenance – it was not a breakdown call requiring urgent attention. I was willing to wait for their service. If I were given a date and time even five days later, it would have been okay. My nervousness and the overreaction perhaps emanated from the steady stream of promises made and not kept. Was I being forgotten or worse, ignored for a reason unknown to me? My friend, please train the staff to ascertain the urgency for service and negotiate acceptable response times thereby relieving the pressure on the field resources. And most importantly to make good promises made and follow up until the request is closed. You’ll find many customers quite reasonable with their demands if the cards are put on the table.

Once they finished their job, I waited for them to write out a service/call report for me to sign off. Their response made me realize how much out-of-step I was with the times: ‘Service Report? What Service Report? We go back and close the ticket, that’s it.’ Brilliant!. An utterly wasteful step cut out! We all know no one at the service-centers or even with the manufacturers ever reads these reports.

Well, I’m sure many similar stories go around all the time especially concerning white-goods. What I hear is: Most equipment manufacturers outsource field support to third-party service-centers. And there is not enough money on the table for these guys to be motivated to operate efficiently and render good quality services. The manufacturers know it and are hesitant to push these guys hard lest they lose them altogether (significant turnover of these third-parties is very common). Rarely their systems, processes and people are tested, for example, with dummy customers. My friend, I don’t know how it is with you. It may be worth your while to take a hard look and make the business viable for these service -centers.   

To draw the curtains down on this story, all concerned know the A/C unit is close to end of warranty. No one is lining up at my door for the annual service contract. Not much in it for any of them, my friend?

Thank you for hearing me out patiently Panasonic. And pardon me if you consider it impudent of me to make those suggestions.

Yes, I forgot to mention: I sent a ‘Thank You’ message to the dispatcher after the technicians’ visit.

 

End  

.

.

Credits: image from openclipart.com ()

Read Full Post »

About eight weeks ago I subscribed to Direct-To-Home services from a leading provider solely for reliable service free of annoying breakdowns that were plaguing my cable service provider.

It was sold to me by a couple of trainees out campaigning door-to-door offering special deals. The facile answers from these guys to my queries about Tamil channels for my Mom’s viewing didn’t alert me on a day I was not at my best. Not knowing Tamil from Telugu or from Kannada or Malayalam, they were no way going to be right in their clarifications just as I found out later. I’m also going to forget the contradictory information given out by two Help-Line operators when I tried to add an option that was said to be included in the ordered package.

Fast forward to the present.

Over the last 2 to 3 weeks, we saw this problem recurring often – the picture would suddenly freeze on the TV and at other times we would lose the sound completely. When this happened the recovery was painful – we had to switch off and on and set the channel again. The ‘Remote’ was ineffective. Sometimes the MTBI (Mean time Between Incidents) was as low as 15 minutes. When this happened often on a rain-free day like today – we were cautioned right at the outset to expect short-lived disturbances during rains – I decided to ask for service.

Promptly I went to the site, did a month’s recharge that was becoming due and now looked for telephone numbers. There was no tab/link for Customer Service- obviously the thinking was their services would be flawless. After much panning and scrolling I clicked only tab that hinted to be of some use – the ‘Help-Desk’. I was offered a simple generic form that carried ‘Unable to View Services’ as the last option of a long alphabetically ordered drop-down list of subject types. And, closest to describe what I had on my hands. Didn’t look very encouraging. There were some documents available on the site for download – perhaps they contained DIY tips on how to fix? But I was not inclined to read docs. It was then I chanced on a Help-Line number helpfully included somewhere there.

Now to the next stage of the saga.

Help_Desk gsagri04

After encountering several ‘All Lines Are Busy On This Route, Please Try Later’ on the MTNL network, finally I managed to reach the service provider. Their IVR (Interactive Voice Response) kicked in. Subject to intense questioning by the IVR and wearing out the keys on the phone, I was thrilled to be informed of the option ‘Unable to View Services’. I seized it with great alacrity of a treasure-hunter finding gold and was told my call would be transferred to an associate. Only seconds away from success I gloated like a climber within a step of cresting a peak. My keen ears waited for the promotional message to end and a human voice to be heard. Well, I continued to wait and wait. The message just repeated endlessly. One more attempt starting from the beginning. Same results. Didn’t feel like trying any more.

The associate obviously had not recovered yet from the strain of his duties during the Ganesh Festival. He had not bothered to leave an appropriate response to the caller.

Went back to the web-site to see if the Help-Line had any time/day qualifiers – there were none. Sundays were not excluded.

So I wait for Monday to dawn hoping the associate had a restful weekend.

This is one service provider who never minded their customers saying ‘tata’ to them! If you get what I mean!

End
.
.
.
Credits: openclipart (Help_Desk gsagri04)

Read Full Post »

Mosquito rewarriner
Customer Service and rightly so has been and continues to be the mantra for organizations. ‘Customer’ for most implies an individual (or an entity) buying products or services and paying for them. What about those ‘pests’ who demand a lot of attention, but never ‘pay’ for what they get? I mean the poor internal customers.

At many places, it is not strongly perceived serving internal customers is a prerequisite for efficiency in their jobs and hence profitable for the organization.

Let me cut the chase and get to an incident shining light on an important aspect of serving internal customers.

This was a periodic review of operations of an organization’s Information Infrastructure Department (IID) providing computing equipment and services to its internal users of an organization. IID had ready data to show its performance with regard to service tickets was well in excess of the promise held out in the SLA’s for internal customers. As it usually happens the internal customers on the other hand did not appear to be a particularly delighted lot. There were no satisfaction surveys in place to get a user perspective on services rendered.

Help_Desk gsagri04
The review did not focus on this aspect as there were other pressing matters…until a project manager brought up his problem.

The project was executed ‘offshore’ for a downtown client. It required the team to log onto client’s system and application to do the job. And the problem was the remote access was not working consistently. The frequent dropping of the VPN connection was hampering team’s productivity and annoying the customer.

The team promptly logged the problem into the Service Tickets System. The IID too promptly attended to these tickets – they tested out, found the link okay and closed the tickets. Their conclusion being ‘no problem with our links, you please check with your customer.’ The naïve project manager took it up only to be pushed back by the customer claiming all was well at his end.

This has been happening for some time. The routine reviews were time-limited and summary based and did not uncover the problem since the tickets were all closed. Finally the project manager could take no more. In sheer exasperation, he brought it up for help.

In the review IID maintained its stand there was no problem at this end.

It took quite an effort to impress on IID the problem needs to be resolved end-to-end for the project manager to execute his project smoothly and there were no other stops on the way.

In such cases it is usually best for IID guy at this end to talk to his counterpart in the customer’s organization and jointly fix the problem. He cannot leave the matter to the poor project manager to resolve.

In this incident however, the problem was resolved finally without involving the customer – it was traced to excessive use of bandwidth during certain times of the day causing the drop outs.

Closing the ticket is not the same as solving the problem.

End

Credits: openclipart (gsagri04 and rewarriner).

Read Full Post »

I am on a constant prowl to collect stories on what companies do to enhance their customer’s experiences employing a variety of different strategies.

While on this subject, not entirely unrelated, I’m reminded of the question of ‘Employee Satisfaction’ in a software services company I was associated with. The attrition of professionals in the company was higher than the industry average. As customary the managers including the HR confidently diagnosed the problem as one of substantial wage disparity – salaries outside were easily 30% or more than what the company was paying. Unfortunately this coincided with downward business cycle leaving not much room for any significant revision. 

While the issue of compensation cannot be easily brushed aside with the younger lot in software industry, I’m dismayed to find it occupying all of the center-stage to the entire exclusion of what other things could be done for the employees.  Mumbai as a city and software services as a job leave very little time for anything else. A good number of professionals spend 2 to 3 hours daily just commuting to and fro in crowded trains/buses.  Many of them hail from other cities living in spacious accommodation before moving to closet-sized apartments in Mumbai. Given this background, reducing the hassle of living in Mumbai is a strategy worthy of serious consideration. But that doesn’t happen. A few token steps are kicked off without a cohesive strategy on this theme, more as an apology – such as providing assistance in paying utility bills, credit card bills, etc.

‘Managers’ don’t much buy into all those industry reports that cite a number of factors up there besides doling out hefty increases in compensation for employee retention/satisfaction. 

 Coming back to customer experiences, here is a simple story on the same theme of making life a wee bit easier.

This is from ‘Through the Eyes of the Customer.’  James Watson makes the point in his post so well I did not try paraphrasing it.  

“…

I love it when someone makes my life easy.

CVS Pharmacy did that this morning.  

I’ve been taking an daily allergy prescription for the past three years.  Once a year, my doctor has to re-approve the prescription so  that CVS can refill it.  And that once-a-year event happened to coincide with this month’s refill.

 Pharmacy

So, I expected that  I’d have to call my doctor, and request to have  the prescription renewed.  Or worse, schedule an appointment to get into my car, drive to the office, and endure a check-up. Either way, I’d be forced to break out of my normal routine of simply picking up the prescription at the CVS Drive-Thru and do some extra work…. 

… so I thought….on

But when I dialed the local CVS pharmacy, and punched the Prescription number into the keypad on my phone, that friendly recorded voice told me that my auto-refill had ended, and that my physician must approve the refill.  

“Damn,” I thought… Here goes”….

But the next automated message made my day:

“Press “1′ if you would like CVS to contact your physician on your behalf.”

Yes!!!  One less thing for me to do, because CVS would do it for me; they’ve designed their customer-facing process in a way to reduce work for the customer; they’ve made my life easier!!! I was delighted.

Now, it might only take me five minutes to call to my doctor’s office and make the arrangements myself.  And a five-minute task done once a year may not seem like much of a hassle. Over the course of that year, it’s really not – except when it is.  Like this morning.

The point is not the CVS saved me five minutes; the point is that CVS eliminated a Task from my To-Do-List.

Most people don’t keep track of time as clearly as they keep track of tasks that need to be completed.  Saving a customer “a few minutes” may not be clearly visible to that person, but if you save the customer from having to perform a task, they’ll notice it every time, and they’ll precieve it as a BIG convenience.  And it’s the customer’s perception that drives their behavior and loyalty.

…”

I recall a similar experience I had with a mobile service provider a couple of years ago. I went in to purchase a replacement SIM for my cell-phone. When I took the form with me duly filled in, at the store they pointed out I had overlooked pasting a mug-shot on the form. It meant going back home to fetch a photo. While I was ‘Oh sh##t’ing, they made me stand against a wall, got a camera out and took a shot right there in the store!   

Whether the business is of providing services or supplying products there are opportunities galore to mitigate the hassle factor for the customer in his interaction, surely  a worthwhile goal for businesses to go after.   

End

                              .

                                   .

Credits:  jlwatsonconsulting.typepad.com/my-blog/

Read Full Post »

The Road to Failed Endeavors is paved all the way with Execution Screw-up’s.

Here’s someone from the most unlikely quarters that got it right.

This is a 120+ years-old 5000+ strong organization, serving 200,000 customers dispersed over a sprawling metro.

Well, what is special about them?

– For starters, six-sigma like performance with 400,000+ transactions in a day, almost on time, every time. These are end-user transactions and do not include internal en-route transhipment transactions normally prone to errors. Contrast it with the hi-tech baggage handling by the airlines industry.

– No disruptions in a city where every political party routinely organizes strikes for whatever reason.

– Education of the employees: Barely literate, some up to 8th Grade in school.

– Technology: bicycles and wooden-crates. No documentation at all. Recently introduced are booking through SMS and a web-site to inform and collect feedback.

The wonder organization is the Dabbawalas of Mumbai – a subject of study by many management schools.

A dabbawala literally meaning (“box person”), is a person in India, most commonly found in the city of Mumbai, who is employed in a unique service industry whose primary business is collecting freshly cooked food in lunch boxes from the residences of the office workers (mostly in the suburbs), delivering it to their respective workplaces and returning the empty boxes back to the customer’s residence by using various modes of transport.

So honest and reliable that customers are known to send home their pay-packet through the dabbas.

What works for them?

‘Their efficiency is not entirely a management marvel; it is rooted in their cultural values,’ says Ramesh Kamble, a professor of sociology at Mumbai University. The 5,000 dabbawalas come from a particular community of Maharashtrians, hailing from 30+ villages around Pune, deeply influenced by the Bhakti [devotion] movement. Denying exclusivity in hiring, Pawan Agarwal, a senior officer of the organization says:’The only recruitment criterion is a ‘guarantee’ – essentially, a verbal assurance of the candidate’s character – by an existing member. Most people tend to refer their friends or family members who belong to the same community…Our values, inclinations and psychology are similar. So there is better understanding and teamwork.’

Bino Paul GD, an associate professor at the TISS School of Management and Labor Studies observes: Their tremendous sense of social coherence with the city – they live with their families, eat home-cooked meals and lead respectable lives – further contributes to the culture and the cohesiveness of the dabbawalas.

There are other management gurus who think it is not as simple as that. How could it be so? They see a whole range of management, organization and process related factors contributing to the impeccable performance. They have not yet discarded the phenomenon as unscalable and freakish.

Whatever, an organization that works unerringly amidst the prevailing chaos. Could it be emulated elsewhere? The Wharton study tries to explain why this story is not easy to practise with the taxi drivers, for example, of Mumbai city. Reasons cited are hard and long duty hours, unrewarding business, the fuedal culture and a life of deprivation for the migrants from the north who constitute a large part of the population, etc.

Interestingly, it also means the stellar performance is now institutionalized outlasting several different leadership periods. In fact leadership is not mentioned anywhere in various write-up’s on this success story. Are there more examples of such kind?

End

Sources: Grateful thanks to knowledge.wharton.upenn.edu and Wiki.

Read Full Post »

 

Recently I learnt about an alarming situation regarding a system rolled out in a utility service for rendering emergency help to public users. It is quite imaginable that similar conditions may be prevailing in number of other towns in various utility operations.

 

It appears that these systems are not developed centrally under controlled processes as one would have thought, but more as local initiatives. And these are developed with the help of freelancers or part-time professionals and not with employees on rolls. This is understandable for reasons of skills shortage and also costs involved. And dealing with an individual developer is a lot easier than dealing with a service provider company especially for carrying out changes. In this mode of development, the changes, more often than not, are occasioned by requirements originally missed out due to lax ways of specifying rather than requirements evolving over usage. So it is not unusual to see a spate of changes lined up soon after the roll-out.

 

The code rolled out in the production server does not match with the code on the development server. Perhaps some code pieces are lying somewhere on the development server not easily traceable, or they are lost, or some changes were made directly on the production server. The seriousness of the situation has not sunk in yet. The ability to maintain and enhance the software is seriously compromised. For those of us who have been in this business long enough, this is not unusual. But what is scary is these are public-facing applications rolled out in the field, whose malfunction could cause personal injury or, worse, loss of life.

 

Further, there is no concept of version control or a sand-box for thorough testing before roll-out. It is not known if the system is piloted first before the full roll-out to iron out wrinkles.

 

As if this is not enough, I understood the freelancer has gone away for reasons not known. May be it was a cost cutting measure or the freelancer hiked his fees or he had to put distance between himself and the mess that was created (may not be entirely his doing). Needless to say there has been no formal hand-over process. When even the live-code inventory is incomplete, code or system documentation is too much to ask.

 

Into this scenario, the freelancer’s replacement walks in. Can you imagine his/her plight? And, there is a pile of pending enhancement requests waiting for him/her to take up right away. What it takes to maintain software is not always appreciated. What is at stake is not the individual’s performance, but safety of public users for whom the system is in operation.

 

Since public safety is involved, it is important that some minimal norms are enforced for developing and subsequently maintaining these systems and, the compliance to these norms are audited from time to time. May be these norms and audits are already an established practice in some  geographies.

 

This is not a call against freelancers who deliver great value, flexibility and responsiveness (and skills too) required by users whose requirement for software development is light and sporadic. It is a call for controlled processes for developing software especially for moderate-to-high impact applications.

 

Processes must be recognized as a mandatory piece of any scenario wherein software is developed or used for a serious application. The processes are not meant only for the developers; importantly, they also discipline the users (not the end-using public) who commission the developers and whose laxity is also often the root cause of the ensuing mess. It follows that both the developers and the users must be educated on the processes to be followed.

 

Of course, the processes must be right-sized to suit the customer and the application. Else, they could enormously slow down the software development efforts. Admittedly, right-sizing processes may not be a trivial exercise. Further, it is not required to induct a full set of processes which could be quite intimidating for a light-load user. It is sufficient to implement some key processes at a level of simplicity that serves the purpose. 

 

This could be done with some minimal professional help. May be there are sources from which it is possible to buy right-sized processes; and, get the freelancers to follow them.

 

On part of the software service providers, there is money on the table for those who come up with innovative models to develop and service systems for these light-load customers at affordable TCO without compromising on the norms. 

 

Of course, an off-the-shelf package solution significantly mitigates the risks and must be strongly considered as a solution over custom development.

Read Full Post »

 

A question I pop up often at software professionals is how do you evaluate a OO design. We assume presently functional completeness of the design is not in question.   The responses are interesting and various. They usually circle around: How well encapsulation, polymorphisms…are implemented in the design. How well reusability is used…. And some get into OO metrics.

 

I rarely get countered that the question is a wide open one; there are several aspects (some 20 plus non-functional attributes) to a design and which one do I have in mind for evaluating a design. After all design is a model for realizing both functional and non-functional user requirements.

 

If I were asked to be more specific on what is my chief concern in regard to design, I would then say it is the basic ability of the software to take in changes to its functionality over time. Changes to the functionality implemented in software are inevitable owing to the way an organization responds to internal and environmental shifts. With some software, these changes are easier to make and in some, it is gut-wrenching.   And, today, a good part of any IT (non-Capex) budget is spent on getting its software to change in step with the business needs.

 

So the concern over the software design being able to take changes in its stride is legitimate and important enough to say: the design that permits changes to be made more readily with less effort is a better design. Is this all about the usual non-functional attribute of ‘maintainability’? May be, in parts. I would like to think about it more as a legitimate evolution of the software while ‘maintenance’ connotes status quo. And today, the pace of this evolution has quickened even in ‘stable’ businesses.

 

Now let us proceed to figure out what possibly could be the criterion for evaluating the design from this perspective. This could also be turned on its head to ask how does one design that readily accommodates changes.

 

OO is already touted as a paradigm which is well suited to handle changes. Why? Because of its concepts such as encapsulation, inheritance, interface mechanism (?), etc. are suited to cope up with changes. Obviously, whichever design uses these features heavily, as shown by appropriate metrics or otherwise, is the way to go? 

 

This misses a crucial point. The initial functional requirements demand a set of abstractions. The design is best done by recognizing these abstractions and aligning its abstractions with the same. This is the true purport of all those OO guides that tell us how to identify candidate classes by listing out nouns from the problem description… If this is done as it should be, the initial alignment is ensured. This still does not guarantee the design as capable of coping up with changes to come.

 

The same principle applies to changes. Changes also demand a set of abstractions in the areas of change if they need to be handled later with minimal effort. A design that also aligns its abstractions with those in the areas of change is the one that truly delivers the promise of OO paradigm.

 

So the key to good design seem to lie outside of design phase! It is in the phase of assessing requirements; and, importantly, how these requirements would change in the foreseeable future. While we do a good job of the former, the latter has no place in our practice as yet! Not aware if formal methodologies for gathering and modeling requirements call for attention to this aspect. Is there a section distinctly devoted in the requirements document to foreseeable evolutionary changes? Not in 9+ cases out of 10. Not a wonder our systems are not well equipped to adapt to flow of time?

 

The software development community could come up with: “How can we foresee changes to come? If we could, we would provide for it from go.” This is strictly not true in all cases. It is not too difficult to figure out with the users which parts of the business processes are apt to change, if only we bring our questions to the user’s table specially targeting the future. Some are obvious in the trade and these are well taken care of even now.

 

Examples:

 

Tax laws: These could change from time to time.

 

Sales-person’s incentives or commission: The scheme for incentivising sales-persons changes from time to time even mid-year depending on the business objectives. In a healthy quarter, getting new clients may be important and in a sluggish quarter, mining current accounts may be the priority. Clearly the scheme needs to be abstracted.  

 

However, plans to open a new office, to start a new distribution channel, to introduce new pricing policy or new service offerings, to acquire a company…may not be uncovered in a routine study of requirements, the focus being on the present. Only a targeted probing with users may bring out these and other possible change triggers.  A word of caution is: the average user we engage with may not be wise to some of these plans!

 

In summary, a formal and focused business volatility analysis could be carried out with users at different levels of the organizational hierarchy so that the abstractions required by the business now and in future (to the foreseeable extent) are identified and the design abstractions are appropriately set up. The design abstractions could range form simple parameterization to more refined OO and variability techniques. The mode of deploying the changes also influences the choice of design technique.  

 

In fact it is a good idea to include a discussion on how the design would be impacted by anticipated and unanticipated changes in the user requirements: would the design abstractions take them in their stride elegantly or would it cause major upheavals. One recalls how in Operations Research, the algorithms provide for sensitivity analysis to figure out the impact on the computed solution if certain conditions were to change. Incidentally an earlier ‘Change Management’ post talks about the sensitivity of effort estimates to changes in user requirements.  

 

Is this a non-issue with packaged solutions like ERP? No, it is still an issue, perhaps to a lesser degree. Configuring a ERP solution for the current business practice is not a trivial effort. And when there are changes to current practice, reflecting these changes could turn out to be a minor or a significant effort depending on the degrees of freedom in the initial lay-out. For instance, consider organizations that frequently reorganize their operations – divisions and departments merge and split, get centralized and decentralized…The ERP could be elegantly re-configured for all these changes or it could be a snake’s pit depending on how it was set up initially.     

 

As an aside, abstractions in the requirements gathering phase may also be necessitated for an entirely different reason – the involved users may not be clear or articulate about their needs at that point of time or the scenario is in some kind of flux. These may get fleshed out later. Design abstractions must be able to cope up with these too. 

 

All along the software architects and the designers were required to think of abstractions. Now are we wanting our Business Analysts also to get into the groove? Yes, that’s the drift. 

 

How do we build systems for businesses which are intrinsically very volatile? Will look at it in a post to follow.

Read Full Post »

Older Posts »