![[Under Construction]](_borders/woman3.jpg){kind=small}
|
|
|
|
FOR IMMEDIATE RELEASE Quality? What QualityAn
interesting article by Simon Seow, our CEO, on Quality relates to actual
incidents on his trip
to By
SIMON SEOW
Sometimes
you can’t put your finger on what’s wrong but this time our columnist can
and does WHEN I
went through immigration at the KLIA yesterday, I experienced the first hitch
I have had with my passport and the airport passport reader. I had
just got a new passport that now required me to place my thumb on the fingerprint
reader, in addition to placing the chip-based passport in the reader. Immediately,
I learned that I had been having it good for the last few years when I breezed
through immigration with a passport that only required me to place it into the
reader. All those
people I used to smirk at, trapped inside the electronic turnstile, fumbling and
fuming, were not tech ignorant users after all. Now it is my turn to stare at
the blood vessels in my thumb, waiting for the red light from the thumbprint
reader to recognise me. My
passport details had already flashed up on the LCD screen but why does a message
keep asking me to place my finger on the fingerprint reader. I’ve been holding
my finger there so long it’s getting cooked. I tried
the other thumb. No. First finger? No. Middle finger? No. After a few more
tries, with the people waiting in line giving me that “put your finger in the
right spot, you moron” look, I removed my passport from the passport reader
and waited for the gate behind me to open and let me out. OK, I
would fall back and find an old fashioned, real-person, rubber-stamping,
immigration counter. But the gate stayed shut. More dagger stares from my fellow
travelers. Ah ...
there is a real person sitting in a cubicle beside the electronic turnstile. A
knock on the glass partition, frantic waves and I am out in no time. Perhaps the
electronic turnstiles are really controlled manually by these people hiding
behind their partitions. Like cartoons of the man inside the ATM, pushing
banknotes out the slot. Why else would you need so many people sitting beside
self-service machines? (I must add here that this does not take away the good
impression I have of our immigration people, especially the fantastic speed at
which they issued my new passport). There
and back again Back to
the KLIA. More educational experiences followed in quick succession. I boarded
the plane just in time, with the cabin crew right behind me. Once everyone had
been seated, the captain duly announced that take-off would be delayed because
of the need to wait for a replacement for some faulty part in the onboard
entertainment system. Moans
follow. “Why did they let us board the plane to be stuck waiting in our
seats?” Half an
hour later, the captain cheerfully announced that the component had arrived and
we could go. Soon, the plane started to reverse itself, away from the
“boarding ramp.” I stared
at the lines scrolling down the screen as the entertainment system booted up.
Unintelligible mostly but I am bound to impress my neighbour if I look like I am
actually reading the stuff. Barely a
few meters and the plane moved forward — back in place beside the ramp. Action
replay. “This is the captain again, ladies and gentlemen. Terribly sorry but
we have a problem with the pneumatic system.” “Wasn’t
the plane checked beforehand?” I wondered. “What’s this ‘pneumatic
thingy?’ ” Now it
was my neighbor’s turn to look intelligent. “You see those flaps on the
wings? They are supposed to go up and down.” “Oh yeah... I see, those
pneumonic, .. err pneumatic things ?.” (Actually,
it’s a hydraulic system. But we get Simon’s point. — The
Ed) Both
these examples of seemingly small problems have to do with little failures in
information technology systems that, collectively, have a significant effect
on our quality of life. Despite
our professed concern for quality and the amount of money and time we spend on
quality improvement programmes, we do not have a quality attitude to our
everyday life. We moan
and groan but we do nothing to change the situation. We accept poor products
and poor service because everyone accepts that computerised systems are like
that, not realising that it is to do with human actions and decisions, first in
the products specification/testing, and then in procedures during its use. Perhaps
we are too busy trying to buy the latest “best practices,” that we forget
the meaning and purpose of quality. What
is quality Quality
is fundamentally about a product or service being “fit for purpose.” This
implies a need to be clear about what the thing is, (whether it is a physical
thing or a service) that we are committed to deliver. The very
first step then is to describe the product (thing), to ensure that all
interested parties share the same idea about what it is. You will be surprised
at how difficult this simple act of describing the product can turn out to be. Despite
this, you should spend the time and effort to do so because all the rest of your
efforts in product design, development and testing will be based on this
description. If it is not made explicit upfront, then there is a very real
danger of the rest of the development lifecycle being based on an assumed
product description. Implicit requirements have a habit of continually changing. After you
have described it in the narrative common to the products industry/area, the
next thing is to define various quality attributes the product must meet. What is
it about the product that can be measured or tested? Who are the people who are
best suited to do the measuring or testing? How will the testing be done? What
is the degree of tolerance or permitted deviation from specification that can
be accepted? The
customer’s acceptance criteria for the product should be defined upfront, once
the need for the product is established. It should not wait until the design or
testing stage. Otherwise we will risk unconsciously adapting the acceptance
criteria according to the design or the developed product rather than to the
purpose of the product. In the
passport reader example, once there was an established need for the fingerprint
reader, the “product description” of the fingerprint reader needs to be
written up. Besides the narrative of what it is and a possible sketch of its
format, the description will list the aspects that will need to be measured/tested,
like, it’s surface dimensions to cater for the minimum and maximum finger
size, for example. The
method of testing is also written up as part of the product description. Does it
involve only testing by people placing their thumbs on the reader, or does it
include the use of machines to test it, for example. Descriptions
of the types of people who will do the test must be realistic according to the
intended users. Will it be just the IT staff and the immigration officers, or
will it include people who do not recognise or expect a fingerprint reader? It
is useful to use real people in that category, rather than for regular staff
to just “pretend.” One
vs. 10,000 Once,
while speaking to a product developer in a conference, I was amused at how much
he went out of the way to describe his products security aspects. His product
could detect all manners of attempts to cheat and abuse the system, but he found
it hard to understand why I was more interested in genuine, law-abiding users
that just wanted to quickly get it over with. (Here I
must resist the urge to start a debate on whether it is better to let one illegitimate
user through, than to inconvenience 10,000 other users, some of who may then
be driven to travel-rage). Which
brings us to the degree of permitted “tolerance” of a measurement. Nothing
can, or should, be made perfect. There is a need to specify the deviation
permitted from the target. This has a bearing on the production and running cost
versus benefit of the product, among other issues. By how
much can the dimensions of the reader vary; by how much can I vary the angle of
contact of my finger to the reader? The list
here is by no means exhaustive, but the important message is that these quality
criteria must be defined in the beginning. They will then be used as part of the
quality planning process of the product’s development, and final acceptance
by the customer. It is
typical to decompose a system description into its perceived sub-systems early
on in a project. The hierarchy diagram showing the breakdown of the system into
its parts, is often referred to as the Product Breakdown Structure, (abbreviated
to PBS). As the
project progresses and more is understood of the requirements, some of the
earlier identified products will be further decomposed into its sub-parts. These
sub-parts, once identified, are also “products” that each need its own
Product Description. A Quality
Log, that shows the planned and actual tests carried out for every product in
the system under development, is essential, if we are to pay attention to
quality of the final system deliverable. This log will help us to keep track of
the planned tests and actual tests carried out for every single product of the
system. A part of
the system cannot be considered completed until the planned tests have been
completed satisfactorily and signed off by the relevant person responsible. The
quality log should be an essential deliverable of a system, and therefore be
part of the contract for a system development project. It is a mandatory part
of a Prince2 managed project. Part
deux I have
not forgotten about the other half of my story, that of the plane’s
entertainment system. This has to do with the quality of our operational
processes after we have implemented the developed products. Granted that we
have to manage the need to get the passengers onto the plane on time, against
the need to avoid giving the passengers a good experience, the point is that
there is a choice that has to be made. In such
situations, there will need to be a way to handle a potential conflict between
the policy of the airport and that of the airline. Without trying to play down
the complexities of real-life situations, it is useful, when examining questions
of quality, to ask who the customers are in a given situation. We tend
to assume that the customer is always right but the only recourse the customer
has is to go and spend their money elsewhere — the next time. But for the
moment they are stuck with you. And this fact, if you are a monopoly, may lull
you into being complacent about quality. Until your service or product quality
becomes so bad that your customers decide to vote with their feet and either
relocate to a place where they are not at your mercy, or the industry finds a
substitute for your kind of product. Which is not so unlikely these days, as
witnessed by the increasing number of people who choose to travel by executive
coach rather than go though the hassles of air travel, for nearer locations. Until the
next article, I need to go and check out the quality criteria in the Product
Description of my sleep. The
columnist has been in the IT industry for the past 30 years and is founder of
Info Spec Sdn Bhd, which provides consultancy and training in methodologies of
enterprise architecture and project management. E-mail comments and other
feedback to intech@thestar.com.my. If
you like what you read, please feedback to the author at simonseow@infospec.com.my
or intech@thestar.com.my. more
articles by the Simon….. Search
Documents
1 to 6 of 6 matching the query "simon
says" 1. [CORPORATE
IT 29-Jul-2008 ] Sometimes
you can’t put your finger on what’s wrong but this time our columnist can
and does.
2. [CORPORATE
IT 15-Jul-2008 ] You
can’t eliminate the risk factor from any equation but you can manage it. The
trick is learning how.
3. Does
your organisation have it? [CORPORATE
IT 17-Jun-2008 ] Knowledge
will be the new wealth generator, we are told. But little attempt is being
made to clarify what this “knowledge” is and how do we get it.
4. Good
governance: Who wields the big stick? [CORPORATE
IT 3-Jun-2008 ] GOVERNANCE
is a current hot topic in government and corporations. What has it got to do
with information technology? Judging by the number of initiatives aimed at the
IT function, quite a lot.
5. Make
a business case for your proposal [CORPORATE
IT 6-May-2008 ] Justifying
a project is part and parcel of everyone’s job. It is not restricted to sales
people.
6. [CORPORATE
IT 22-Apr-2008 ] ONLY
“antiques” like me will recall the verse of that old song that goes East is
East and West is West, and never the two shall meet. This, to me, seems an
appropriate description of the relationship between technical IT people and the
“users” for whom they develop systems for. For More Information Contact: |
|
To register, please download registration, fill-in and send to us via info@infospec.com.my or Fax: 03-7957 1807
Send mail to info@infospec.com.my with
questions or comments about this web site.
|
