I recall facing this question myself five years ago, when I accepted the assignment to roll out an improvement programme on a 150+ IT services company. At the time it seemed to me a few months assignment which ends when "we write down our processes and then get CMMI certified". What a simplistic, foolish view! Now I wish I could give some advice to the younger me… however, since that"s not possible, it may make sense sharing some lessons learned along the way - sometimes the hard way - hoping that someone else will benefit from them.
What happened during the past 5 years was not only a learning experience but a complete change of mind-set with regards to quality and continuous improvement, thanks to the great people who guided and mentored me in this. In reality, this quest turned out to require 5 years of hard work, serious commitment not to give up and eventually changing the mind-set and the overall way of working in the organisation. Such programmes are no easy job. They are intrusive, hard to predict and often seen as "messing up" the normal way of doing things. So the question is normal: "Why bother?"
Also, during the past few years I learned that there are many IT persons - engineers and managers as well, in small and large organisations, who are now asking the same question: "Why bother?" They are not asking this with the same words, of course, but with the same idea, with variations like:
"Things worked well so far, why change?"
"We do not want to get ISO nor CMMI certified, so what"s the point?"
"We are a small company, we hate corporate thinking, and these things are not for us."
"We have no time this year, maybe next time."
"Why spend money on this, instead we"ll hire two more coders."
"We have been working on processes and nothing changed."
"Someone else tried and failed."
"We tried and failed."
…and the list goes on.
Sometimes the answer comes from prospects or customers who are only willing to partner with companies that can prove a certain level of maturity. This can basically trigger one of the two reactions: either (1) finding shortcuts to get that certificate, or (2) making an investment and optimise it in order to maximise the returns. Luckily, the majority of managers would choose for the latter, but the scale of the other group is significant nonetheless.
But the prospects (or customers) asking for such a proof of maturity are rarely interested in a "rubber-stamp" alone. They are interested in knowing that those bright success stories on our webpages can be repeated. They want to see that they have been analysed, their main ingredients for success are identified and available for future projects to be done together. This is a matter of key importance for the Central- and East-European IT companies. There is always someone out there offering the same services cheaper, or faster, or both. Therefore, the only chance we have to remain competitive in a crowded, volatile IT services market with global competition is through demonstrated and continuously improved quality. Quality that is not only plainly stated in our tagline. Quality that first needs to be DEFINED, then it needs to be MEASURED and DEMONSTRATED, finally, it also needs to be visibly IMPROVED in time. This is not achievable in a brainstorming meeting. This is achievable with improvement programmes that require both commitment and investment.
The term "Quality Assurance" has a meaning much broader than we are used to, beyond testing, beyond Quality Control. The existence of a QA system can make a significant difference in the organisation. There is a common misconception about QA: in the vast majority of the cases QA is considered to be fulfilled by test engineers in a team. Even worse, they are often referred to as "the QA"s" who are not part of the development team, instead they test the results with a delay of a full iteration. Actually testing activities are part of QC (Quality Control) within the development lifecycle, checking the products/services that have been produced.
QA is more important: it means ensuring quality of the products and services that are going to be produced and delivered. The difference is huge. Just as an example, QA also includes review activities, which are able to detect 8-10 times more defects than testing in the same time unit. It facilitates the reuse of experience, measurements and know-how, for instance increasing the estimation accuracy. QA checks that the people doing the work understand what they are supposed to be doing and are using the best practices. It verifies that measurement and reporting is done efficiently. This leads to more accurate planning and the list goes on.
Any effort, time and money put in continuous improvement programmes must be considered an investment rather than a cost. And you should expect a significant ROI. Yes, an investment is needed; change requires time and money. So, most of the various corner-cutting mechanisms that exist do not lead to success; they do the opposite and turn the investment into a cost, a waste of time and money that will never be recovered. Some such approaches may include:
Just do it! - without training, without support, without vision nor a plan,
Buy a miracle tool that will sort it all out,
Buy the processes of someone else,
Have someone write the processes (preferably by next Monday),
Invent new processes,
Have the same person(s) responsible for defining, measuring, implementing and evaluating their own work and results.
With a correct, healthy approach, however, significant optimisation is possible. Improvement programmes themselves can be optimised for minimising the investment and maximising the returns through some simple principles:
Start from the way things are done currently (improvement, not invention),
Document existing practices and identify bottlenecks,
Focus on what is important for the organisation,
Collect and analyse relevant measurements, share them across the organisation,
Involve staff in defining the needs for improvement, while showing management commitment to it.
Get professional help to get started, get trainings and coaching!
So back to the original question - why bother with all these?
Because it facilitates the survival of the species called East-European IT Services Company, especially for the sub-species characterised by Outsourcing. Because the IT industry - and especially the outsourcing business - in our region is heavily challenged as competition gets global and the continuously increasing freelancer communities are becoming an affordable alternative. We must be able to demonstrate continuous improvement over time in order to not be eclipsed by competition.
Because it promotes the most powerful competitive advantage: Quality. While competition might offer cheaper and faster services, there is something hard to compete on: Quality. Have you ever seen an IT company claiming that they don"t deliver quality? Of course not. Everyone claims providing high quality products and services, and most of them do. But it is extremely difficult to explain its definition. Because the definition of quality - if it exists at all - often comes down to measuring time and money. So the natural question is: does that mean that cheap and fast means high quality? The truth is this is not an easy task: few companies are able to appropriately define, measure and improve their quality, and these details can make all the difference.
Because it reduces the heavy cost of reactive corrections such as fixing and rework. Implementing a proper QA system in the organisation ensures that "quality is not someone else"s business". It ensures that everyone contributes to it, instead of leaving it to "QA"s" to deal with. It ensures that the know-how and best practices are shared and made reusable. It ensures that measurements are collected and consolidated to statistical information, increasing the accuracy of future forecasts. It ensures that quality is engineered from the beginning of the process and investment in trainings and planning is not wasted but it has a return.
Because it facilitates continuous learning. Learning from mistakes is fine. Every person, team and organisation makes mistakes and it is normal to collect and analyse the lessons learned in order to improve. But this doesn"t mean that we must make mistakes in order to learn. Sometimes we just cannot afford that. So why not aim for making things right from the first time? The usual constraint here is time: no time for reviews or for proper planning or for proper technical design or time for rework and fixing. In reality the time allocated for ensuring that things are done correctly the first time is recovered in triple amount at later phases of the project lifecycle by less testing, fixing and rework. There are a large variety of helping practices to rely on, such as reusing our past experience, our and others" consolidated know-how, proven best practices and statistical information.
Because it is - or more precisely it can be - practical and applicable. It suits large and small: being a small start-up or being a large corporate, none is an excuse for not investing in improvement and both can benefit of it.
Small companies are hungry for new business, for bigger deals, for larger customers. And often these prospects are demanding. They may simply ask about an SDLC model, which is not even that hard to answer. But, if they go deeper in details asking for explanations for why things are done in a way or another, then well… we need a solid rationale behind it. Most of the time the described SDLC contains the design + development + test phases well explained. What about planning? Monitoring? What about configuration management? Change management? Risk management? Planning without monitoring is a waste of time and effort. Monitoring without a proper planning is nonsense. And so easily a promising deal can turn wrong.
Large corporations can generate significant losses if not optimised. Sometimes leading to the schizophrenic situation of having mountains of know-how inside and still no one can really use its value. Complex environments are subject to heavy dependencies - between various roles, departments and tasks. So there is no one to oversee the whole chain, strategy and plans are often get blurred between layers, leading to heavy overhead and confusion for the engineering teams. These result in delays, wait times and eventually rework. Now, multiply this with hundreds of brains & souls in an average corporation and the loss figures might be surprising.
Because it leads to tangible, measurable results. Just a few examples :
Yearly decrease in TTM - from 15% to 23% gains
Yearly increase in early defect detection - from 6% to 25% gains
Yearly reduction of field error reports - from 11% to 94%
Overall business value (ROI) - from 400% to 880%
Because we have to sell our services and products to more and more demanding customers. It is nice to showcase the successes that we had. We must be able to demonstrate why they were successes, what made the difference. We should be able to showcase also "how" we made it successful. And more important, we should be able to ensure that doing the same will ensure repeating the success - that"s why we need repeatable processes.
As a conclusion…
These are just a few of the reasons for which it is worth bothering with improvement. Of course, a full-fledged large-budget improvement programme is not always affordable (even if it usually remains more affordable than a lost contract), but this should not be an impediment if there is will. Some small steps can be taken to start with:
Start from current work practices. Document the current SDLC. Identify the gaps.
Define objectives. Then act in small steps towards them.
Get professional advice. It can maximise the ROI and it can make it practical.
Organise trainings aimed to establish critical competences such as project management, process improvements, risk management but also for getting familiar with the model to be followed (be it CMMi, Six Sigma, ISO, TickIT Plus, etc)
Focus on people, as they are the only ones to deliver quality services and products, while a model or a set of processes are only tools to facilitate them to do so.
Always, in any work practice think according to the Sheward-Deming cycle: Plan-Do-Check-Act.
Implement reviews as often as possible, upon as many artefacts as possible.
With a strong commitment, it can become easier than it might seem. And it is definitely worth the effort, the results can be amazing. I consider myself lucky to have experienced such a journey from start to success - no, not to end, because such a journey never ends - and I am truly hoping that someday many readers of this article will be able to say the same.
And then, of course, there is the opposite question: why wouldn"t you bother improving your business?
