Feeds:
Posts
Comments

Posts Tagged ‘Quality’

I was camping in a fairly large house, well maintained, surrounded by a number of flowering trees and plants, home to countless birds that treated us to a melodious cacophony announcing their morning foray and home coming in the evening. It was time for the trees to renew themselves – service staff came in the morning and again in the afternoon to sweep off the leaves copiously shed by the tress on the front-yard.  The flowering plants however were still abloom. At times on my touch, a bee would startle me flying out from deep inside the flower.

For one who has lived all his life in Mumbai flats (apartments) where one cannot take ten steps without hitting a wall, one’s auditory nerves constantly assaulted by caw’s of those sullen crows and bark of stray (and house) dogs, this was an overwhelming experience. The spacious front-yard was where I took my mandatory morning and evening walks, my senses enjoying the sights and sounds around.

Get the picture?

The only blot on the scene was the rubble piled up near the neem tree at one corner of the house in the front.  The house owner had not cleared it intending to reuse it in future possibly for patching up parts of the yard.

Yesterday morning, walking near the neem tree I saw a splash of red dried up on the debris. I had not seen it before. Clearly, someone, possibly one of those tradesmen called in for some repair work, had used it as a spittoon after chewing a paan (betel leaf + lime + arca nut shavings + whatever). Unfortunate, but true, in this country one may freely spit in public or even common spaces, but never so within a house. But the perpetrator saw it differently – if the corner was good (?) to pile up the rubble, no one minding, it was ok for him to spit over there.

The ‘Broken Window’ syndrome playing out!

Broken_windows,_Northampton_State_Hospital

From wiki: ‘Under the broken windows theory, an ordered and clean environment, one that is maintained, sends the signal that the area is monitored and that criminal behavior is not tolerated. Conversely, a disordered environment, one that is not maintained (broken windows, graffiti, excessive litter), sends the signal that the area is not monitored and that criminal behavior has little risk of detection.’

A few broken windows, at times even one, left unfixed for some time is a trigger or invitation for many more, if not all, to be broken.

Much is written on this syndrome as a subject of study under criminology and urban sociology.

Outside of crime, the phenomenon may be observed in many other contexts: projects, product development, organizations, communities and even in personal life.

When a project manager leaves unfixed the first infractions on time deadline, quality issues or team indiscipline…, the first window is broken. His team reads it differently. It’s very likely he would, to his grief, witness many more ‘broken windows’ before long on his way down and out.

End

 

Source: wikipedia

Read Full Post »

paul-heckel_MrxmZW4Jh.jpg

End

Read Full Post »

 

Outside a hospital:

600400_10207514006700929_5639004389195404671_n

This security guard’s duty is to instruct people to remove their shoes.

Why he was arranging shoes in the rack?

“Sir, this seat is my office and I want to sit in neat office.”

He also greets worried visitors with a reassuring ‘Everything will be fine, your patients will soon go home with you.’

In all likelihood he would not have had the benefit of any level of schooling.

End

 

Source: Adopted from facebook.com/groups/101024580247213/ posted by Gautham Iyengar (here)

Read Full Post »

Rfc1394_Wheelchair

Last week, we had been away to a resort off Lonavala for a short break of four days, taking along a reluctant 85+ year old lady – my mom – kicking and screaming. Every morning and evening, I took her out in a wheel-chair thankfully made available by the resort to give her a much needed outing. The wheel-chair ride was the first for both of us.

I am not aware if there are norms for the ramps meant for steering wheel-chairs up or down. In this instance, the wheel-chair often dashed down the ramp almost uncontrollably pulled by her weight and the steepness of the slope. At least on a couple of occasions she came close to being thrown out of her seat. Clearly the need was for seat belts to secure the occupant safely. Also brakes would have helped start/stop the wheel-chair when needed, just like the brakes on the baggage trolleys at the airport.

The wheel-chair had a pair of foot-rests that swung into place from the sides for use. These all-metal foot-rests had sharp edges that caused abrasions on the feet when the old lady struggled to get her feet into position.

A convenience feature I would have liked to see is a pair of height-adjustable handles to push the chair instead of me half-bending down.

It is quite possible the wheel-chair I used was old and primitive and the newer models provide these safety and engineering features.

Incidentally I’m not ashamed to confess: Only after messing it up a couple of times, I found out it was much easier to seat her in by positioning the wheel-chair to where she was standing rather than other way around. Did you say common-sense? Well…

End .
.
Credits: openclipart (Rfc1394_Wheelchair)

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 »

 

The business tsunami must have already hit the shores of IT service providers by now. In peace times it is always useful to understand how well is our customer doing in his market place, his points of success and vulnerabilities, and add high-impact value to our services. However, in war times such as this, the universal common-sense trend is to fold inwards on costs and productivity. Initiatives to help our customer along this direction would go a long way to forge a stronger relationship. It would not be a smart idea to do nothing maintaining status-quo or get our strategies mixed up.  

 

If we have been servicing our customer for sometime now, it shouldn’t be too difficult for us to see where these opportunities lie. It’s time to make those moves if it is not already too late.

 

Cutting down on waste is an effective strategy to reduce costs and boost efficiency. There is an excellent article by Bill Kastle in iSixSigma magazine (1) on how to cut waste in Financial Services. This post distills some experiences in IT services industry. Here we go:

 

Waste 1: Over-Communication

 

In a production model where the software development involves the long chain of end-users, user-specifier, analyst, designer, coder, tester, user-acceptor, there is communication at every step. A number of system models are in use to support this communication with clarity and efficiency, depending on what is communicated.

 

IT services are often rendered using a model of a mix of onsite and offshore resources.  In some cases, when there are no onsite resources deployed by the offshore service provider, the offshore team directly interacts with the customer’s project manager. In either case, effective communication between the two geography-separated teams is absolutely essential for the success of service delivery and holding regular telecons is a well established practice. A telecon is lot more efficient and time-crunching than exchanging multiple rounds of lengthy emails and much greater clarity is obtained on each other’s views.

 

On the negative, these telecons go on for long hours at inconvenient schedules (due to time differences) for the customer while soaking up a good amount of most productive morning time of the offshore team and is often not sharply focused. Also some more time is consumed in assembling before and returning to desk after the telecon.

 

Assuming there is a diktat that from tomorrow a telecon that lasted for one hour would be limited to 45 minutes by an automatic timer, how would I, as the host initiating the telecom, manage? Some simple steps, really:

 

– I would plan the structure of the telecon by listing the items of priority naming participants and collecting the background material. 

– Communicate the plan and the relevant material to all relevant participants.

– With this prior preparation, tightly orchestrate the call, keeping to the subject on hand and limiting the participation only to those who need to be at each step.

 

If a project of 5 team-members holds 3 hour-long telecons in a week with 3 participants per telecon, a reduction in its duration by 15 minutes yields 1%+ savings of productive hours, not to speak of the customer going to bed 15 minutes earlier and reduced telephone bills!

 

There are times one has to be innovative beyond achieving this basic efficiency in communication. On one occasion, a customer brought up his tale of woe: he had to have these daily telecons with the offshore team that kept him awake late into the nights and sapped his energies. He was building an application, with the help of an offshore team, for managing documents of legal cases and the associated workflow in a law firm. There was an enormous variety in those cases and also in the following workflow. And it took him a lot of time to describe these requirements to the analyst on this side who was trying hard to make sense out of the talk (nevertheless, a vast improvement over the earlier arrangement where he had to make the techies understand him). The customer candidly admitted that he usually missed out a few points in the welter of details discussed, which with great fidelity were missed out as well in the software delivered. And the QA marked them later as defects in the software.

 

Does the above tale of woe point to some ways of reducing the burden of communication and also incidentally reduce defects?

 

Yes, there is at least a couple that could improve matters.

 

Firstly, even in a telecon, clearly a more structured way of articulating the requirements could be deployed. For instance, if screens are used mainly to specify user activities, the requirements may be tightly sequenced as: a) for each field, description (syntax and semantics), default value, display control, filed-level validation b) screen-level (or inter-field) validation and computation and c) for each event (not covered under a) and b) its description, and processing. Templating the requirements thus cuts out free-style (and wasteful) communication and also safe-guards against omissions and lack of clarity very early in the SDLC. This holds regardless of development paradigm: waterfall, agile, etc.

 

This is in a way no different from the traditional method of systematically capturing the user needs in a comprehensive requirements document, instead of catching them on the run as is wont now.

 

As an aside, this is also a potential source for quality problems because the testing team, by not being part of these telecons, is never first-hand aware of the requirements or changes agreed with the customer during these telecons. This disconnect shows up as inadequate coverage in testing or, worse, wrong test cases. A mitigating practice is to at least capture crisply the highlights of the telecom in a follow-up shared communication.

 

Secondly, a familiarity if not knowledge of the application domain significantly helps in reducing the communication burden in regard to understanding requirements. While the luxury of a domain expert may not be available on most occasions, alternatively a short capsule of training program in the problem domain for the analyst greatly facilitates faster comprehension of the requirements. This compromise approach is vastly under-rated or untried. In practice, it has always significantly speeded up capturing of the requirements more completely and clearly.

 

Another aid to easier understanding of requirements: In many projects, short or long, developing a glossary of entities, rules, validation, exceptions, etc. capturing the semantics of the application supported by cross-references is a very useful aid for the same purpose of easy comprehension and also for conserving application knowledge gained over time, obviating the need for verbose documentation. Going beyond the requirements gathering phase, a good glossary is an effective communication tool in all phases of a project. And the nice thing about it is that it could evolve incrementally starting from scratch as more facts are uncovered. This, in practice, has not received the attention it should.  

 

Sometimes the telecon consciously moves away from tasking or problem solving or reviewing mode into a rambling mode merely to establish or strengthen the rapport between the teams on both sides. Or, junior members are called in to watch and learn how to interact with customers. These are planned departures from the course of efficiencies espoused herein.

 

We have looked at only one kind of communication – telecon, and how to bring efficiency and quality therein. The structure of the telecon would depend on its purpose and would evolve over a few sessions. Where the telecon is to explain user requirements, we also saw some approaches to prepare ourselves better in reducing the burden of communication and achieve enhanced quality too. The processes of communication in IT services are pervasive and substantial in a project with enough opportunities to cut out waste at every step and to boost quality.

 

Can we shorten the long service chain of end-users to user-specifier to many in the IT service provider organization and back to user-acceptor? Also can we pare the written-down documentation to a minimum?  These steps should in principle reduce the over-all load of communication. That’s a subject for another day, with implications much beyond communication load.

 

Enriching views and experiences from you, in concurrence or contrary, are most welcome.  

 

To continue on other themes for reducing waste…

 

Ref: (1) http://finance.isixsigma.com/library/content/c040324a.asp

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 »

Older Posts »