Rss Feed
Tweeter button
Facebook button
Linkedin button
Delicious button
Digg button
Stumbleupon button

Posts tagged recommendation

Be LEAN .. this year !

 

In last few days I have been fortunate enough to participate in the workshop for LEAN service framework. And thus, I am trying to share my experiences and learning on LEAN here.

The LEAN framework originates from the manufacturing system developed by Toyota called Toyota Production System [TPS] that pursues the principle of optimum streamlining throughout the entire system through the thorough elimination of waste and aims to build quality in at the manufacturing process while recognizing the principle of [ongoing] cost reduction. It also includes all the accompanying technology & tools necessary to accomplish those aims.  [Reference .. here]

The process that Toyota developed for Just-in-time production was called TPS until 1990. MIT researchers tossed the term LEAN in their 1990 book called “The Machine that Changed the World” to describe the principles of Toyota Production System. Thereafter, of course, the process was known to the world as LEAN Service Framework.

In a nutshell,

LEAN is an integrated system of principles, work practices & processes that empowers the operational users to drive the relentless pursuit of perfect customer value creation. 

Although LEAN was innovated and started in the manufacturing industry and especially at Toyota, it, over the years grown out of the manufacturing industry and into other verticals, not to mention the IT/BPO industry.

LEAN underpins 5 principles in the framework as follows,

 

Lean Principles

 

 

 

  • Eliminate Waste – As per the LEAN principles, the waste could be due to the idle time spent by the employees waiting for work, or spending extra hours to exceed customer expectations (without customer asking for it), excessive testing etc., activities and all such activities that do not add add direct value to the customers.
  • Eliminate Variability – This talks more about complexity of the work within the team. LEAN suggests eliminating the variability of work done by the employees so that activities & individual performances are streamlined to carry out typical activities. This also talks about the external work that comes within such as ticket trend, business requirements etc., and suggests to streamline.
  • Eliminate Inflexibility – This suggest more about the resources capacity and the work segmentation and align the efforts and create skill pools so as to better utilize the knowledge, performance & work practices against repetitive / common tasks.
  • Performance Management – LEAN suggests to compute the performance of the individuals as well as the team and making the results publish to the individuals / teams and discuss with them on a regular basis. LEAN recommends that regular performance discussions enhances the team morale, gives them goal to enhance performances etc.,
  • Involvement of workers – LEAN, more than a process is more of a philosophy and change in the thinking of the workforce and suggest to have the workforce participate and understand these principles so they themselves are aware of the waste being created around they can eliminate themselves.

 

Many IT companies have implemented LEAN successfully. IBM has been doing the LEAN implementation for the customers since last 3+ years. Over the years, being LEAN organization has been a selling point for the IT vendors and equally the customers have been demanding. 

The benefits of LEAN include reduce waste, reduction of inventory costs, cross trained employees, reduced cycle time & obsolescence, high quality & reliability and may more.

 

This, of course was a drop in the ocean of the knowledge of the LEAN framework, even for me. If you are interested in knowing more and reading more, suggesting the following reading

Principles of LEAN Thinking

Lean Manufacturing  &  Lean Software Development

What is LEAN?

Benefits of LEAN

LEAN – The Machine that changed the world !

Bye the way, if you have read the above carefully, the following video might tell you something.  Have a look (with audio ON) and let me know what you think ?

 

Caltex – going extra mile !

… and the reward goes to ..?

Ohh .. wait a minute !

This article has nothing to do with any award / reward function you would see on a television, cinema, but its more to do with the way awards and rewards are judged within an organization and how sometimes it puzzles me.

Today, I had been to a rewards committee meeting as a guest judge and at the end of meeting, I left the room with lots of thoughts to ponder with.

award-cup Few days before the meeting, I was sent an excel sheet with good detailed nomination information about  6 candidates from whom I needed to judge the top two candidates. The top two would be rewarded a certain amount as per the company policy. There is a quota of the monthly / quarterly awards which are distributed at the end of every month / quarter.

Normally, the rewards committee has few fixed judges and few guest judges. I was one of the guest judge this time and was asked to voice my inputs on who would, in my opinion, win the award and why.  During the discussion, I observed that the rewards committee makes a good effort and attempt to discuss each case and try to give their opinions on the face value of the nominations they are presented.

On a whole, the process of inviting nominations from Project Managers and having a meeting in which a representation from Sr Management, HR & few guest judges would decide who wins, is good enough in most of the cases.

Most of the decisions, unless the judges know the nominee well, are made on the basis of what is written in the nomination form and how well the arguments are written.

The whole discussion made me wonder, in the end, who actually gets rewarded?

Is it the person who has done a great work or the person who has actually written a great nomination form with appropriate arguments?

How do you ensure that the right person gets the award?

What I have also seen, is the fact that the award normally goes to the person who has come out of adversity and saved a project from a serious escalation or from a difficult situation. Example of this could be someone who has just handled a business critical Priority 1 problem and resolved it within the SLA timings.

Then there is one person who makes an effort all year to keep a consistent performance and ensures that escalations do not happen and also ensures that the crisis situation never arises. This person, although gets nominated for the award, but would never get it, because his nomination form would be a lightweight, compared to the first one.

Typically in the support project, what I have seen is the team or the individual that resolves most problems or most crisis situations is rewarded the most. While, in a positive way it is correct to appraise a person who has gone extra mile to resolve the crisis and save the project from any potential penalty.

However, on the other hand, few people who are proactive, keep wondering what they need to do to get a recognition? In few discussions with the teams previously, we used to joke that we have got the project to such a stable phase, that there is no more challenge left which would give the team a chance to shine above the rest. !!

In a nutshell, there are quite a few factors that would determine whether a project or a person would get a reward or not and few of them I could list as follows,

  • Type of project – If a project is stable and all processes are matured, then there is a less likely chance that the project would be considered for any award. Eventually, all the people working in the project have less chance of getting recognized for their work.  Effectively, since the project itself does not offer any challenges, even outstanding person would struggle to get a recognition for the work there.
  • Nature of work – If someone has saved the project some costs, efforts or time, then the person would be worthy candidate of being nominated for the rewards. Whenever the nomination is given, its important that all the necessary details are furnished properly. Moreover, the benefits must clearly come out of the nomination form. The words such as costs reduction, resource reduction, automation, efforts saving, crisis resolution  should come out appropriately and should be emphasized.
  • Glorify the work -  As I mentioned above, irrespective of how many judges know your work quality personally, the decision is made on the basis of what is written in the nomination form. So its very important to glorify the work and presented accordingly.
  • Awareness – One of the most important aspect of being rewarded for outstanding work, is being aware of rewards process and ensuring that the information is proactively sent with some good details as I mentioned above.  During few discussions I had with the teams, it was observed that the team ‘expect’ the managers who work with you to ‘recognize’ their work automatically without the team expressing willingness and desire to actually have one awarded. Its a misconception that the work would automatically be awarded without any advertisement or internal marketing. Unfortunately, its one of the most difficult part for teams to understand and practice.
  • Due attention by project managers – Its very easy for project managers to put the blame on the rewards committee about lack of reward to the team. The rewards committee is the soft target by many project managers who fill up the nomination form just because its mandatory and lack ‘awareness’ as I mentioned above.  The project managers should ideally go all out to ensure that all correct details are furnished, glorified and presented accordingly for the rewards meeting.

These are just some of the tips you could use to assist yourself in presenting your case better.  Finally, a quick word on what I believe,

There is only one alternative to hardwork, its name is ‘smart work’ !

Taking ownership of tasks – when should you or when should you not?

Its often expected by customers that the vendors take ownership and full accountability of the projects and related pitfalls. While on one hand its good to take ownership of the tasks in your project and deliver them on time, within budget and exceed expectations, its equally important to understand the remits and scope of your work and project before assuming the responsibility & the accountability of failures.

Not only by the customers, but the display of the ownership from team is demanded by project managers & senior managers as well.

A Dilbert strip below just about sums up how the management assumes project teams to “own” things !

dilbert_ownership

Quite rite ? Do you think so ?

It is essential, to demonstrate the capability to own and deliver the things, however it is equally important to know the limits of the ownership and a clear understanding of what you should deliver and be accountable for. 

If you are into application support and maintenance projects, its even more important to know your project boundaries & scope so you could actually define the components you own and maintain.

Typically in the support projects, with the scenario of multiple support teams supporting various components in an end to end journey, the problem or fault can lie in any one or more components in the chain.

If any service impacting incident occurs in such scenario, I have seen customers pushing the front end (or Portal or Website) support teams for solutions and RCAs. Irrespective of where the problem or issue lies. It is fact that in a web based journey the problems are only visible in browser and thus generally it is perceived that the teams that supports the actual portal application are responsible for owning the investigation & resolution of issues.

Generally it is OK for the ASGs to take up the responsibility of owning the issues & try to get a solution in place ASAP. However, it is probably too much to expect them to own the end to end stack and push for investigation & resolution where the fix lies outside the boundary of the support team.  In such cases, I would rather have the E2E Service Managers to own the fault and drive the resolutions through the downstream systems rather than the poor portal ASG teams. 

I do not think there is any concrete definition or rule which says which tasks / issues / problems / escalations you should own up and which you should not. However, in case of the conflict I would suggest it is always better to stick to the rulebook (i.e., scope of work, application boundary) and take a wise decision.

After all, you would not want to lose brownie points !!