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.

QA Perceptions or end user needs

During the software development process, we come across situations where the team would brainstorm on how the end use would use a particular feature, or the steps the end user would do to get a certain task accomplished.  In most of the cases these small details cannot be validated with the customers. In such instances, The Developers take help of the QA personal (as an end user representative). Often the QA team has a different perception as against the developers. Then usually the Implementation happens in accordance with the QA recommendations.  

 

I tend to wonder these days, if we are developing the product according to the QA Team members’ perceptions or what the end user requires