Feeds:
Posts
Comments

Posts Tagged ‘Quality’

An interesting story from James Lawther:

…During the second world war over 60 million people were killed.  That was roughly 3% of the world-wide population.  It was a hazardous time.

Among the hardest hit were the bomber crews.  The Eighth Air Force suffered half of all the U.S. Air Force’s casualties.  The British fared as badly.  The chances of surviving the war as a member of the RAF’s bomber command were only marginally better than even.

If flying bombing raids wasn’t dangerous enough, landing when you returned home was also fraught with danger.  Pilots of the Boeing B-17 Flying Fortress had a series of runway crashes, accidentally retracting the landing gear when they touched down.

…Accident investigators blamed these incidents on pilot (or human) error.  There was no obvious mechanical failure.

It wasn’t only Flying Fortresses that had the problem.  There were stories of pilots of P-17 Thunderbolts and B-25 Mitchells making the same mistake.

Nobody would deliberately retract the landing gear when they were still hurtling across the tarmac.  Why the pilots did so was anybody’s guess.  Perhaps the pilot’s attention wandered when they realized they were almost home.

…The authorities asked Alphonse Chapanis,  a military psychologist to explain the behavior.  He noticed that the accidents only happened to certain planes and not others.  There were thousands of C-47 transport planes buzzing about.  Their pilots never suffered from such fatal inattention.

After inspecting the cockpits of the different planes the cause became clear.  On B-17s the controls for the flaps and undercarriage were next to one another.  They also had the same style of handle.   Pilots who retracted the undercarriage when the wheels were on the ground were actually trying to retract the flaps. They just pulled the wrong lever.

In the C-47 the two controls were very different and positioned apart from each other.

The solution: Once he identified the cause Chapanis developed an equally simple solution.  Circular rubber disks were stuck to the levers for the undercarriage and triangles were stuck to the levers for the flaps.  When a pilot touched the rubber, he felt the difference and the crashes stopped…The pilots were well aware of which lever to pull.  It was “human error” that caused the mistake.  But laying the blame on the pilots wasn’t ever going to solve that.

14268987360_480684fa56_o-400x320

We all make mistakes.  It is in our nature.  Don’t fight it, fix it.

 

End

 

The original post – unfortunately no way to reblog – may be read here.

Advertisements

Read Full Post »

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 »

Older Posts »