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

A mathematical model: Why are large organizations slow to change and how to make them faster

SIZE DOES MATTER!

Recently, in a meeting, a person mentioned that the organizations are like a sliced pizza. Each slice a function or a business. We were discussing change management and he said that any change that cuts across all the groups (of a delta r) would have a change impact of r-squared.

Not quite, as I thought about the problem he had made a mistake, the impact is more 2*pi*r*delta r. However, the mistake was not quite as important as the corollary on organizational change management.

A large organization is like a large pizza. Trying to make a change is directly proportional to the size of the organization (2*r*delta r where r is representative of size). Well, it is mathematically proven that elephants can't dance.....

Well, while we discussed the same, we were also quoting the example of a smaller BU that had implemented the same change and was very successful. Mathematically, all that the BU had done was to reduce 'r' and hence made it easier to provide the 2*r*delta r change!!!

While it looks simplistic and too obvious, its rather rare that a lack-lustre meeting with an analogy can provide this practical insight! (Its also shows that meetings close to lunch time can provide better time for introspection!)

Share

Subscribe to A.Karthiks blog

A practical 3 step approach to kicking off programs in different Business Units (BUs)

Okay, your company has committed to a PMO and has agreed formally or informally to the overhead. Having implemented in a BU, senior leadership is finding it useful and wants to rapidly expand the matrix organization.

Programs are kicked in different BUs and PMO is asked to sync them up and run them up to a common process. While the tactics may vary  from organization to organization (As there are different types of PMOs) , my experience is that it is possible to classify actions into just 3 broad steps

1. Setup Governance
2. Establish Teaming
3. Sign-off on portfolio/program scope [Not the project scope which is usually part of the Project itself]

What do I mean by this?
1. Setup governance - Getting the sponsor and resource managers to agree about project objectives and agree to review the same (together is important). Setting up a chair to resolve conflict if there is disagreement and agree on time commitments/schedules for reviews

2. Establish Teaming - Getting atleast the PM nominated (who will then estimate and track resources)

3. Sign-off on program scope - especially important as there will be a lot which will not be covered in the first pilot . Important to say what will not be in the new process


While there is a lot of verbose documentation on how to setup programs and follow a standard process, I feel that this is a kind of jumpstart guide (3 steps) to PMO nirvana rather than stall and run in circles in a large organization. Communicating this to executive management and getting their buy in is also easier.(Most of it is their intervention in these tasks)

References of some links on PMO setup
http://www.qaiglobal.com/downloads/Internal-PMO.pdf
http://www.projexc.com/pmo-set-up.html (Talks of a parts but not quite the steps)

Share

Subscribe to A.Karthiks blog

Challenges in moving to a project matrix organizations: People change management

Changing organization structures from a deep functional to a project matrix, involves substantial challenges in people management. There are  broad guidelines that may be useful 

1. Keep the end in mind - very often it is "courses for horses". You do fit your organization to the best people you have, period. Hence, neither your organization structure nor your role definitions for the new structure will be perfect. It is critical to identify what are the 1~2 items that you will NOT compromise [ Example, when establishing a program management organization, having it function neutral may be a critical rule. You can still accommodate people and new structures , provided you stick to this broad rule]
2. Changes have to be enforced once decided. There are 3 techniques - most textbooks talk of just two to handle the resistance to change
   

• (a) Carrot - make people comfortable and show them the possible growth paths/career plan in the new structure
  
• (b) Stick - make organizational compliance mandatory. Preached easily, but difficult to practice with your best guys
  
• (c) Inaction! or wait - Several fears arise due to fear of the unknown. In any change management effort, the only way to overcome this residual fear, is not by more written definitions, but often , by pushing the people into their new waters and waiting for them to settle down. [For those of you who have travelled by Indian Railways, passengers are finicky and fight for their seats only till the train starts. For the next 6-10 or 24 hrs they all settle down into well oiled positions without any external intervention. This is probably cultural, but then thats what change management is all about!!]
  

These may sound simplistic, but having a gameplan like this in mind and also documenting the new org structure, rules and approaches help to improve on a continuous basis.