Innovation with SOA and R&D, Business Perceptions and Engineering Challenges

There I was sitting in a meeting with business stake holders discussing on the next set of deliverables for a new product we have been developing for the past five months. This is a project I am involved with new business development in my company. To give a brief background, we are developing a retail reward system that is both hardware and software based. We have two dedicated teams, one for business and one for technology. The teams are small and focused on getting this done with the shortest possible time.

My this post is not on developing new product but about the relationship between the business teams and technical teams on driving the product development. As with any new product development we have fewer resources, more complex problems and tighter deadlines.

As with any new innovation project, the challenge I face everyday in the project is the uncertainty involved in solving complex engineering and technology issues. Historically in our company business for the most of the time has been dealing only with software projects, even those projects were most of the time limited to the scope of enhancing our existing applications or trans migrating our existing applications.

This product I am working on now is unique in the sense that it has hardware development and software development. As we are going through the development phases I see a expectations gap between the business and the engineering team. The complexity involved in the engineering solutions is seldom reflected in the perception of the business for a particular business requirement.

The core concern of the business is its ROI on the project and the delivery schedule. While the concerns are legitimate the problem is the expectations arising out of them are not rooted in reality. The biggest gap I see in this issue is the concept of risk management. While businesses are within their rights to demand the ROI which includes the business requirements and delivery time, as with any business investments they should also realize that they are taking up risk in their investment expecting a higher return.

When this uncertainty in engineering and technical challenges or in other words the risk in the project is brought up to the table in the form of prototype testing, tighter scoping of the business requirements, avoiding complexity by eliminating scope creep etc., business gets rattled.

We see in many blogs in EAI space the importance of ROI, especially in the BPM and SOA space we see arguments forcefully made to sell the SOA project to the business with relevant ROI. Many SOA proponents advocate that the SOA practitioner do that job of selling the project to Business with ROI. Doing this I see an agency conflict.Since it is in the benefit of the SOA practitioner to sell his goods he is going to underplay the risk involved in the project, which many times translates to direct costs in the form of change management, process correction and the need for outside resources in the form of outsourcing.

So how do we attack this gap in the Business perception of engineering challenges and bring to the table the Real Risk in ROI presented for the project. Looking through my spyglass I see some answers in financial management theory. In the CAPM model the expected rate of return for any investment takes into account the risk free return, the risk premium for the investment and the market sensitivity factor.

In our case applying the CAPM model to SOA or R&D projects we should factor in the historic success rate of IT projects in the enterprise, the risk premium associated with attempting new technology and the industry success rate for projects of similar nature (if available) for the ROI calculation . When a dialog on ROI is based on this framework, the risk factor is automatically included in the dialog and should address the gap in engineering challenges and business perceptions about it. I would welcome feedback on any other the ways to bring to the table the risk factor.

In conclusion it is not about IT department showcasing ROI of SOA, IT or R&D projects that leads to business alignment, rather it is about what kind of ROI we present and what type of dialog it initiates in the business about the project. A ROI rooted in the reality of what is the risk associated with the project and what is the expected rate of return for the business it provides will decide the true business alignment.