Tuesday, March 2, 2010

Lessons from Toyota


The ongoing Toyota fiasco and investigations is an interesting case study from which all organizations, and especially your own staff can learn a lot about how we run our projects, products & business.
Stated briefly the issue is that there was unmitigated acceleration in several Toyota cars and models - so when the accelerated pedal was released the vehicle did not decelerate but kept accelerating on.The issue led to atleast 2200 car crashes and 26 deaths according to reuters - http://www.reuters.com/article/idUSTRE61904Q20100210 .

While we have got used to such numbers and statistics here is the actual traumatic , fatal 911 call of a lexus that led to the discovery of Toyota's massive cover-up.

For Toyota the issue has led to huge recalls around the world - Atleast 12 million cars are expected to be affected according to some sources leading to expenses of billions of dollars for Toyota. Toyota stock price will be driven down and so the company's worth will go down with it.
Toyota has to face the music in the US , China, Japan , elsewhere and has had to face government investigations. It will also now have to face numerous and costly litigations. Brand has taken a hit and that has long term implications.
Here are 3 questions , pertinent to running our own businesses :
1) Was Toyota Corp in denial mode ?
Toyota had clearly been in denial that such a 'bug' existed. It even deflected agency investigations about the issue. This issue had been happening atleast since 2002 : for 8 years they had been able to deny the bug while damage was being done !!. Often accident victims were blamed by Toyota for their driving, instead of the product. In other words it took 2200 accidents and 26 deaths for Toyota and the government departments to wake up to what maybe happening. If they had not been busy denying and looked into the bug earlier would it have saved them the billions they are forced to spend now ?
2) Quality was made-up :
The fact that quality had been overruled in the company was given away when Mr.Toyoda, the president of Toyota Corp, immediately restructured the quality department to report to him directly. Who was the quality department reporting to till then ? And its not too difficult to guess what kind of reporting they must have done.
When sales imperatives or project management take precedence over quality usually disaster is waiting to happen ( hello subprime crisis !). But even more likely, the issue was spotted and known to some grassroot level quality worker whose protests and notices were smothered by a mass of seniors like product managers, quality managers and vice presidents. Quality becomes a cliched word and, often stage managed in many projects. The Quality department is looked on as an hinderance as if otherwise operations are always smooth. Very few managers know the history of quality and what used to happen in industry before the quality movement came in the 1940's.

Sometimes the level of risk in IT projects cause me to shudder - lack of testing, buggy code, numerous patches, poor project management, ambiguous requirements, limited resources, duplicate systems, redundant data.......a single line of buggy code can cause millions of dollars in actual damage. We need to know always what is important and what is not to the project and the business, and not flinch away from keeping to those standards ever. Thats is the hallmark of a great , trustworthy consultant.

3) Changing circumstances :

What finally bought up the issue to speed ? It is very interesting that the issue comes to light when the global economy has suddenly collapsed and shrunk. The good thing about the ongoing recession is that several poor -quality businesses have been flushed out into the open : eg..those that ran on poor liquidity (Madoff, Satyam) : those whose mistakes may have been overlooked or even forgiven during better times. And we often have no control over circumstances when they change. We have only ourselves to blame if we were not better prepared for it.

Tuesday, January 26, 2010

New hire PMPs - how to publish for certain target groups

Publishing plans for certain groups of people only is very difficult if not impossible in Oracle Talent Management 12.0.7 and earlier.
I have already in a earlier blog post indicated how we can setup that a PMP goes only to certain people.
Now further, if you are using Objectives & Objectives library though it maybe possible to restrict whose scorecard will have valid objectives and whose doesnt. This in a sense can functionally restrict whose scorecard can get appraised by the supervisor and whose scorecard cannot be.

Objectives in the Objective library are linked to employees via eligibility profiles. Eligibility profiles can be defined based on many many parameters including date of hire, date of joining etc...now if you setup such a eligibility profile say only those whose 'length of service' should be minimum 6 months atleast and link it with an objective then a PMP which includes this objective will have scorecards with objectives only if the employee has been in the org for 6 months atleast.

Friday, November 13, 2009

how to restrict a PMP for just specific people in the hierarchy

Here is a tip for those working with Talent Management . It looked like there was no way to publish a plan just for a specific person using PMP. So for example new hire cases used to be a pain right ?. And invariably one would have to customize for this.
There maybe a simple functional workaround for this.

SUP_ASG hierarchy type of PMP will create scorecards and appraisals only if the worker assignment number of the supervisor is in place. So if you want to publish a plan just for a specific person(s) in the hierarchy you should setup their assignment record with worker assignment number of the supervisor ( there are two assignment numbers in the assignment screen) and publish a PMP of type SUP_ASG. This plan will appear only for those specific people now.

Friday, October 23, 2009

HR issues in project management - when not to let go of an employee

If a popular employee or a intelligent person in the group is to let go, the effect seems to be that credibility of management goes down bcos it gives out the sign that management did not want to hear such a person.

Considering the psychological effects of letting go of a person or, in general, of any decision is very crucial to the success of the decision.

People see trends in everyday occurences.

Tuesday, July 28, 2009

Republishing a PMP

Problem in republishing PMP v 12.0.6 :
If Appraisals are created and then PMP is republished then scorecards cannot be edited bcos an appraisal id is already created.
Hence a good practice is to avoid resetting appraisal dates : have a good gap between the objective setting period and appraisal start date if possible

Monday, July 27, 2009

quirks in implementation

The problem in implementations comes not from business rules but rather from the exceptions that users want to have to the rule. eg...HR specs that a manager shud be able to view only his hierarchy. No problems. But then the manager for many reasons does not make changes themselves so they give access to their secretary or second level leadership to do the menial jobs.....that is where issues start coming in....

Thursday, June 25, 2009

pride goeth before a fall

There is nothing wrong with learning new stuff in apps. But what is shortsighted is to not share it with anyone and becoming proud of your niche. Some other fellow who knows more than you will come along and that will be the day you meet your maker.