Almost all service providers are generic and claim that they are able to deliver on a very wide range of technologies and domains. It is most likely true if a vendor claims to have a certain experience that matches your requirements and they will be able to produce engineers with the right skills. When you have found the right individuals you negotiate rates and the deal is done when you get a good price. This is not the best way to approach a nearshore outsourcing vendor. read more about it here: Selecting outsourcing partner is not a CV exercise

A discussion with a potential client the other day led to a talk on selection of service providers and more specifically how to compare cost. From a range of 6 potential suppliers the cost varied with over 30% looking on the stated daily rates. That is a significant spread over a rather small sample who are more or less from the same geographical regions, just outside the EU. How can that be and what do you need to know when looking at the cost?

This is the third article in a series, taking a look at Business Value and how to use it conceptually to improve the return on investment in software development projects. The two earlier can be found here: 3 Models for Quantifying Business Value in Agile Development and here: Thoughts on Value Based Governance in software projects

Any investment carries an amount of risk. In software development, unlike in the case of financial investments in a transparent market, it doesn’t follow the predictable pattern of high risk equalling high yield and vice versa. However, the one reason for the investment is the same. By investing, you desire to create greater values as a return.

I'm a passionate about the creation of results and I'm passionate about agile software development. My only reason for this is that I have learned that it can create better results than other methodologies, nothing else. Any new method that improve "Result Creation" will always be attractive to me but you need to look at the whole picture.

"Yes, we are running agile development"

The cultural environment that your firm has fostered has the greatest impact on your software development results. Time and again I meet firms with great software developers, individually strong and competent as few, still their software projects continue to fail. I have argued many times that selecting an outsourcing provider for software development is not a CV exercise, nor is it when you are going to hire people for your own teams.

Every day, every minute, I think of things that can be done better. Where can I improve? How could something be designed to serve a better purpose? What can be changed in order to shorten this queue? How should government, where agile is needed most of all, change their ways to increase service, but not cost. Agile is the way of relentlessly striving forward, making changes in small steps and every time look back and analyse what can be done better tomorrow. Am I different from anybody?

50% of outsourcing projects fail. Google it! Many of the enterprises who have outsourced big programmes are in fact struggling with the cost structure instead of enjoying its benefits. Despite the obvious cost advantage that an off-shore location can offer, the total cost of the development has not gone down to the levels that are even close to meet the original expectations. It is of course cheaper by the hour but, waste, unhappy customers, delays and quality problems add to the investment and simply seem to eat up all the savings and a bit more.

Business value keeps getting deluted when software projects move from business executives to the IT folks. The plan that underpinned the business case of the investment is unfortunately often washed out when translating into IT and features in a software. This is a critical error and it is not easy to correct if starting development without it. Here are 3 models that I think can be used in combination, each serving it own purpose in the planning process.

A very large portion of all software projects fail in some way. Budget overruns, delayed deployment and software projects that fail to deliver the intended value, are far to common. Reading Vin D'Amico's excellent blog post about failure for the wrong reasons, I think it's also important to look at the reaction, when it does. In projects where work is being outsourced it can be especially convenient to have someone else to blame for the failure. What should you do when failure is seeping up from the cracks? Who do you blame and why?