Thursday, 13 December 2012

Braille and 'braille-ing' pharmaceutical packages


History


Braille is a 'tactile' writing system used by the blind and visually impaired.
'Tactile' means - 'Of or relating to or proceeding from the sense of touch' - so the braille is read by the visually challenged people by touching the relief portions on a medium. This can be found in books, menu cards, signs, elevator buttons and currency.

The event that would truly transform lives of many in the future 


Braille is named after its creator, Frenchman Louis Braille, who went blind following a childhood accident in his father's workshop. Being very intelligent and diligent by nature and along with the support of his parents and teachers - he was determined to fashion a system of reading and writing that could bridge the critical gap in communication between the sighted and blind.

In 1821, Braille learned of a communication system devised by captain Charles Barbier of the French Army. Barbier had invented the system called NIGHT WRITING which was a code of dots and dashes impressed into thick paper. These impressions could be interpreted entirely by the fingers, letting soldiers share information on the battlefield without having light or needing to speak.This inspired Braille to develop a system of his own and the first edition of this was published in 1829.

His words

"We do not need pity, nor do we need to be reminded we are vulnerable. We must be treated as equals – and communication is the way this can be brought about."

BRAILLE ALPHABETS

A single braille cell

  • The basic grid of a Braille alphabet character consists of six dots, in two parallel vertical lines of three dots each. From the six dots that make up the basic grid, 64 different signs can be created. 
  • Reading direction of Braille is the same as for regular type and the rules for hyphenation that apply for regular fonts also apply in Braille. 
  • An un-contracted Braille is one in which each individual letter of the alphabet, punctuation mark etc. is represented by its own Braille character(s).








Note 1: In order to indicate a number, the braille numbers are preceded by the braille Number Sign - this is to differentiate them from the braille alphabets A to J which share the same scripting.
For instance, if  50 mg is to be indicated, it would be as follows:








Note 2: In order to continue without space, alphabets after the numbers - the letter sign has to be included after the numbers.
For instance, if 150g is to be indicated, it would be as follows:







Sample Text:


I am Balaji and 27 years old; Daughter's name is Madhu.

Braille Conversion

(Courtesy - Translator tool of Mathisfun.com)























BRAILLE REQUIREMENTS FOR PHARMACEUTICAL LABELING AND PACKAGING

There are currently 2 global standards that lay out the regulations for including braille text on pharmaceutical packaging.
  1. In EU, European Committee for Standardization (CEN) created a new standard EN 15823 'Packaging - Braille on packaging for medicinal products'. From October 2005, the 25 member states of the European Union are required to have legislation in place in conformance with the EU Directive 2001/83/EC: this requires that all products authorized after October 30 2005 carry Braille identification.
  2. In North America and Canada, International Association of Diecutting and Diemaking (IADD) has created “Can-Am Braille” - a set of guidelines and recommendations for the use of Braille on pharmaceutical packaging. This is still a voluntary standard with no legislation. The standard is very similar to the European Braille standard.

Braille Compliant Font Specification:


The ECMA standard (European Carton Makers Association) ECMA Euro Braille is based upon 'The Marburg Medium format'.

ECMA Euro braille Specification

  • The diameter at the base of the dot is 1.6 mm, this is also the diameter on the female matrix and the diameter of dots shown in the artwork file.
  • The dot spacing is exactly 2.5 mm (from dot center to dot center).
  • The character spacing amounts to 6.0 mm (from center to center).
  • The line spacing is 10.0 mm with a tolerance of +0.0 mm/-0.1 mm.
  • With regard to the height of the embossing on the surface of a folding carton, it is recommended that this is determined visually, since the deformed carton board is likely to recover slightly over time. The upper tolerance level is reached when the surface of the folding carton starts to burst.
  • An un-contracted Braille grade should be used - here every individual letter of the alphabet, punctuation mark etc. is represented by its own Braille character(s).
  • There is no capitalisation in Braille text on folding cartons.


Positioning of Braille 

  • The distance between the chosen Braille embossing location and the center of the cutting and creasing lines must be 8 mm - measured from the edge of the dot. 
  • Braille texts cannot be applied to locations on the carton where there are bar codes or perforations.

Amount of Braille Text

The number of available characters and lines for Braille text embossing are determined by the dimensions of the folding carton.
Based on Height (H) - the total number of braille characters are decided.
Based on A(Length) / B (Breadth) - to whichever panel it is attached to - the total number of braille lines are decided. 
Number of braille lines on the main panel
  • If Dimension A/ B value is greater than 22.6 mm - Number of Braille Lines on the panel should be 1.
  • If Dimension A/ B value is greater than 32.6 mm - Number of Braille Lines on the panel should be 2.
  • If Dimension A/ B value is greater than 42.6 mm - Number of Braille Lines on the panel should be 3.
  • If Dimension A/ B value is greater than 52.6 mm - Number of Braille Lines on the panel should be 4.
Number of braille characters per braille line
  • If Dimension H value is greater than 50.1 mm - Number of Braille characters per line should be 6.
  • If Dimension H value is greater than 56.1 mm - Number of Braille characters per line should be 7.
  • If Dimension H value is greater than 62.1 mm - Number of Braille characters per line should be 8.
  • If Dimension H value is greater than 68.1 mm - Number of Braille characters per line should be 9.
  • If Dimension H value is greater than 74.1 mm - Number of Braille characters per line should be 10.
  • If Dimension H value is greater than 80.1 mm - Number of Braille characters per line should be 11.
  • If Dimension H value is greater than 86.1 mm - Number of Braille characters per line should be 12.
  • If Dimension H value is greater than 92.1 mm - Number of Braille characters per line should be 13.
  • If Dimension H value is greater than 98.1 mm - Number of Braille characters per line should be 14.
  • If Dimension H value is greater than 104.1 mm - Number of Braille characters per line should be 15.
  • If Dimension H value is greater than 110.1 mm - Number of Braille characters per line should be 16.
  • If Dimension H value is greater than 116.1 mm - Number of Braille characters per line should be 17.
  • If Dimension H value is greater than 122.1 mm - Number of Braille characters per line should be 18.
  • If Dimension H value is greater than 128.1 mm - Number of Braille characters per line should be 19.
  • If Dimension H value is greater than 134.1 mm - Number of Braille characters per line should be 20.

Braille Dot Height


For embossed materials, the target Braille cell dot height shall be 0.20 mm.

Conclusion


Braille has deeply influenced the lives of visually challenged people - letting them being treated with dignity in a society and empowering them. With the advent of having braille on medical packages, it becomes a life saver that can help the blind even at emergency situations. 

India is home to about one fifth of the world’s blind people, according to the World Health Organization. As European and American communities have embraced the concept of braille-enabling the pharmaceutical packages - I wish our Indian pharmacos and package design / converting community join hands together and implement the process. 


Thursday, 6 December 2012

Guidelines on the labelling of pharmaceutical products

This is a post that's related to my field of packaging. I have now been interacting with a company called KAROMI, who develop enterprise solutions for a variety of domain. They have now ventured into packaging domain in which they help the clients - the pharmaceutical companies - to manage their artwork and establish seamless communication channels with the graphic artwork development process for the medical products - (Here is the link to their website)

As I began to interact with these guys, I became curious in studying about what this drug - compliant artwork labelling meant. So, I have researched some common day to day pharma products and have tried presenting these data in a 'lay-man-digestible' image.

I also wish to convey here that the material below is not collected from Karomi and hence is not their endorsed opinion. It is just my 'blind' capturing of details for research storage.  


I have used a free application called XMind, to generate a mindmap (a visual representation in a map format), exported it as an image and then used the services of a free image hosting website service - FreeImageHosting.net to put up this image.

Click Here to open a detailed description about the general guidelines 


Click Here to open a detailed description about the individual drug based labeling guidelines

If there is any other pharma labeling guidelines I have missed out. feel free to add them in the comments section. It would be helpful to the community.

Thursday, 4 October 2012

Coup d'oeil of Folding Carton


Folding Carton: Identity

Boxes made of thick paperboard that are creased and folded to form containers that are generally shipped and stored flat and erected at the point where they are filled with the product. Folding cartons  are used for sales, storage and shipping various products and are generally small enough to hold in one hand.

Produced flat
Shipped after pasting & creasing 



         
Erected while filling the product

Finally in retail shelf 

PAPERBOARD PACKAGING FAMILY (An infographic)




Folding Carton Family Hierarchy


There are thousands and thousands of folding carton styles floating around in the market. As the number of designs grew globally - identification and communication of a design became increasingly a problem between the product maker (who needs a package for the product) and the package producer (a.k.a converter).
There was a global need to classify various package designs into multiple groups and identify each one of them with a unique ID. This unique ID was aimed at removing any culture specific jargon for a design and to facilitate clear communication at all levels of design and manufacture.

One of the most famous organizations that created a global standard for folding cartons was ECMA (European Carton Makers Association). In October 1960, ten national carton associations in Europe founded ECMA. It was principally created to build a formal structured network - to engage in cross border communication, to promote exchange of market data and to promote technical development of equipment used in carton industry.
In 1967 - ECMA published a CODE - the ECMA Code of Folding Carton Design Styles - as a design book. In 2009, the first electronic version of the standards was introduced as a stand-alone application.


In the new digital ECMA code, users can:

  • Browse and search through the catalog of designs
  • View the folding sequence of the most common designs in an interactive 3D environment
  • Export the design drawings in a CAD - CAM friendly vector format

Here is where you can get a demo version of this application (valid for 10 days). This is sold at a price of € 476.00 (approximately 33,000 INR) and can be bought here.

Without any further ado, here is a look at how they have classified the Folding Carton family:



Birth and growth - significance:


Like so many other inventions, the birth of folding carton was also as a result of an accident. 
It happened in the year 1879, in Brooklyn - where Robert Gair had a paper bag factory. The paper bags were being printed in letter press. 

BIRTH

One such day, while producing seed bags - a careless press man failed to notice that a type rule had been set too high and it had cut through and ruined 20000 seed bags. 
Then the 'EUREKA' moment came. Mr. Gair was intrigued by the clean incisions across the seed bags. It occurred to him in a flash - that there was a way of constructing a multiple die that would cut and crease box board in a single operation. 
The ruined seed bags - inspired Gair to create a die - in which he can set sharp cutting blades a little higher than blunt creasing rules of the press - thus cutting and creasing in a single operation. 

GROWTH

The folding cartons earned prestige in 1896, when the National Biscuit Company began to sell Uneeda biscuits in cartons. The biscuits were wrapped inside a wax paper liner inside a tray-styled carton. The colorful printed wrapper featured a boy in a raincoat - to emphasize moisture barrier. 
This was a very significant event - because - for the first time - users could buy biscuits in a clean unit size package, rather than having the retailer measure out a quantity from a large biscuit barrel where the biscuits where exposed to moisture, odors, insects and breakage.   
The UNEEDA biscuit carton also represented the birth of brand advertising that relies on the package as a sales tool. Furthermore, it symbolized the shift of power from retailers to manufacturers. By packaging at the factory rather than at the store, and by making their products easy to recognize - manufacturers were able to take control. 


Why should I opt for this type of packaging?



Top 12 difficult interviews - Indian IT companies

Friday, 14 September 2012

Research is Life


Currently, I am heading the research in a packaging application, where I am expected to provide the functional requirements of the software and validate them with the industry for the appropriateness and automation. I am also associated with another Graphic Arts product for planning and imposition, where I collaborate and sometimes (by virtue of being 'the oldie') mentor the development along with a very young and enthusiastic team of 2 members. Our domain team is a small one, but one that is very highly motivated. The motto being to reach out to the needs of our product users, addressing their needs effectively.

Research - a story of Transcendence:

ape by steeleman204, on Flickr
Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 Generic License  by  steeleman204 


Over the years that I have been associated with this activity 'RESEARCH', I started developing a consummate love for it. Now it has become my way of life. My identification, character and my personality. This love story is a story of transcendence. 

Shifting from Production environment to Research environment:

I came into this R & D field from a production environment. To give a glimpse of my previous birth (yeah it seems a birth ago now - though it's been 5 years now),Productivity was the essence of a production environment. Time was the most sacred resource involved. Blasphemy is not to have achieved the daily numbers target. Quality was always the 'next' big thing. 'BOSS' was your yardstick. Your performance was measured solely in the 'opinion' of your yardstick. Regardless to say, your moods and satisfaction reflected your yardstick's. My pascal meter was touching an all-time high. Then the lid was taken off. A call from Chennai - seemed more like a life belt. 
I joined this company India Metamation. Everything seemed to be surreal. Nice-straight talking-honest people around with a transparent, employee friendly environment. All of this came under a tag - 'R&D'. Little did I know then, it would become my avatar. 

Research - as an activity:

The 'R' in this 'R & D', started off with being an activity - a task in my To-do list that was very specific to the issue I had to research on. More specifically, since my work deals with software development - a research was confined to a feature needed in the application. Putting it in a cruder fashion, research was about a button in the user interface - where to have it, what should it do - Period. 
Commonly this activity was carried out with the help of a call and a peep. A phone call to the operator asking where he wants this and what all he wants to do with it. A peep into the competitors manual for improvising. 
This was followed by a cute little research document. One describing the research - containing the conversation of the call and the screen shots of the competing product: 'fidelity' being the stand out attribute of the document. Care was taken not to give my personal opinion or judgment within this. It was truly an open document. The reader - the developer could build up on this further and interpret this the way he wanted to. But the research was done. My production mentality prevailed: a research done, a document submitted, a number shown.

The beginning of life: 'Am I missing something?'

Then the results of these - made me think about what was missing. The product was merely what was enough - what the customer expected. It matched the competing product. There was never any exclamation or a eye brow rise from anyone seeing the product. At this same time, I was also looking at some of the software products in other domains. Google was one of those that I watched closely - because it was one that I was using most. Every time, I saw a new release or a product update from them - I was astonished. Why? Because every time I got the new feature and used them, I felt like 'how could I live without this feature from now on'. They had sensed my mind - they had not asked what I had wanted, but they sensed it. This thought made me take up my research a level further. 

Research - as a duty:

My next level was looking at Research as a duty. It was my official duty to think about what the user wants. My research began not by calling him or by peeping into a competitor's user manual - but by becoming a user, thinking how he thinks and seeing what he sees and finally sense what he wants. I still call up him and look at some competitor manuals - but that's certainly not the starting point but an additional rounding off activity to improvise.


I could see a marked change into my documents from then on. Even if I was not able to complete my research in a specific time, I was convinced to think that this research would yield a feature that is going to make life of a user easier and better. The features that resulted out of these research documents - truly reached out to the users. For a start - they acknowledged these. It was a lesson learnt. Also the time spent on this seemed worth every second of it, so my production mentality melted away.

Twist of life: Non-research tasks becoming mundane and a burden:

Amidst all of these, I was also doing other domain related activities such as testing, documentation and customer support. Because I had associated an intent in my research activities - that of sensing a need - it was a task that I began longing for. If there was a research topic in my daily kitty - it made up my day. The flip side to it was these other tasks started appearing mundane and looking unglamorous. They lacked the appeal and the high that a research task gave. As a result, the quality of my work in these areas waned. I was found lacking in these areas. Again this made me think. One day the realization struck - There was a research involved in these tasks as well. 

Research - as a way of life:

I began to understand that any process, had methods and tools involved. That these methods and tools - when sensed, researched and refined - yielded maximum mileage. 



For example this is what happened earlier when I wrote the user documents. I was merely worried with conveying the knowledge about the software to the user. I was constantly sweating over the usage of voices here. However later a minor change in perspective made me at ease with the documentation: Instead of communicating 'What I know about the software?' I had to communicate 'What does the user want to know about the software?'. I started seeing this document creation from the eyes of a new user. I started using tools available such as Google Docs for collaborative working - that made the approval process simpler. I started documenting FAQ's about screenshot capturing and voices in a commonly available location so that people could review and voice their opinions on it. This became a guideline knowledge source for the future. I was at peace with this method from that moment on.

There was a similar thing with testing. With testing I started creating testing procedures and also started classifying the categories of testing - that way I could quickly go through these and perform an effective testing. I also learnt that the key to testing is preparation, imagination and persevering execution. 

To round it off, looking at each activity involved as research stems from a need of systematic analytical approach to an issue. The moment we decide to tag each activity as a Research activity - we start thinking about the methods and tools that can be used for & subsequently how we can improvise these methods and tools for better efficiency of the process. Also as a side effect, it made the process more enjoyable and lucrative. 

And I was able to extend this realization to the other spheres of my life - personal included. That is any process or activity in life - has in it a potential research. It is up to one to sense this, address this and refine this - making the activity, one to look forward to and enjoy. 
This has been my philosophy - research is life.
________________________________________________________________________

ALL THAT I LEARNT ABOUT RESEARCH

  • Research Activity - Systematic Investigation with an open mind to generate new ideas or ways of doing things.
    • Major steps involved:
      • Identification of a research issue
      • Literature review
      • Specifying the purpose of research
      • Data Collection
      • Analyzing and interpreting the data
      • Reporting and evaluating research
  • Researcher - A scientist who devotes himself to doing research
    • Traits of a researcher:
      • Patient
      • Honest
      • Curious
      • Observant
      • Organized
      • Perseverant
      • Enthusiastic
    • You are good researcher:
      • If you have a desire to contribute something original to the world
      • If you are never satisfied by one or two sources & dig a little deeper to find the answers
      • If you are able to extract relevant information from large amounts of information
      • If you take in the (inevitable) rejection or disappointment {in terms of having your research data accepted and acknowledged} as fuel to make your research more complete
    • Skills to develop:
      • Analytical skills: Ability to apply logical thinking to gathering and analyzing information, designing and testing solutions to problems, and formulating plans.
      • Communication skills: Asking pointed, well directed questions
      • Documentation skills: Documenting clearly with known, doubtful and unknown areas
      • Presentation skills: Presenting an unambiguous, clear picture of the research

Inside the mind of a tester and how to don the role better

Software Bugs by FastJack, on Flickr
Software Quality Assurance a.k.a. Bug Spotting
Creative Commons Attribution 2.0 Generic License  by  FastJack 

This is often a hat that has to be worn by me, mostly after periods of activity slumber. In the midst of an interesting research about the future development of the projects or at the helm of one of those tech fruitions - 'TA DA!!!' - a mail from my partner arrives. 

"New version, here's a list of what it covers and what it does not do! Test!". Like a child being called back home by its mother in the evening, to do the never-ending homework - I start trudging, pushing myself to this world. 

The world of software testing
Software testing is the process of testing the correctness of executable code which does operation on data. Tester will provide various data to the executable code to see if it works as expected or if that handles all possible errors on various environments. 
OK OK - That's about being a good boy - and being politically correct as to what software testing is. But here's what I personally think about software testing: 
Any code is guilty, until proven innocent. I don the role of a paranoid - always suspicious, uncompromising and cunning, trying to frame the developer. 


Missing Hugh II by Little Miss no Name, on Flickr
A PARANOID
Creative Commons Attribution 2.0 Generic License  by  Little Miss no Name 

The only difference here is, it is a case of constructive paranoia. What makes it super special is my developer (well, most of the times) loves me for this. 
Deep-in I realize, that validation and then subsequently testing is the second most important activity involved in a project after the conceptualization. However there is always a melancholy associated at the beginning. I began to ponder over the reasons.

Why testing is the least glamorous actress around?
  • NO RECOGNITION: Foremost, there might not be any rewards from the end user in terms of approval or recognition for our testing. Give your customer a totally bug-free product. Prod him and state him the amazing fact that it does not have any bugs. Invariably his reaction to this would be: "Whats so great about this? Aren't these software applications supposed to be bug-free?". Bug-free attribute will never become a selling point for the application. And here's another killer - 'Bug-free'ness can never be demoed.
  • RESPONSIBLE FOR EVERY FAULT: Tester is responsible for every fault of the software. There is so much at stake, if I miss anything but at the same time very little that I get if I find one.
  • ANY MORTAL CAN DO TESTING: It is also a common perception that there is lesser skill levels associated with testing. To put it in other words, we think that testing can be done by any mortals. There is no proficiency that can be showcased to the world by doing a fine act of testing.
  • NO CLEAR END: A testing act at the outset, has no clear 'THE END' stage. We have grown up with the idea in mind that any software will have bugs. This vox populi retards the motivation of performing a perfect job. 
  • CUMBERSOME: Testing is also an umbrella act - there are many testing categories involved in an act of testing. To identify which are the relevant test categories that a given version needs to be put to and to stack up the relevant resources involved - this is a cumbersome task in itself.
  • VICIOUS CYCLE OF BUG FINDING - FIXING - REGRESSIVE BUG TESTING - REPORTING: Rigorous bug testing will be inhibited by the following cycle. Any version given initially for testing - will contain a bug. Fixing this bug will throw other bugs. Also other bugs might regress after the fix. So why do a rigorous test, when you have to go through the same vicious cycle after a fix is going to come? So a typical attitude will be: 'At the sight of any bug - abandon further testing. Let's rigorous test this when the fix for this comes.' 
  • BORING: There is some repetitiveness associated which might make it boring.
  • STATUS: Management doesn't consider testers equally with developers.
Why all the wooing then?
I was able to feel all the above points in my heart. But the issue was: If all this were there, why do our directors (a.k.a coders / product developers) keep spurring on the testers. They spend a good portion of their energies, motivating these guys. They seem to be pinning a lot of hopes on an act the result of which will not make the product sell more.After significant pondering over this, the parallelism dawned upon me:
'Testing is not a heroine - she is a character artist'. A character artist may not be able to attract people to come and watch the movie, but if there is no character artist and the associated scenes of emotion, the film will crash at the box office. That is what testing is : Its the character of a software. No matter how good the looks of a software may be (features), it will not be liked by people if it lacks character (being bug-free).

Reliability - A testers brainchild
The principal objective of software testing is to give confidence in the software. A customer can wait more for a new build or product release, but they don't like to work with defected software. Reliability is a hugely understated but yet powerful attribute to an application. Reliability can be defined as the probability of a computer program performing its intended functions, without any failure for a specified time under a specified environment. It is solely a testers brainchild.
"Reliability - Directly proportional to - Customer Satisfaction"
Reliability enhances (or diminishes) a product and in-turn a company's reputation.

Testers provide an environment of positive reinforcements to developers
For programmers, getting better at what they do requires quick feedback - positive and negative - on what they have done. The faster they they get the feedback, the faster they will learn. A great tester is such a precious asset to a developer. There is no better way to improve a programmer's morale, happiness and subjective sense of well-being than to have dedicated testers, who get frequent releases from developers, try them out and give negative and positive feedback. 

Even developers spend large chunk of their time testing too!
Microsoft chairman Bill Gates quotes the following about testing:
"Microsoft in terms of this quality stuff–we have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We’re more of a testing, a quality software organization than we’re software organizations ."

Testing is an act of a discovery
Discovering the unexpected is as important and in some cases more important than conforming the known. While doing testing initial rounds of testing, wear the second hat first and the first hat from there on. As to the attitude of a discoverer, Isaac Asimov quotes: 
"The most exciting phrase to hear in Science, the one that heralds discoveries, is not 'Eureka!' but 'Now that's funny..."

Every bug missed is a learning activity
Don't worry too much about a bug (may be a big one) that slipped through. Identify it, acknowledge it and learn from it. Every bug missed and acknowledged later - is a learning activity. The right spirit would be: 'This particular bug path will be considered every single time from now on and shall never be missed in my future tests.'

Testing activity as a team
It can also be an environment of fun and challenge, if testing can be done as a group activity. This provides ample scope for learning more about the software as well as the testing procedures.  

Graduate from testers to test designers
More than the act of testing, the act of designing tests in one of the best bug preventers known. Use all of your analytical and cognizant abilities, to design a testing procedure. 

Before any of the testing sessions, prepare:
  1. Testing documents - stating:
    1. features covered in the version
    2. features not addressed
    3. any other special environmental and process exceptions specified by the developer
    4. suitable knowledge base materials
    5. smoke areas for bugs
    6. testing categories that this version can be subjected to
  2. Resources for testing
 To conclude software testers do not make software; they make them better.
In God we trust, the rest we test....

Don't google... yet...

Google 貼牌冰箱(Google Refrigerato by Aray Chen, on Flickr
Creative Commons Attribution-Noncommercial-Share Alike 2.0 Generic License  by  Aray Chen 

Google is a very good tool and is a necessity in this fast growing internet age. But it cannot serve as an answer to anything.

COMMUNICATE WITHIN FIRST:
In fact for some of the most important things, the answers lie within. Not every problem that we face have a direct answer to them. A lot of them may be subjective and open to one's own imagination. It is after constant and continual reflections within that we can find the answers to some of these things. We need to urge ourselves to communicate to the voice deep within. Resist your urge to google your question immediately and quickly look at what like-minded people have arrived at. In my opinion, googling must be the last resort that should follow after 'talking-hearing-within' and appropriately documenting your thought process. 

INTERNAL CHEMISTRY:
Googling habit or tech-gadget reliance immediately at the surfacing of a question retards the chemistry that one enjoys with his inner self. Progressively one starts believing that he does not have the capability to provide a solution. One becomes a cattle member following the crowd. Believing that a 'ready-made' answer - that will perfectly solve your problem - lurks somewhere in the internet, diminishes the 'YOU' individuality. It makes you one among the common stereotypes.

HOW TO USE GOOGLE:
  • DOCUMENT WHAT YOU ARE LOOKING FOR AND WHY: When you reach a block, for which you have to find an answer - first document in your own words what are you looking to achieve / solve and why. This will help you set the context clearly not allowing you to distract. Use this to frame your search query astutely.
  • PRESENT THE BIGGER PICTURE: This might follow immediately after documenting the issue or after gathering the first set of search results. How does the answer shapes the further proceeding of the project. This helps in looking 'beyond'. By this you don't limit your search to 1 answer - which is good in a lot of cases.
  • ASK YOURSELF IF YOUR UNDERSTANDING THIRST IS QUENCHED: Ask yourself whether the answer that you have arrived is completely satisfying your understanding. If there are areas of uncertainties, document them and either research more or proceed further based on your judgement of the magnitude of the uncertain areas.

WHEN TO USE GOOGLE:
  • Validation of properly established opinions and calculated assumptions
  • Events, locations and people searching
  • Direct answer questions such as math related issues
  • Documentation templates

Finally remember to constantly revisit / evolve what you are looking for.

Monday, 3 September 2012

Traits of the "rainmakers" and how to become one




"The Rainmaker Professional", Photo Credits: amrufm via Flickr 



The Rainmaker:

Each day of our lives, we get to meet a lot of people doing their work. These people may be selling their product / service to us or they may be our clients or they may be our colleagues. Once awhile during such interludes, some one amongst this crowd may throw up himself / herself as a 'rainmaker'. The coining of the word 'rainmaker' might be more biased on the economical scale and personalized to an institution - but the intent that it is being used here in this post is simple. 

'Rainmaker' is the person whom we want to be associated with. With whom we yearn to enter into a business. Whom you would love to have on your team list. When it is said that these rainmakers throw themselves up amongst a crowd - it barely is by verbal acclamation, but they stand out by their approach towards the work. What is subtle is that the other people in the crowd, although have an envious attitude towards these people, eventually gravitate towards their work.

In this post,we are going to discuss about the approach of our rainmakers towards work. Some people seem to be naturally blessed with these traits while some go through a lot of experiences to imbibe these traits. But here's the good news: the first step towards becoming a rainmaker is being conscious of these traits. After realizing it has to be put into action and then eventually by practicing it again and again, it has to become a characteristic. 

Acquiring these traits present a huge challenge that involves addressing the minute little things in the path but the rewards are very high. You will build up a huge self respect and also be respected by others in your working circles. In the long term, you will be viewed as a 'Go-getter' and become a very influential person in other's life. Ultimately you will start attracting positiveness in all the spheres of your life.

Anatomy of a rainmaker:
Now lets do the mental anatomy of our rainmaker. Here is the list of traits of the 'I-like-to-work-with' individuals that we come across:

Enthusiasm
Enthusiasm encourages a person to stay open to tasks and face their underlying challenges rather than focusing merely the outcomes. Don't get me wrong - Results do matter. But keeping a constant focus on the results alone is akin to eating merely for having one's stomach full. You have got to enjoy the taste of the food. Rainmakers are process gourmets and this paves way for acquiring a cognitive mindset.
 
Devotion
Devotion to one's job is placing the work ahead of one's personal interests, egos, likes & dislikes. In Hindu principals - it is the highest virtue to be possessed by an individual and is treated as a means for attaining spiritual salvation - 'Karma Yoga'. One can often watch rainmakers would just stretch a little bit more to get the work done even when conditions are unfavorable or when people are satisfied.   

Passion
Passion arises when the work done makes one feel good about oneself. In other words, it is ignited when the core value of an individual is addressed. Rainmakers associate and bind their core values strongly to the work they do. And passion can make any task that looks tiresome to others, a satisfying pleasure trip for one. 

Focus
Focus is born when an assignment poses itself as a challenge. The quest of mastery of work - makes any task a challenge, notwithstanding the magnitude of the task. One would get to observe the rainmakers get 'into the zone' when they encounter challenges. In those Zen moments, one can feel the peak of concentration.

Resourceful
In order to be resourceful, one should venture into unknown territories. Here the focus is on lateral (horizontal) growth and not merely longitudinal (vertical). No doubt rain makers are proficient at what they do, but they also chip-in with significant contributions that could take the pressure of a working partner. Being resourceful also demands that you have a helping nature and a willingness to play the team game.

Troubleshooters
Experience results when one has the courage to time & again put oneself in a vulnerable, difficult position. And as one gains experience - one also gets composed, balanced and peaceful. All of these resulting from the 'been-there-seen-it-all' attitude complemented by a 'constant-improvement' attitude. Rainmakers  would not be deterred by anything and by virtue of which they have people wanting to come to them for refuge.

Composed
Being composed helps you put things in proper perspective. One's judgment and cognitive quotient shoots up when things are approached with a calmness. Rainmakers are real shock-absorbers for the rest of the team. Contributions from a composed person who has clarity of thoughts are always valuable. 

Patiently curious
Curiosity reflects a constant desire to expand oneself in his/her field. However curiosity with desperation works often in a negative way. Curiosity when constant and aided by patience and action results in a positive working mode. Rainmakers are naturally curious - but their patience often results in practical work-around when they do not have a clear answer. This makes them very effective. 

Forward looking
Planning / plotting before acting arises out of a person's tendency to avoid harm or difficulty. But this forethought fuels the evolution of an amateur into a professional. Rainmakers make sure all the bases are covered and often have an alternative plan up their sleeve just in case something fails.

Deliver more
Last but one of the most business relevant trait is add more value than what is expected. How good it is when someone gifts a fountain pen with ink filled in it. That is the art of delivering more. This comes from putting oneself in the shoes of the user and think what adds more value to the transaction. When rainmakers are approached with a service, one can be rest assured that they think more than what is requested and then offer greater value.

RECAP:



At the end of reading this exhaustive list, one might feel overwhelmed by the number of traits listed here. But these traits will throw up as choices or decisions one can take sides in real life circumstances. Identifying and choosing to take these positive decisions will slowly build you up into a rainmaker.
 
The first time I came across this term in a popular John Grisham novel - initially it represented a street smart person. But as I began encountering my work heroes in real time - it felt very relevant to tag them as my world's rainmakers. Today, I would like to challenge you - to be conscious of these traits and try to imbibe them, put them into action at your work and become rainmakers.