Friday, May 28, 2010

Is Supplier Risk Management “nice-to-have”?

We recently built a supplier risk management enterprise solution for implementation as a software as a service (SaaS) business model. The solution was architected based on inputs from various practitioners and domain experts in the industry as well as personal experiences in managing global suppliers in both large and small enterprises. It received many accolades and good reviews. However, we noticed that many companies had tough time justifying the budget for implementation of a supplier risk solution. Frequently, there are other more urgent priorities competing for the same budget. Some organizations tend to view Supplier Scorecard or Supplier Risk Management solutions as “nice-to-have” rather than a critical part of the enterprise operation. I beg to differ. Investment in risk management is somewhat like buying an insurance policy except it is much more critical. An insurance policy is primarily used for reactive or defensive purposes, whereas supplier risk management can be used much more proactively. Consider the recent examples of failures in supplier risk management in widely different industries:

Toyota’s failure in managing the supplier of braking systems (CTS Corp) that led to massive auto recall
Apple’s failure in managing Chinese suppliers (Foxconn) that violated corporate social responsibility obligations
BP’s failure in adequately managing subcontractors (such as Halliburton) for the offshore drilling platform leading to world's worst oil spill

In each case proactive management of supplier risk should have highlighted the danger so that mitigating actions could have been taken before it was too late. No amount of insurance could have provided as much benefit as an appropriate level of investment in supplier risk management. Typically, the investment required for managing supplier risk would have been just a small fraction of the insurance premium. Thus, in an increasingly inter-dependent enterprise that is constantly looking for operational efficiencies by outsourcing non-core functions, investment in supplier risk management cannot be over-emphasized. Is this the hazard of the “flat” world?

Tuesday, May 18, 2010

Is it Agile or Waterfall?

Quite often we have heard companies say that they are using Agile product development, but when we get into a discussion of their product development velocity or when I ask them how frequently they release their product, we uncover that the typical new releases take 8- 12 months or longer. Moreover, the release dates are not very predictable causing a lot of turmoil in the organization including customer dissatisfaction. This type of product development is closer to traditional “Stage Gate” or “Waterfall” development process. A true adoption of agile development framework will result in a significantly faster development cycle with more predictable and frequent product releases.
I started using agile methodology in late-1990s at HP. We used to call it "Evolutionary" product development as compared to the traditional "Waterfall" product development. We have had many successful product launches using this approach. Since then I have become a firm believer in the organized Agile product development process proposed by Scrum Alliance ( Time and again the Agile process has proven its merit to me by accelerating the development process and more importantly, by making the process more predictable while delivering a higher quality end product that is better aligned with the market requirements.

As indicated in the Manifesto for Agile Software Development (, a true Agile process must emphasize

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile process delivers product functionality through frequent iterations (also called scrums). Large product features or requirements are developed over multiple iterations with each iteration involving a small vertical slice of the overall functionality. The requirements are fixed within an iteration or scrum but can change for a future iteration as the particular iteration is planned. The duration of an iteration or scrum can be anywhere between 1 – 4 weeks.

The traditional “Waterfall” approach specifically focuses on proper documentation and attempts to adhere to the documented plans and processes. As a result, the Waterfall process discourages changes in the product requirements once a major development effort has started. Unfortunately, in reality, the product requirement can change significantly based on more refined market data. This is particularly true for the longer development cycle. By the time the product is released at the end of an 8-12 month development cycle the market requirements are likely to have shifted in many fast changing industries.

Transition of a product development organization to Agile product development from a legacy Waterfall process is so radical that it cannot really be implemented partially. A firm executive-level commitment to change is essential. This makes the decision to adopt the agile methods as the most important step in implementing Agile development process. It requires a bold leadership that can act as a change agent and is willing to risk short-term setback to position the organization for a dramatic improvement in the product development efficiency. While proposing Agile methods it is important to emphasize the value of adopting Agile product development. The business users and executives are more interested in the business benefits than a religious debate about "Agile" versus "Waterfall".

Once properly implemented, the Agile development process provides more flexibility, more predictable development schedule, greater visibility into the release process and improved product quality. I hope to elaborate this in future from the perspective of a Product Manager, commonly called a “Product Owner” in the Agile parlance.

Friday, May 14, 2010

Back to Blogging!

It has been a long time since I have done any serious blogging in these pages. I have many excuses. I have been busy. In personal life sandwiched between taking care of my father and our two boys. In professional life sandwiched between my new passion of managing exciting products in Supplier Information Management (SIM) and serving the professional supply management community.

I have been taking care of both my parents for over 25 year. My mother passed away after prolonged illness in February 2008. During the last few years of her life, my father was also shouldering considerable burden of taking care of her as she was getting increasingly weaker and bed bound. I miss my mom more now than when she was suffering from her incurable disease. While she was alive, the very fact that she was around was comforting even though she was very much dependent on others due to her illness for most of my life (since I was about 2 year old).

Within a few months of mother’s death my father was diagnosed of having Parkinson’s disease. This was a major shocker. We were so focused on mom’s well being that we probably neglected his health. He also ignored the symptoms of Parkinson’s. I am fortunate that I was able to take some time off from work and clear my head. I also took a mini vacation with him and visited Indiana. He really wanted to visit India but settled for Indiana and visited my aunt's family.

During my travels, I started reading "Always Looking up: The Adventures of an Incurable Optimist" by Michael J. Fox. It is a book based on acclaimed actor’s personal experience with Parkinson's disease. It gave me a better appreciation about life and also what my father may be going through. Recently, Atlantic Magazine published a son’s tragic story of coping with father’s Parkinson’s disease. It touched me particularly hard as I struggle with my dad’s rapidly declining health due to the same disease. “Letting Go of My Father”, The Atlantic Magazine, April 2010.

I hereby make a personal resolution about bringing more balance into my personal and professional life. While doing so, I hope to blog more often in the coming days.