Author Archives: mthompeng07

Contingencies

In my previous posts I wrote about the elements needed to devise an effective plan, to anticipate problems, prevent their occurrence, and to deal with them if they occur.  With everything in place, nothing over looked, everything should run smoothly.  There is a good chance that will happen but there is the chance it will not.

Even though you have everything covered there is the possibility that something could happen that could hamper your progress.  The situation or event could be within or outside of the process or the design.  Either way it could be something that is beyond your control.

So far, the procedures I have written about, for the most part, have been reactive. Something adverse happens, we deal with it.  The only proactive procedure I have written about was anticipating problems and taking measures to prevent or quickly rectify them.

There is, however, a situation that I have not written about that we tend to take the reactive approach to.  That situation is when a feature of the product, service, or process being designed simply does not work.  As I said, the reason could be external to the system and / or beyond your control.  What do you do when that occurs?

There is only one answer; change it or replace it with something that does work.

Anticipating possible problems and incorporating measures to prevent them is a proactive action.  Redesigning a feature when you discover it doesn’t work is being reactive but it doesn’t need to be that way.  You can proactive about it. It starts with you asking yourself the question, “what if this doesn’t work?”

I always ask myself that question throughout every step in the design process for the following reason.  If the reasons for it not working is completely beyond my control then that feature will have to be replaced by one that will work.  That question then results in the following question, ‘what would work?’  That subsequent question, in turn, produces the need to devise a backup idea or plan.  Initially the backup idea does not need to be detailed.  It should just be an outline but it will set the potential requirements for resources and thus their identification.

If it is discovered that the feature will not work then a baseline alternate will have already been devised.  The resources for this alternate will have also been identified, therefore, considerable time would be saved.  It could be argued that time was already spent devising the alternate plans, so no time was saved.  While it does take time to create them, overall time would still be saved.  Take into consideration these alternate plans would be initially just a basic outline and they would be conceived concurrently whilst you were working on the details of the original idea, therefore, very little extra time was used.

I have experienced instances where a feature did not work. Management then became rather concerned about a schedule slippage. I would allay their concerns by presenting an alternate feature with it’s resources already identified. Since it’s outline and resource requirements have already been defined then there should not be any appreciable or no slippage to the schedule. Had I not already thought of an alternative feature then there would likely be a delay in the schedule.

So, does this technique save time? Definitely. It also reinforces confidence in the team and within it. You should also keep in mind that this technique is not just for individual contributors. It could also be used in the various aspects of management.

Until the next time!

Considering Immediate Cost And Long Term Productivity

Through most of my career I have used one type of software package and I was very proficient in its use.  I knew I should have tried other packages but I didn’t get around to doing that.  I was, however, rather interested in one particular suite that was gaining significant market share.  I asked some of my colleagues why was it so popular.  All they said was that it costs much less than the competition. That was completely understandable.  It is always preferable to get any product or service at the lowest price.  Or is it?

I finally got the chance to use this software and I was surprised with its functionality. Some of the basic functions were quicker to use than the software I was used to but I found it to be frustrating when I performed more advanced tasks.  I told one of my colleagues about my findings.  He had used this package before learning the suite that I’m used to. He mentioned it’s shortcomings and said he preferred the other software, despite it being more expensive.

Before I continue I would like to state that I’m not endorsing any product or service over another.  The purpose of this post is to demonstrate considerations that may not be present in the selection process of products and services.

When ever I performed an advanced function the programme would execute differently to what I wanted.  Eventually I discovered a technique to work around this shortcoming but it would take at least three times longer, depending on the complexity, than on the other programme.  This definitely had an impact on productivity.  The company saved money up front with the purchase price of this software but a portion of it’s operational costs had increased in comparison.  I would wonder if the equivalent cost of extra time to market was less than the price difference of the other software suites.  I was certain it was not considered.

I’ve witnessed the same thing with other products with differences in maintainability, reliability, security as well as other factors.  For example, if the selected equipment requires a more frequent maintenance interval, longer maintenance period, or breaks down more often then the initial purchase savings would be erased by the maintenance costs and the costs associated with downtime.  If the security capabilities of the selected system is not a robust as the higher costing competitors then the resulting costs due to breaches will be significantly higher than the initial purchase savings.  The downtime needed to mitigate damages, fix the vulnerability, or replace the system could be very long, therefore, adding considerable cost and adversely impacting productivity.

A somewhat similar situation could also arise when companies move their operations to low cost centers to take advantage of lower labour costs.  If the lower cost labour’s skill set is not near the level of your domestic labourers then quality and training costs will be much higher.  If the lower cost labour does not possess the same level of diligence as your domestic employees then problem identification would be greatly reduced.  Problem resolutions would only be accomplished by a select few rather than it being a combined employee effort.

Over the long term (or even the short term) these extra costs could easily exceed the initial savings thus eliminating it’s cost advantage. With that in mind, it is extremely important to consider the long term impact of any performance differences between competing products, services, or regions before deciding.  Also, if it is decided to change a product, service, or region after discovering the extra costs associated with a performance difference then there will be the addition costs of switching, in terms of set up, training, logistics, et cetera.

Until the next time!

Understanding Expanded

In my previous post I wrote about seven common points for effective listening.  I would like to expand on the point ‘understanding’.  I felt it warranted further explanation.  For example, a person could be listening well to what is said but they may not completely understand the intent of the message.  What I’m saying is that understanding goes beyond just spoken or written words.  It involves already having a background knowledge on the subject matter and using that knowledge to develop an idea of the goals; or the desire to gain further knowledge.

To be more specific, if someone was to tell you or ask you something and they didn’t provide all of the information, with your background knowledge you would be able to determine what the missing information is yourself.  If you didn’t have enough background knowledge then you would ask pertinent questions in order to obtain the missing information.  This is one facet of understanding.

I have been in situations where someone was expressing a need for something by listing the requirements.  They didn’t know what it was specifically but with the criteria they presented and my background knowledge I was able to tell them precisely what they were seeking.

Of course I have been in the situation of seeking something specific but not knowing enough to identify it.  An example was when I needed a certain electrical connector. I could have spent a considerable amount of time navigating several connector companies’ websites.  I felt it would be more time effective if I presented the criteria to the individual sales reps.  Since they have in-depth knowledge of their entire product line, they would be able to identify a suitable connector much quicker.

I provided the criteria and a 3D sketch of the required configuration.  My 3D sketch showed a generalisation of a 16 pin connector with mounting points on the left and right sides. None of the companies I contacted did not have any connectors in that configuration. The sales reps could have said, “sorry, we don’t have any connectors that match that configuration and ended the inquiry.  Instead one of the reps recommended a connector that looked nothing like the sketch but had two mounting points at the rear of the connector.  Without me telling him he understood the location of the mounting points was not critical, just that they were necessary . He also understood that the connector body didn’t need to look like the sketch.  Functionality rather than the looks was paramount.

Another sale rep recommended a connector that looked very similar to the sketch but it didn’t have any mounting points.  There was no way to secure it to the other component without the need to specifically design a bracket for that purpose.  That would have added time to the design cycle and other costs.  Overall, it was not a preferred option.

As I stated before, communications is all about getting what one needs, therefore, it is essential that you understand what those needs are.  Understanding them results in less time to realise the deliverables, greater satisfaction, appreciation, and higher confidence from the requester.  To aid in gaining an understanding of what is required the first thing you have to do is list the presented requirements along with the expectation.  You will also have to determine which information is pertinent and which is superfluous.  Referring to my example, the connector having 16 pins was pertinent.  It looking like the sketch was superfluous.

Once all of the requirements have been given you would then use your knowledge to derive a preliminary plan that would realise the desired outcome.  If you determine that you don’t posse the necessary skill set to achieve the required outcome then you would use your knowledge of your colleagues skill sets to determine which one would be capable.

It is very important that if don’t have the required skill set that you pass the task to someone else whom does.  At the very least, inform the requester that you don’t have the necessary skill sets.  Both actions will save time, prevent frustration, and a loss of confidence from the requester.

When it comes to expectations, the act of understanding something could be very involved or it could simply.  It all depends on what is required.  Essentially it is a combination of knowing the requirements and yourself.

Until the next time!

What Did You Say?

I ended my previous post with the question, ‘how does one becomes an effective listener or retains information better?’  There are a number of methods that are written on the Internet with some variations but they do have some commonalities.  These common points I noticed were:

– focus

– patience

– questions

– understanding

– impartiality

– empathising

– observation

There were other various points but those were based on personal opinions and specific settings other than the work environment.  The common points that I have listed are valid and I do use them but the way I use them is dependent on the situation.  The situation varies from group meetings to one-to-one conversations.

As I said before, in the work environment communications is all about getting what you need.  The information conveyor needs something done or delivered.  The information recipient needs to act on those needs or facilitate them.  In order to fulfill the needs of the conveyor you must have all of the relevant information.  To ensure that none are missed you need to perform the first point, ‘focus’.  You need to have your complete attention on the conveyor.  Nothing should distract you from what they are saying; with the exception of a burning building.  The conveyor may think you’re not serious, unprofessional, or even disrespectful if you are easily distracted by other things in the immediate area or what’s on your mind.  As I wrote in the previous post, this could result in the conveyor losing confidence and perhaps even respect for you.

To aid in being focused you must exercise the second point, ‘patience’.  Impatience is a definite distraction for focus, therefore, it is imperative that while you are listening you must not be impatient.  You must allow the conveyor to present the information in a manner in which they feel is effective and are comfortable with.  You may feel that the speaker is taking too much time but they may feel they are providing all of the necessary information. For one-on-one conversations or small meetings, if you have a very finite amount of time to listen, inform the speaker of that before they start; not during.  This will allow them to condense the information so you are not missing any when you leave.

If you have any questions while the conveyor is talking, wait until they pause or are finished to ask your questions.  While it’s unprofessional to interrupt someone, it’s embarrassing to be told that they were about to cover the answer to your question.  This is yet another reason why it is important to be patient.  Some people may feel the need to interrupt because they are concerned that they will forget their questions once the speaker finishes. A remedy for that concern would be to write down your questions in a notebook.  If your questions are answered while the speaker is talking then write down the answers next to your questions, for later reference .

This leads to the next point ‘questions’.  It is absolutely essential that you ask questions if the conveyor did not present enough information.  Your questions need to pertain to the requirements of the speaker.  If the speaker is conveying the performance criteria for a car, it would be irrelevant to ask what colour it should be.  Your questions should be based on an understanding or a lack of understanding of what is required.

This brings us to the next point, ‘understanding’.  There is no better way to be and remain focused than to make an effort to understand what is being said and what is being expected.  As I said before, communications is all about getting what the speaker needs. You must have an understanding of what that need is or strive to gain it.  If you have trouble trying to understand then your questions will be very relevant.

What I typically do whenever the speaker pauses is to formulate in my mind the best or optimum way to achieve the desired deliverables.  If enough information hasn’t been presented to achieve them then I will ask a question or questions, at the appropriate time, requesting clarification or more information.  By the end of the meeting I would have a general plan on how to achieve the deliverables.

Complementing understanding is ‘impartiality’.  Essentially, you must not allow your own ideas or preconceived notions to bias you against the conveyor’s ideas or procedures.  If you do then you will not be receptive to what the speaker is saying.  If you are not receptive then you will not be listening effectively, therefore, listening with an open mind is essential.

The next point is ’empathy’.  Some may say that empathy and understanding are the same point but they do differ.  Understanding is the comprehension of the content of what’s being said.  Empathy is the understanding of the conveyor’s situation that brought about that need, the urgency for it, the criteria for obtaining it, et cetera.  By having a comprehensive understanding of this background information you will able to devise a more effective, quicker solution.  There would be less time spent obtaining clarification, negotiating compromises and less iterations involved.

The final common point is ‘observation’, the act of noticing non-verbal cues.  These cues could include facial expressions, eye movement, hand gestures, body posture, et cetera. The authors of these listening skills articles state that much information can be obtained from these cues, which I don’t doubt.  Personally, I’ve never utilised observations to determine what these cues are probably indicating.  I have found in the work environment that it was always in the best interest of every conveyor I’ve dealt with to state all of the essential information in order to get what they need.

As you have noticed, just as productivity aspects are all interrelated so are the common points for effective listening.  Focus requires patience.  Empathy requires impartiality.  Questioning requires focus and understanding and so on. With these seven points always keep in mind that communication is all about getting what one needs and listening is all about getting the necessary information to provide those needs.

Until the next time!

The Other Side of Effective Communications: Listening

I wrote a couple of post a fair time ago about the importance of effectively conveying information in various forms by ensuring it is complete and without any ambiguities.  The impact on productivity due to missing, incomplete, or misconstrued information varies.  It could be inconsequential to very significant.  It all depends on the situation and timing. Either way, the importance of effectively communicating information is immense. Important as it is there is no guarantee that the desired results will occur.  Even if one spends an appreciable amount of effort and due diligence to ensure that the information is complete and concise, the outcome can still be the same as if those activities were not performed. This outcome can occur when the recipient is not listening, paying complete attention, or they forget the information shortly afterwards.

I have read several articles about the importance of thorough listening and they all present points that are worth while committing to memory.  However, I noticed some variations to their points on how to listen effectively or at the very least inspire confidence in the conveyor that you are listening effectively.

For the information conveyor their means is getting what they need.  For the information recipient, it is more than just producing the need of the conveyor which is at stake.  The conveyor’s confidence is in consideration.  In other words, it is one thing not to deliver what is required.  It is another for the conveyor to lose confidence in the recipient to deliver.

I have experienced this with a supplier.  Some products were delivered to us that were faulty.  The fault’s progression was due to a breakdown in communications.  There were some differences between what was required and what they were able to produce.  The supplier should have directly communicated these differences to us before the products were made.  Instead they embedded this information in a document provided to us, therefore, it’s criticality was not expressed.  I phoned the supplier to discuss the issues. After a brief conversation I decided to visit them to learn first hand how they make the product.  With that knowledge I could be able to instruct the supplier’s engineering personnel on how to make the products so that they completely conform to our requirements.  While I use doing this the engineering manager pointed out a shortcoming in my idea due to an inherent limitation in one of the processes.  I then told them of a way to work around this limitation which would still meet our requirements.  They all agreed.

A few days later I received an e-mail from the supplier stating the process they were going to use to rework the faulty products.  I was not familiar with this process, so I sent an e-mail to them asking about the parameters of this process.  The engineering manager responded by mentioning the limitations of the first process that was discussed in person.  He also repeated his stance that one of the requirements could not be met due to this limitation.  To say I was surprised would have been an understatement.

In my e-mail, I was asking about the second process, not the first.  Also, it was discussed two days prior how to work around the limitations of the first process, in which everyone agreed to.  Not only did the supplier’s engineering manager not answer my question, he completely forgot our discussion on how the product should be made.  I was starting to lose confidence in the supplier.

As you just read, not listening to someone, in this case a customer, does not just impact productivity.  It also affects the information conveyor’s confidence in the recipient and ultimately their reputation.  That in turn could reduce the probability of repeat business or for an employee a reduction in responsibilities.  Any erosion in confidence would be difficult to regain.

How does one becomes an effective listener or retains information better?  For the sake of brevity I’ll answer that question in the next post.

Until the next time!

A Component Of Innovation: Materialising Your Ideas

The other day I was perusing through my saved articles in my Globe and Mail app.  One of them stood out because it reminded me of something that happened when I was in high school.  This article, titled “Do you have what it takes to innovative?“, was written by Peter Aceto.  Mr. Aceto is the president and chief executive officer at Tangerine Bank.

His article essentially stated that true innovators have the drive and perseverance to turn their ideas into reality.  How many times have we heard or said ourselves, “I thought of that before”, when we see a revolutionary product or service?  A follow up statement would then be, “I should’ve acted on that idea.”  I’m sure many of you have witnessed or experienced it.

This is what happened to me rather recently, except it was not me who came up with the great idea.  It was created by one of my chums in school.

He came up with an idea to invent a remotely piloted aerial vehicle that could be used by law enforcement agencies.  It’s function would be reconnaissance of potentially dangerous situations.  Does that sound familiar?

The use of aerial drones has increased exponentially.  Anyone can buy one.  Their prices range from the relatively inexpensive and up.

You’re probably wondering why he didn’t follow through with his idea.  It was (or is) an excellent and rather versatile idea.  It’s uses has gone well beyond law enforcement.  They now have commercial and industrial applications.  They are also increasingly being used by hobbyist.  Having an idea which had such a great potential, it is unlikely that anyone would not follow through with it.  Well, the actual reason why he didn’t materialise it was he gave up too easily.  He discovered a technological problem and didn’t bother to find a solution around it.  He accepted the premise as an impossible one.

Today we all know just how possible aerial drones are.  Which is probably evident of someone else possibly encountering the same or similar technological problem and finding a solution for it.  This is the essence of Mr. Aceto’s article, inventors demonstrating  perseverance to overcome any obstacles they may encounter and turing their ideas into reality.  His article also states a natural tendency for people to give up when they do encounter a problem.  He even goes further by indicating that some people will even create a hypothetical problem or constraint, which would lead to the same result of giving up. This made up problem or constraint may not even be applicable but it is treated as an excuse to quit.

I don’t know why people generally do that but I have witnessed it a number of times.  My advice for anyone whom may feel the need to give up is simple.  Focus on the goal and only the goal!  If you do encounter an obstacle then the only thought you should have is, what is needed to get past or around that obstacle?  As I’ve stated in a previous post, ‘Know Yourself and Your Performance‘, when you encounter an obstacle you should determine if you have the capabilities to resolve it.  If you don’t then you should determine who would have the required capabilities.  I have on many occasions enlisted the help from people who had the required skillsets to resolve the problem. Again, I did what it took to achieve the goal.

Even though I’m giving advice about turning an idea into a product, this advice could also be used developing an innovative service, procedure, or process.  It’s all interchangeable.

Achieving the goal of turning your idea into reality becomes even more satisfying when you’ve overcame obstacles to get there, in addition to the success of your idea.  With the numerous drones flying around, and their numbers  increasing, I’m sure my chum from high school has thought to himself “I should have followed through on that idea”.

Until the next time!

Employee Empowerment

The last key for a successful company turn around that John Chen mentioned in his blog was employee empowerment.  This was the only key of his which I did not write about as an aspect of productivity.  Since I didn’t write about it, do not think I consider it as not pertinent. It is just as important as all of the other aspects.

The reason why I didn’t write about it is actually quite surprising.  I really didn’t think about it.

You’re likely wondering why I didn’t think of it, yet I wrote about those other aspects.  The reason was that empowerment was inherent in every environment I’ve worked in.  I’m so used to it that I don’t think about it.  If any of my co-workers or myself encountered a problem or an oversight that was made by someone else, we immediately took the necessary steps to correct it without asking permission from management.  Like most things in life, there are exceptions.  Those exceptions could be ‘customer specifications’ related.  In that case, permission would definitely be required.

Essentially, empowerment is the act of giving the authority to subordinates to make their own decisions, take risks, to take control of a situation that requires an immediate direction, et cetera.

If employees are empowered then decisions on several matters could be accomplished by several people rather than by just one; the manager.  Projects would progress at a faster pace.

A recent example of this occurred when our project manager decided to have a supplier supply a main component in a semi-completed state.  Our fabrication department would then complete the parts by adding the remaining features.  The project manager naturally assumed that the remaining fabrication would be well within the capabilities of our shop and it was a correct assumption.  Our fabrication department have consistently produced excellent components.  Personally, I don’t make assumptions on anything, regardless of past performances.  I decided to ask the fabrication manager if his department was capable of the required operations to finish these parts.  He replied it would be very difficult due to possible imperfections in the semi-completed parts.  I informed the project manager of the fabrication manager’s concerns and I suggested a higher point of semi-completion that would be free of any inherent imperfections.  He agreed to my suggestion.  It was very fortunate that I had done this.  Had I not taken the initiative to check with the fabrication manager, the result would have been in a much long project completion time and extra costs.

That was an example of what John Chen expects in his organisation, employees taking the initiative to take action on things that they recognise as a potential problem, as well as providing ideas.  It is easy to sit back and say “I knew that was going to happen” but that hindsight doesn’t benefit anyone, not even the person making that claim.  Productivity suffers and consequently the company’s bottomline.  One will not be appreciated when they make an after-the-fact claim but they will be appreciated if they are proactive the moment they’ve identified a potential problem.

As a manager, you have to be open to suggestions from anyone regardless if they have less experience and knowledge than you.  They may have noticed something you may have overlooked or not considered.  By letting your employees know you are willing to listen and give consideration for their ideas you will be fostering initiative with your employees.  Once that is established your projects should run faster due to others, not just management, making decisions on matters which requires immediate attention.

Until the next time!

Know Yourself and Your Performance

Another fundamental key for John Chen’s method for corporate turn around is “Know Thyself”.  This key has similarities to a requirement for productivity which I wrote about in a previous post, ‘Know Your Performance’. Both of these requirements have the basis of establishing a baseline and determining your or your organisation’s capabilities.

As much as they are very similar, their intended uses and subsequent goals are different (on the surface).  John Chen’s use for ‘knowing yourself’is for exploring and executing new strategies for new revenue generation, while the ‘know your performance’ goal is for improving productivity of the established operations.  Even though the goals are different, their approaches are the same.  When it comes to reaching either of these two goals it is important to know your own capabilities, your colleagues, as well as that of the company. Think of yours and everyone else’s capabilities as additional available data that can or should be included when devising actions, determining feasibilities, or overcoming obstacles.  Keep in mind, it is one thing to know what are your available resources.  It is another thing to know how to effectively use them.  This now brings me to the next point.

We all have encountered problems we have never seen before.  When that happens there is an understandable tendency to believe that one is not capable to deal with such problems. This is due in part to a lack of experience.  The other reason is a lack of confidence. Experience can be gained by attempts and actions.  Confidence, however, can be gained when a feasible plan is present and / or capabilities are known.  When you know yourself, your colleagues, and the capabilities of the company confidence levels increases.  That feeling of uncertainty then diminishes.

When ever I encounter such a problem or requirement the first thing I do, after reviewing the criteria or determining the root causes, is to ask myself the question; what is needed to satisfy the requirements of the criteria or solve the root causes?  I then look at my own capabilities and skill sets to see if I can accomplish the task.  If my capabilities are inadequate then I would do a quick mental search of who does have the required capabilities.  Once it is established who has the required capabilities then a plan can be created.  With access to the known capabilities and a plan in place, everyone’s confidence levels increase.

When you are tasked with doing something completely new or different and you have established the capable resources at your disposal, devise a plan that directly addresses the requirements.  It doesn’t need to be perfect, just effective.  With that mindset, known information, and identified resources, moving forward on which ever path becomes a less daunting endeavour.

Until the next time!

Urgency Is Key

The next key John Chen mentioned for a successful organisational turn around was ‘Maintain the Sense of Urgency’.  He again touch upon two productivity aspects I have mentioned before; speed and selectivity.  I have only covered selectivity partially in my post ‘Information Excess‘ but I’ll go into more detail on it now.  Selectivity is as it sounds.  In the terms of productivity and organisational turn around, selectivity is the act of determining what is necessary to do and what isn’t.  It is also a determination of how much resources are required for completing certain tasks and then assigning priorities.

If a task requires more resources than what you feel is acceptable or it’s level of complexity may slow the overall process or even stop it then you could decide to avoid it.  The decision to avoid it would be easier if it is determined that it’s results are not necessary for the project’s completion or the lack of them will not adversely affect the outcome.  A very simple example of this was when I was about to write a test or exam at school.  Before the commencement of the test I would divide the allotted time by the number of questions.  That would determine the average amount of time I had to answer each question.  I then divided that time by four to give me the amount of time I had to devise a way to solve the problem. If I didn’t determine a method to solve it within that time I would go to the next question.  The philosophy behind this method was that I would not spend too much time trying to determine a solution to any one question.  If an excessive of time was being spent trying to answer one question then there may not be enough time to answer some or most of the remaining questions.

This is what John Chen meant by the term “paralysis by analysis”.  Overall progression is halted by the expenditure of resources on a given task at the expense of the other tasks not being completed.  Going back to my example, if the test consisted of 20 questions, it would not be as large as a detriment if one question was not answered as compared to ten.  It is therefore important to maintain your perspective in order to maintain your sense of urgency.

This was evident when I was working in a high volume manufacturing environment.  If a problem occurred during a production run or a problem causes the production to stop, that problem would cost the company an appreciable amount of money for every minute that went by.  That goes without saying that urgency was a mandatory requirement for the problem resolution. The quickest, most direct approach was preferred.

During my time in this company one of my colleagues asked me to assist him with interviewing some candidates.  During the interview I told each of them I will ask situation based questions that were relevant to the company’s operational environment.  One of the questions involved a part that had a nut permanently attached to it but the assembly drawing showed a mating screw that had a different thread.  I explained to the candidates that the screw and the nut could not be mated and the production line was still producing the affected parts.  I also told them that the finished products had to be delivered on the same day.

I was surprised of most of the candidates’ answer.  Their answer was to conduct a feasibility study on comparing the costs of replacing the nut, the screw, or scrapping the parts.  I reminded the candidates whom gave that answer that the finished products had to be delivered the same day.  In other words, there wasn’t enough time to conduct this study and deliver the products punctually.  They then sat quietly while they tried to think of another answer.

Only one candidate gave the most appropriate answer; simply replace the screw.

When you have to maintain urgency in your tasks, always keep your sight on the required outcome.  That will help you to maintain perspective.  Always look for the simplest solutions, that you believe will satisfy the requirements, first.  If that simple solution does not complete satisfy the required outcome then modify it incrementally until it does.  These simple two steps should prevent the condition of “paralysis by analysis” by not complicating what is required.

Until the next time!

Problem Solving Is Part Of The Culture

The next key to a successful organisational turn around that was mentioned in John Chen’s post was ‘Create a Problem-Solving Culture’.  His primary goal of this key was to have employees focus their efforts on finding a solution and not dwell on the problem itself.  He has found that when problems occur people generally tend to only talk about the problem. That in itself becomes a self defeating exercise.  Focusing on only on the problem has the effect of dragging people down since nothing is being accomplished.  As time goes by the problem would seem bigger than what it really is.  As John Chen mentioned, “hopelessness reigns”.

In this second key John Chen has touched upon two of the productivity aspects I’ve mentioned before; mindset and root-cause analysis.  This was evident when he stated that employees need to have the drive to quickly devise a solution once a problem has been identified.  Drive is a component of mindset.  It overcomes complacency.  It either ignores or utilises your ego as a motivating force.  It also works with focus to keep your eyes on the goal.

While drive may come naturally to some it is not for others.  As I mentioned in a previous posts, it is not easy to overcome complacency, ego, and the detrimental side of focus on your own.  We tend to stay in our comfort zone unless a motivating factor causes us to leave it.  Our egos are a little harder to let go.  The motivating factor would have to be much stronger.

That motivating force could come from the management but it would be tedious for them to motivate the employees whenever a problem occurs.  That is why it is preferable for employees to be self motivating; not just when a problem occurs but at all times.  To be self motivated we need to be aware of our complacency, egos, and poor focus (or too much focus).  We also need to be aware of the consequences on productivity of those three traits. That is the first step to developing and improving our drive.

With our determination engaged and we are properly focused on the problem solving task, we can then find an effective solution for the problem.  As I mentioned in my post on problem solving, to effectively solve a problem one must investigate it’s root causes. Having the drive and addressing only the symptoms of the problem would have the same outcome as if one didn’t have any drive at all.  Time and energy would be wasted since effective problem solving requires determining and addressing it’s root cause(s).

All of this may seem like a daunting task initially but like any thing else you need to identify the steps first and then take them one at a time.  Over time this procedure will become second nature to you.  You will not need to think about the steps.  You may even modify some of the steps to improve the procedure’s efficiency.

This is essentially the points John Chen was conveying in his second key to a creating a successful turn around of an organisation, ‘create a problem solving culture’.

Until the next time!