LEAN Behaviors

We keep talking about culture change when we refer to lean. In fact it's an attitude change.

I call it Lean Behavior.

 

Here are some differences in attitude between the Traditional thinking and lean thinking. Lean thinking is very optimistic. It engages people fully. They feel appreciated and trusted. Inner resources surface and motivation is strong.  They keep looking even more fervently how to get rid of waste that eats away at their wealth.

 

We’ve never done it before _____ We’ll be the pioneers

It’s too complicated ___ Let’s look at it from a different angle

We don’t have the resources ___ Necessity is the Mother of Invention

It will never work ______ Let’s give it a try

There-s not enough time _____ We’ll reevaluate our priorities

We already tried it _______ We learned from the experience

There’s no way it will work _____ We will make it work

It’s a waste of time ______ Think of the possibilities

It’s of waste of money _______ The investment will be worth it

We don’t have the expertise _______ We’ll benchmark those that do

We can’t compete ________ We’ll get a jump on the competition

Our vendors won’t go for it ____ Let’s show them the opportunities

It’s good enough ________ There’s always room for improvement

We don’t have the money __________ Can we afford not to?

We’re understaffed _____________ We are a lean machine

We don’t have the room _______ We better organize our space

It will never fly __________ We’ll never know until we try

We don’t have the equipment ______ Can the equipment be rented?

It’s not going to be any better ______ We’ll try it one more time

No one communicates _________ Let’s open the channels

Isn’t it time to go home? _____ Days go so quickly around here!

I don’t have any idea _______ I’ll come up with some alternatives

Let someone else deal with it ____ I’m ready to learn something new

It’s too radical a change _______ Let’s take a chance

It takes too long to approve _____ We’ll walk it through the system

Our customers won’t buy it _______ We’ll explain the benefits

It’s not my job ____ I’ll be glad to take the responsibility

 

I CAN’T ________________________ I CAN

 

 

 And that is lean thinking.

 

I picked this up from here:

http://www.implement-lean-manufacturing.com/lean-thinking.html

 

 

Lean Thinking

The image and metaphor we like to convey a key thinking mistake and opportunity is the sport of relay racing.

 

Consider the relay racers standing around waiting for the baton from their running colleague. The accountant in the finance department, looking aghast at this terrible underutilization ‘waste’ indicated in some report, would probably mandate a policy goal of “95% utilization of resources” to ensure all the racers are busy and ‘productive.’ Maybe—he suggests—the runners could run three races at the same time to increase “resource utilization,” or run up a mountain while waiting.

 

Funny…but this kind of thinking lies behind much of traditional management and processes in development and other domains.

 

Of course, in contrast, here is a central idea in lean thinking: Watch the baton, not the runners

Results

Results… are the outcome of a process. What we want are good results from a controlled process because they will be repeatable. Bad results from an uncontrolled process simply mean that we’re not doing our job. Good results from an uncontrolled process…only mean we’re lucky. Today, a bad result from a controlled process just says that we’re stupid: We expect different results from doing the same thing over again.

Four Men

It chanced upon a winter's night, Safe sheltered from the weather,
The board was spread for only one, yet four men dined together.
There sat the man I meant to be In glory spurred and booted.
And close beside him to the right The Man I am reputed.
The Man I thought myself to be his seat was occupying,
Hard by the man I really am who to hold his own was trying.
And all beneath one roof we met, yet none called his fellow brother,
No sign of recognition passed ... They knew not one another.

 

… Author Unknown

Product Transitions or problem transitions

As a PM responsible for enhancements or maintenance of a product, that has been recently acquired by your org. You need to think twice before making any commitments. During an acquisition, in most cases the potential revenue or profit that can be generated takes precedence over the technical or engineering aspects.

The engineering team gets to have a look at the product from under the hood, only when it gets transitioned, and they are proclaimed to be responsible for the same in the future.

 

It is the PM’s core responsibility to check on the following before making any commitments on maintenance or enhancements.

 

a) Ensure that all of the necessary source code and rights to use / modify the same is available

b) Ensure availability of engineering & User documents,

c) If any third party components are used, check that the required licenses are available and support contacts are established

d) Allow for the engineering team to look under the hood, and get a good grip on the same.

e) Allow for the QA team to check on the quality and confirm that behaves the way it was expected, or whatever is mentioned in the user guides and marketing brochures are actually true

e) There will be push from all stakeholders requesting for updated product with fixes or enhancements at the earliest.

f) Resist the temptation to make any commitments (wishful thinking never helps)

 

If you are pushed to commit, indicate all of the above as risks of high impact and shout as loudly as possible (in writing), it’s ok if nobody listens to you, as long as you have evidence that you did shout.

A Case for Reqmnts. Engg. Group

If Organizations have a Process Group, Program management Group, Systems engineering group… why not a Requirements engineering group.

 

If projects are subjected to Cost and schedule over runs, one of the top causes for the same can be attributed to Poor Scope definition. So is it not imperative that organizations give due importance towards Collecting requirements and Analyzing them. (Thus enabling successful projects)

 

This would require specific skills set which would include VOC collection, interviewing, facilitating brainstorming, negotiating, and knowledge on latest technical advancement. A bit of domain understanding would be an added advantage.

While the above set of skills are about collecting information, the next set of equal importance is about the ability to clearly communicate the same in written form.

This requires the understanding of different visual representation and appropriate use of such options which include, use case scenarios, flow or process diagrams, sequence diagrams, data dictionaries etc.

Topics for Articles

Planning to write two articles in the next few weeks,

 

The first one will be about “managing Integration Projects” This would be based on experiences related to a) Projects involving procurement of a Sub-component or service from an external vendor, b) Joint development with external organizations or vendors as part of a larger solution or c) multi-site development for a software product.

 

The Second one will be about the “importance of scope definition”. Attributing most of the Quality problems in software to poor scope definition. I will discuss on the reasons for poor clarity on scope, or the difficulties associated with capturing the scope, and what can a PM do to address such scenarios.