Do Auto executives make good software managers? - My experience

Do auto executives make better software industry managers? My top 3 reasons -

I counducted an inteview of a candidate for a software startup and the inteviewee asked me about where he could get more information on "lean", and today in Economic Times I saw an article on Wipro adopting Lean

Toyota’s lean lessons for Wipro - ET Slide Shows - Features - The Economic Times

I worked for 3 years in Automotive with a (now) Deming company, prior to moving to Software consulting (aka body shops in their initial years). Here are my 3 reasons , why auto guys do well in software

1. Better people management skills:
I found that people from experience in Automotive were better at managing teams and quality than people bred in software (Not that they coded better - but had an eye to quality and managing people) - Googles Project Oxygen too rates being a good coach as being more important than tech skills (and typically you have lower number of people reporting and a deeper hierarchy in traditional automotive firms making them better managers)

2. A more evolved control and improve process (PDCA)
A company where I worked used a NPD process which had been with them for 15 years. When they launched an ERP system, they adopted the NPD process for software, introducing similar phase-gates, and did a very effective deployment (Similar to a waterfall for Software development). They used simple tools to foster execution , such as daily morning meetings to foster communication such as on the shop floor, daily task lists and risk sign-offs.
One friend of mine was from a heavy engineering project management company and came to lead the quality group of an IT Retail sector consulting firm . He brought and implemented online tools to track project health, risk and developed job times similar to Industrial-engineering-time-and-motion study. Result -  significant cost reductions and quality improvement in the software deliveries.

3. Greater ownership of results
Typically software firms "Ship" the product and support is by far online and remote. Ownership is by Third-parties. In an automotive context, given high investments and legal requirements to support the products for 7+ years, most teams are interested in "real performance" over the need to "Ship by a date!"

Share

Subscribe to A.Karthiks blog

Part 2 : Checklist manifesto If you do read it, watch these videos too

If you read the book Checklist manifesto, do see these 2 videos

HOW NOT TO USE A CHECKLIST -


HOW TO USE A CHECKLIST -





My review of the book: Part 1

Share

Subscribe to A.Karthiks blog

The 80-20 rule: Can we explain this using physical phenomenon

We have all experienced the 80 20 rule. I am reading the book by Richard Koch - 80/20 principle and wondered, while there is a lot of merit in 20% causes resulting in 80% of the results, can we explain this relatively statistical empirical phenomenon.

We have always known that nature is balanced to a point of equilibrium by a minimum (simplified) natural forces. There are countless examples - Yin and yang, Demand and Supply curves and so on.

In business too, we are familiar with matrices that we use to balance and prioritise. Examples, effort Vs return matrix, marketshare vs. customers. As one guru once said, any matrix is useful if one of the axis is a representation of necessity and the other axis is a representation of achievability.

This is where my theory comes in to say that result is always at minimum a quadratic ,and where there are more than 2 forces a multi-variate. This explains the non-linearity and the 80-20 principle or the 4-64 principles.

While post-facto this physical explanation of the 80-20 principle seems simplistic, I see it explaining the reason to use the 80-20 with care especially in identifying relationships and underlying causal forces

Share

Subscribe to A.Karthiks blog

Branding the key metrics: Making metrics stick

Most change management programs and PMO struggle to deliver key metrics to senior management because of poor traction with operating and senior management.

To make a metrics program successful, the 1 or 2 (at most) reports should be branded with a name. Branding and retaining the key metrics into a report say Q25 or T20 or 9box , enables recall and drives continuity to a changing/improving set of metrics.

Further, this can also be incorporated into training programs / presentations at all levels to ensure importance and recall. A generic non-branded report such as a project report can easily be abused / modified and mis-understood diluting the needs of project reporting.

Program Metrics Dashboard design guidelines: 10 useful guidelines from experience

I have been experimenting with some metrics design dashboards for pipeline tracking of programs. I have used these guidelines and tricks

1. Keep it simple - the chances of making a super heavy dashboard is high - stick to fixed number of metrics (You want to add something, You have to delete something! - crude but effectie rule)

2. Let users use an excel sheet or a web page - dont make them use a complex database

3. Make users fill directly into a dashboard like page - that way they know how it will look rather than them filling a form and you creating a dashboard. This also provides them instant feedback on performance

4. On most companies, poorly performing programs report far fewer metrics than better ones. [A symptom of what you dont measure you dont manage (I dont beleive that you manage by just measuring though)]. More in the "red" zone is a better sign than No metrics. REPORT % of metrics filled in your dashboard

5. Achieve balance - report on cost, quality, purchasing, sourcing, delivery , issues et al. Failing to achieve balance will scuttle all-round execution and delay programs.

6. Follow  some simple xls rules: Validate everything using Data Validation rules, Use input messages that are descriptive, use comments in xls, format each cell based on the input format you need, unlock entry cells and protect worksheets,Test with sample data before distributing! - It is much better to do all this before you get it to the programs than to send out a poorly validated set of measures dashboard

7. Use charts were possible to break monotony

8. Keep improving and standardizing - it is important to let users know where to look for what information.

9. Create a mapping file for creating a summary from all project xls files and load into access or any enterprise database that you have. It is improtant to archive both plans and actuals on the monthly or quarterly rates at which PMO collects information.

10. Create also a reverse mapped dashboard to generate any of the metrics dasboard reports from the database.

The negative spiral of poor process adherence.

Most companies are complaining of insufficient resources for the wrong reasons (I believe having more ideas and initiatives and hence no resources is a good scenario)

Short term

People want to do things fast (or atleast think they can) by short cutting processes. Poor process adherence (in intent) leads to poor quality and capability build up. This results in fires. Fires result in a surge in resource requirements. Sudden surges cant be met with external resources. They are met by redeployment from other processes and projects. By the time the problem is fixes, the other processes with poor resources are way behind schedules resulting in people want to things faster! - Indeed a fantastic negative spiral!

Long term

Further, in the long run, poor process adherence leads to no metrics and continuous improvement. Resulting in poor capability buildup (and inflexibility). This results in poor business efficiencies and results. This leads to fires and patchwork.

This is probably the only real reason to create and execute to processes even at the risk of first time being a little late - The net result will always be better than getting into the negative spiral

The process vs. experience paradigm: Establishing the PMO and managing the change

Establishing the PMO ,especially a process for product introduction is a challenge. Any established company trying to establish a new process is "running the trains and laying the tracks" at the same time.
Any process that does not match with intuition (experience based) is discounted as a poor process. Similarly, any new process that does not throw new insights is also discounted as a heavy process for doing something intuitively or from experience. Hence, establishing benefit of a new process is balancing the fine line.
We have also heard common complaints that there is no spirit in the templates and deliverable. People are churning the wheels without the spirit - so what is the "spirit". There are also numerous form vs. content debates
A proposed methodology is
1. Fill the forms/templates/deliverable
2. Check with common sense, get feedback on the content from experts
3. Create a conclusion from the deliverable
4. Highlight issues and closure plans, force learning's from the team (and incorporate in process)

The benefit of the process is only if we can ramp-up learning and standardize across programs to get the benefits of experience standardized.

Every one of these steps must be orchestrated for key programs by the PMO. Hence, while PMO strives for training members on the deliverables, it is crucial to drive debate on the content and signoff on outputs.