Role of the program in issue resolution: Project Management

Several times I had been told that the role of the program is to keep the ball rolling on tasks, and this meant little to me.

In a matrix organization, a key role of the functions is functional excellence. Several times, each functional member raises issues on other groups and the response to this issue by another group is usually a solution

Wrong!

The response to the issue by another group is another problem - rarely a solution.  Each functional team has what is often labelled as professional ego and it hurts to change their pas

Example, I need to fit this part and need 10 mm clearance. You have only 2 mm. Answer from a mating part group, even if I change you will have 3 mm besides I cant change it as it costs too much.

In most non-program situations, the conversation stalls here and in a muddle of competing tasks, functions move to easier tasks (not necessarily important). Often times, the issue gets resolved after long periods of inaction in a kind-of batch mode resulting in delays.

It requires a program team to get the experts together and strike a bargain with a unifying metric - the customer requirements - to move the program forward.

This is probably the key value add from program teams.

Share

Subscribe to A.Karthiks blog

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