It is easy to understand why: very often, the quality of delivered software is far below par, regardless of where it has been built- in house or outsourced. At the same time, software is everywhere and especially, in those areas where ‘Quality of Operation’ is crucial. Therefore quality should have become the norm by now, but it hasn’t.
For ISV’s that are in existence purely because of their software products, this can become a true deal breaker. More often than not, it has brought companies to their knees of existence.
Without suggesting being complete or exhaustive just yet, there are certain interesting observations that I would like to share on why quality is low so often. As with many other situations, the whole is greater than the sum of the parts.
Everything just fell in place
In one of my previous posts on why focusing on details is important in software offshoring, I made a comparison to sports. Even now, it serves as a good metaphor. When a sportsperson who has just delivered a top performance is asked how he made it possible, often he answers on the lines of: ‘Everything just fell in place’. Achieving the same seemingly herculean task depends on every aspect being top-notch and favorable. It’s not in just the training methods or the weather, but also the material, and perhaps even some personal circumstances that provided a driving force for him to succeed. The training methods may not differ from last year, but somehow, there were small changes made that pulled everything together and created a favorable situation for victory and success.
After all, it is all in the details.
So what about software solutions?
Coming back to software development, there are interesting comparisons to make.
Before delving into more detail, one point should be made: the field of software development is actually only entering the early stages of maturity. Early project and process methodologies simply did not fit because software development is both a creative, engineering type of process as well as a production process at the same time. We have only recently started to realize what that means and have it reflected in the methodologies applied. It is therefore obvious that focus on these methodologies to better quality increases proportionately. .
However, there are still other factors to become attentive towards.
It makes a difference whether you are a startup, or an established company.
It makes a difference whether the product is new or old.
It makes a difference how the product is being used and also where- in a well established market or an emerging market.
And what about the people and the team? The best programmer might not be able to perform at all in a highly competitive environment, if not guided well, or assigned to the right team
And regarding the culture- a company when growing would start expanding to different locations and even geographies. What does it mean for quality? Sure, having everybody in one room is nice and cozy, and it probably is the most optimal situation, but it just is not possible always.
In the end, it is up to the leader of a company to put the right ingredients together and in the right quantities and boil a good soup out of it.
Some of the important ingredients which should always be viewed as interrelated parts are listed below. This, by the way is also important when looking to outsource/offshore. It should never be a separate item in the generic discussion on quality, but an integral part of it. There are many companies that have done this right and they do not have any quality issues in their software, not even when offshored.
The areas that I would like to go into more detail on with respect to how they are interrelated with each other in relation to quality in my next blogs on this topic are:
- Company Life cycle and Product Life Cycle (not the same!)
- The type of product, and what it means for the organization
- Software Development Methodologies and tooling
- Knowledge Management
- People, Team and Cultural aspects
- Market Dynamics
- Leadership and how small mistakes can have big consequences
- Governance aspects, especially in offshore product development type of situations
I’m sure that there are more, so do let me know if you’d like to add more to the list.
It’s all about assembled software solutions
To conclude for now, let me bring in a possible controversial statement.
Although for an ISV it is often said that its core competency should be focused around how to build software, I think that in today’s world, where everything changes at the speed of light, the core competency of ISV’s should not be limited to just that.
Instead it should be possessing the ability and leadership quality to be the spider in the web.
It should be focused around understanding the market dynamics and being able to create an ecosystem that is highly efficient at making (assembling, if you will) the best software solutions for that market so that in the end, the whole (including quality) is greater then the sum of the parts because quality is all about the sum.
Leadership decisions are critical in making the right choice and sometimes that choice can even be to not do everything yourself.