On predictability in software development. How can one make order from chaos or 5 steps of growing the maturity of an IT company
„A badly planned project will exceed its duration three times; nevertheless, a well-planned project will exceed it only twice” or “there is never enough time to do the things well from the beginning, but there is always enough to do everything again in the right manner” – these are only two “sayings” to be found in the world of project managers from the IT industry.
Looking at them from the point of view of a project manager, these could sounds truly funny, if they were not at cross-purposes with what the clients expect to happen: “We want predictability from the IT managers”, “We want the estimation in IT to have an acceptable deviation”; “We want predictability for budgets, within costs and deadlines”, etc.
Under such circumstances, the first natural reaction is that of finding a number of excuses which seem founded at first sight, especially given the fact that the field makes available a host of such excuses starting from the idea that the software development process is a creative one and up to comparisons with other mature industries, and the IT manager praises the intellectual work over physical work.
But beyond of making fun of a bad situation or of adding a few witty words, we must ask in all seriousness – Why would we get into such situations and how can we find a solution so that we would be predictable?
What is “Predictability in IT”
So, let’s see what is hidden behind the phrase “Predictability in IT”. For the ease of the example, we will make an analogy (http://calleam.com/WTPF/wp-content/uploads/articles/What- makes.pdf) with the construction industry (we know that some of the reader might be surprised by this analogy). So, we have a client who wishes to build a house: he goes to a team of specialists which give him, within a +/- 30% margin of error a price quote and a deadline. In opposition to the construction industry, in the field of IT the majority of the customers are complaining that they cannot obtain such estimations from the IT companies. And then – the question appears: where does this difference come from? We might think, at the first sight, that the difference resides only in the difference between the physical work and the intellectual, creative one and thus is it harder to estimate. In reality, the things are somewhat different. The conclusion of the study we quoted above is that in the construction field there are few decisions made after the start of the project (in comparison to the ones discussed previously and these decisions are made at a centralised level, only by a few people), while in what concerns software development, a lot of decisions are made, at any level and during any stage of the project development.
Thus arises the need to create a process which would describe, broadly, the activities included in an IT project, which would lead to a correct and realistic estimation of both terms and costs and which would offer the expected quality of the developed product.
To come back to the IT field – predictability and quality in IT are given by the combination of three elements:
- Well trained people
- Well-structured processes
- Performant technology and tools which could be used as support for process implementation.
Naturally, there is no universally-applicable recipe for growing the maturity of an organisation on the three directions mentioned above, but surely the following 5 steps are of great help, if not essential.
First, a company needs to aim at policy level to improve the three directions above. One needs to consider their cost, which is not negligible, both at the level of human resources and of the financial resources, with the mention that these will function better than a boomerang, bringing long-term benefits.
2. Transition from personal process to project processes
Once the vision is set, as well as the drive at company level, a second step would be the unification of the processes at the level of each project. Why? And especially, how do we do that? We may start from the idea that “people make the best of a place”, but there are some that make a place better than others, in other words, there are cases in which experience, expertise and interest for the completion of a quality project come into play. And then, why shouldn’t we take the best-practices already tested at individual level and extrapolate them at project level, where everyone in a team could benefit from them?
This step, that pertains to the project leader, is one of collecting information, it takes a lot of tie and requires maturity in order to make the difference between what is good, relevant and applicable and what is not. Nevertheless, the benefits of this step are seen immediately in the product quality, and especially in the team’s productivity
3. Transition from processes and good project practices to those formalised at organisation level
Even though the previous step bring a series of improvements on the working model, there is however a problem. Some projects go better than others. There is still no steadiness and predictability at the level of the company. Why? Because some project already have more performant processes they are guided by, and others don’t, and this may depend both on the specificity of a project and on the experience of the people involved. Under such conditions, there is the need to share knowledge between projects, there arises the need to transfer good practices and project processes at the level of the organisation.
4. Formalising the processes at company level, organising a group which would concentrate on process improvement and tools
During this step, there arises the need of centralisation, of refining and formalising all processes coming from project level. As best practices we recommend the setting up of an internal working group whose responsibility would be the formalisation of these processes. The group would have the purpose of refining the tools which would then facilitate the process implementation. The greatest danger now would be to end up with a bureaucratic process which would lead to increased costs and the impairment of the working manner. How can we avoid ending up with bureaucracy? With the help of the tools which allow for the automatisation of the process activities.
E.g.: automatic testing tools, issue tracking tools, automatic code inspection, project management tools, etc. Experience has shown us that, in this stage, it is important to create a data base which would include all good practices identified in steps 1, 2, 3 and 4.
Furthermore, this data base (Company Knowledge Base) must include as well the KPIs measurements of existing projects. The data base includes all information collected during project development, good practices, and measurements – becoming a reference “library” for future projects. Thus, all information remains within the company, can be easily consulted, and the development of future projects is based on proven good practices and not on individual knowledge.
5. Share the best practice
The last step would be the implementation of the processes collected at company level, again at project level. This phase begins with trainings and workshops both at project management level as well as at the team level for each project. As a result – processes become unitary at company level. In this step includes as well the adaptation of organisational processes at the particular situation of each project (because there is no “perfect process that fits them all”).
You succeeded, go on
The five steps above may guide a company that is still based on individual processes or on project processes towards standard processes supported by tools and executed by highly trained people that can offer the much-coveted predictability in IT.
After the company goes through the steps above it is essential to improve continuously the already-standardised manner of work. This process must be a continuous one.
Instead of conclusions
In conclusion, the roads towards quality improvement and predictability for the Romanian IT companies is one of the “secrets” that may offer a competitive advantage, especially against the background of the price pressure coming from India or China, but also because of the increased expectations coming from the customers who want quality software products, at the estimated prices and deadlines.