Marinate

Marinate - Not a very business savvy term. However, this is something that is very essential for any process / resource to operate irrespective of the geography and the industry.

Take a look at almost every project delivered across the world. Is there a perfect deployment without even 0.0001% stability time? The answer is NO ! However, I find leaders across the world that conveniently choose to ignore that they have to give sometime for the new project to stabilize or the new process to be be ingrained into the organization. I see this happening time and again, a new product development / new project / new Endeavour is planned and the ROI is always calculated from the date of go-live and does not usually take into account the overhead associated with the stabilization period that I like to call the time to Marinate.

How do you go about getting a successful marination (if there is ever such a term) done? Always remember as leaders, that change is the most difficult thing and therefore allocate a period of time for the users to marinate and soak in the new processes. Of course, as if you were cooking something, you would want to have period checks to see how the marination process is progressing. Lastly, in order to ensure success, have a line item in the project / product plans for the marination-cost and begin your ROI calculation at the end of this period.

So, the next time around, when you are bringing in new technology, will you remember to marinate before you deploy? Think about it !

Sustaining generic process

The dream of every executive - design and implement a cookie-cutter, sustaining generic process. Teams across the world try and achieve some form of efficiency in their processes and try to leverage this process the next time around in the hope of standardizing.

Can this dream of one process for a specific product development / deployment be achieved? The answer everyone wants to hear is "YES". The answer that is realistic is "MAYBE".

And here is why - when teams are formed to create a standardised process they look at their existing value-chain. They put in the thought of how will a standard process function across this value-chain, look at the various parameters and stakeholders and X-weeks later produce a generic process. This process will continue to function in its self if that was the only process in the world! The fact of the matter is it is not. And therefore the troubles begin because your customer wants you to provide the data in a different format or there is a new law that requires that when you manufacture in China and Ship-To UK you need to have 7.5% VAT etc. etc. This is when you break your Sustaining Generic Process.

So how do you achieve a more sustaining generic process? You step out of your realm and look at the overall process first in your department, then your overall organization and then in the industry segment that you operate in. Visualize and evaluate various options that can impact your processes based on the industry maturity and experience and then design a process. Take the Banking Industry as an example - the processes are standardized, cookie-cutter to a very very large extent irrespective of the bank you are dealing with.

So, the next time around you sit with your team to design a sustaining generic process, look at the complete picture, think out of the box and put something that will catapult your organization to the top in your industry segment. Think about it!

Can't and How

A usual work day across the world, deadlines, issues, concerns etc. etc. We are always battling these with teams, users, customers and so on. What I have seen is whenever there is a paradigm shift that is proposed for issues or for an action plan that calls for extremely tight timelines the usual answer is "It Can't be done".

Whenever I lead a team, I coach them to think a little differently and instead of saying "It Can't Be Done" they should say "How Can It Be Done".

The problem is saying "It Can't Be Done" is more than a statement - it limits one's ability to think beyond. People always forget - the human mind is capable of great things however we end up locking the capabilities by saying "It Can't be done".

As a leader, it is our responsibility to coach the team to think beyond their capability. How do you go about it? There is no cookie-cutter, one-size-fits-all methodology however what I have see that works is just pushing the team to think of a a more holistic picture of the problem and how the decision would impact the overall solution. This more-or-less gets the creative juices going because the team is at least made aware that by saying "It Can't Be Done" the impact to the overall solution is more greater than the problem at hand. The team begins to think on how to minimize the impact to the overall project and that is what it takes them to turn round the corner from "It Can't Be Done" to "How Can It Be Done".

So, the next time around, you are hit by an issue, before you accept "It Can't Be Done", ask yourself, how do I explain the bigger picture to the team because the solution is out there. Think about it.

The 3 Ws

Every project or activity at the workplace can be made a relatively easy task if the team is made to understand, articulate and help answer the "3 Ws". The 3 Ws are - "What needs to be done?", "Who will do it?" and "When will it get done?"

Look at a typical work plan either for a project, a release, or even a office move. There are tasks created in order to accomplish a goal. This is the answer to "What needs to be done?". We assign these tasks to someone. This is the answer to "Who will do it?". Then lastly we assign a timeline. This is the answer to "When will it get done"?

I see this happening on so many projects worldwide - these three questions are always looked at however they are not looked at simultaneously, in one meeting or in one workshop. This is what typically happens - a work session is held and the tasks identified (What needs to be done) and sometime later the plan is put together (When will this get done) and then the owners for these tasks are located (Who will do it). During all of this activity, the timeline gets squeezed, therefore the owners are not ready (The Who part is unanswered) and therefore some shortcuts are made (What needs to be done). This results in a perfect spaghetti of mis-matched tasks.

In order to have a perfect execution of a plan - I strongly recommend in looking at all these "W's" together. This not only brings forward all known risks and issues, it also helps get the team a head-start on the end-to-end vision.

The next time around, when you are making a strategic or a tactical plan, would you keep it high-level or go down to the details of the 3 W's because the devil is in the details? Think about it.

How resilient are you?

A typical work day for all of us involves working various issues - business, personnel, technical, financial and so on. We work those issues to the best of our ability and move on. We feel good about those resolved issues at the end of the day.

However, sometimes we hit a bump. One of the issue does not get resolved, gets into a legal mess, the press is involved and life becomes a nightmare.

This is where a true leader stands out and shows the true leadership qualities. How quickly a leader recovers from this mess and goes back to "another work day" mode shows strength in character and spirit. The leader's recover means the recovery of the team he / she is leading.

So how do you as a executive leader reach that point where you hit a huge-huge-huge issue and recover very quickly? I see that leaders usually are in a pattern of "Tell me what to do" or "Tell me what are my options" which basically puts them into a analysis-paralysis mode. Leaders, in my opinion, have two major knowledge streams - experience and on-the-job-education. They need to rely on both of these, solicit inputs and then go with their gut feel. As Jack Welch said - "Straight from the gut"

Leaders need to show and articulate their recovery plan and start working towards that very very quickly. Of course, there might need to be modifications to the plans as we move on however the plan needs to be published for all to see and comment. Leaders need to show how quickly they can lead their teams and companies to recover. Sometimes, the recover plan calls for hard and painful decisions. Remember what Lou Gerstner did to IBM? Made some hard and tough decisions, published his recover plan and executed to the plan. The result - a new and improved IBM cam out to play in the IT arena.

So, the next time a major issue hits you, are you going to ponder and ponder and think "Why Me?" or are you going to learn something from that and put a recover plan and recover and show how resilient are you. Think about it.

What's in a Name?

I see this happening in work places across the world. People remember names only when there is a designation associated with it. Have you ever wondered - do you name of the janitor who works on your office floor? What about the security card you met the other late evening who escorted you to your car in the parking lot? Do you remember him / her? Now, do you remember the VP you met in the elevator while you were going to your car? You remember his / her name right?

If the answer was YES then you are missing out on a major network that the executive work-force relies on - speaking to the janitors / cleaners / clerks / guards etc. etc.

This is what happens in the corporate world - there is a large web of reference networks that take place where your skills are referred to and you get a job but it is the "other" network that helps you grow in an organization. Think about it like this - if you need some face time with the CEO you better be nice to the Admin assistant sitting outside the CEO's office. She will tell you when the CEO is leaving to get into the car so that you can "accidentally bump into the CEO" in the elevator.

This is the story - the person who stops by your office to pick up the trash also stops by the VP's office to pick the trash. The VP relies on networking with the right folks at the right time. He / She asks the janitor his name and then next time on always speaks to him with his name, asking him how he is doing and so on.

So the story goes that one day the janitor tells the VP that he just picked up trash in your office and you were in a bad mood and yelling on the phone. You just blew that promotion because you, one, did not ever talk to the janitor, and two, you forgot the basic courtesy of greeting the janitor using his name.

So, the next time around, you see the janitor or the cleaner or the guard, take a minute to talk to him / her and help them help you. What's in a name you ask? Plenty I say. Think about it.

What went wrong?

How many times have you sat back and wondered at work - what did the team do wrong? Once you are done with collecting your thoughts you think it is time to get together with the team and have a "Lessons Learned Session". That is when things start to get messy.

So how do you go about telling someone that they made a mistake? There are multiple ways - the obvious ones are to tell the individual / team on their face. But what does that get you? In my opinion, this is the worst way to communicate and highlight a mistake.

I have seen this happening again and again, in various companies across the world - the Lessons Learned sessions are usually held after the project has gone live. The issue does not end there - the lessons are just documented and not learnt or implemented in the next project. But that is another topic all together.

So back to the fundamental question - how do you communicate hard-facts?

I have seen this work - Take the complete team offsite. Before the team lands offsite, set the agenda and the expectations on the objective of the offsite session so that the individuals can be prepared to have constructive discussion and are focused. Also, set the ground-rules that NEVER criticize the individual. Also, NEVER use the word "ALWAYS" !

Once the ground rules are set, lead the team in identifying the project items in 3 categories -
- What went good and should be repeated everytime
- What can be done better
- Never do this ever again

As a leader I see that quite a number of times, team-leads acknowledge the "Never do this ever again" however they do not celebrate the "What went good and should be repeated everytime" part of their deliverable.

Also, I see this happening everywhere - we do not communicate the good and the bad learning's at regular intervals. We usually save this activity to the end of the project. I feel that doing this as a regular activity specifically for long term projects is beneficial because it gives time to the team to learn and act therefore the leader is able to harvest the learning's on the current project itself.

So, the next time around, you tell someone "I always need to massage the data that you give me", are you criticizing the data or the individual - think about it !