Welcome! to my world..

I was reading a blog on the above topic and the blogger expressed his opinion that probably one of the best way to handle the OPD is to make the vendor responsible for the outcome rather than the output. I respectfully disagree.

Product Engineering or OPD is close to home for me; I play two roles in my day to day work, as supplier/vendor and Product Owner. The company I work with, BlastAsia Inc. primary focus is OPD for mid-size companies from world over, we have been doing this since later part of 2004, and for clients from about eight countries world over in 2008. In addition we are also involved in building our own business solution suite under BlastSuites product line.

The notion of ‘outcome’ based engagement model is unreal to me and perhaps most in the industry would agree. I do understand the repeated failure of software engagement raises the question of how to tame this monster. But I am sure the answer is not in throwing the requirement booklet over the wall to the vendor and waiting for them to come back with a beautiful outcome.

Let’s look into the few key causes of failure in software project, in terms of failure to produce the ROI:

1. Incapable developers or miss-match of skill to required capability; bad engineering practice, immature coding practice, lack of quality control etc.
2. Unclear or Continuous changing requirement and uncontrolled change management process
3. Rigid project management practice focusing more on delivering contract over business requirement
4. Product concept mismatch with the market, irrelevant, too early or too late thus there are not enough  takers

If the reason is the first point, then no matter what process and engagement model you go for the result would be crappy. If it’s a fixed priced contract like most are now a days, you run the risk of the 3^rd kind, you get what you asked for exactly and nothing more, considering in software requirement is never written in stone and progressively the requirement keeps changing, if the PM is successful the projects business outcome will be a failure in most cases. If the engagement is ‘outcome’ based, we are letting the vendor middle with your business model and concept, considering the 4^th point. This can get very messy if you understand what I mean.

Now to my recommended solution, what lot of progressive companies in the world has realized to face the issue head-on by defining the roles and responsibilities more clearly. Lean Agile development has come out as the option for Nokia, Siemen, google, amazon and hundreds or other bigger and many smaller companies have adapted to.

Scrum defines the role of product owner more clearly and is the person in-charge of ROI on the investment. The development team, in-house or outsourced focuses on delivering the items on the priority list as defined by product owner in time-boxed iterations, however each sprint output is complete and shippable meeting the quality standards and definition of done as agreed upon.

Thus my take on the issue without making this thread too long is to adapt a transparent, shared but clear role and responsibility in a lean and agile development methodology. Let the business people focus on business model and requirements and let the developers focus on delivering best quality software from coding point of view. Where does the outsourcing providers fit in, as partners to the product companies thus providing them best quality of engineering at a fast and adaptable pace to meet the market requirements; wait a minute isn’t this what is happening with manufacturing, plants in China building to the product specifications of US and European companies.

- Sept 2009