Avoidable risks in IT projects

We can differentiate possible risks in IT projects in 2 categories: The technical and functional risks. The first kind of risks is du to internal programming team error such as wrong coding method or lack of version control. The second kind of risk is du to bad process around the IT project that implies all the stakeholders, such as the communication obstacle between the project development team and the project owner.

1. The technical risks of IT projects

According to an article of software-testing-zone.blogspot.com [1], nine technical risks can impact an IT project:

• Communication problems,
• An unrealistic calendar,
• A wrong definition of the architecture,
• Bad coding methods,
• A lack of version control,
• Buggy external tools,
• A lack of experimented testers,
• Last minute changes,
• The human factor.

Let's evaluate each risks in order to identify the possible responsible. If we use a typical "Project Owner" "Project Development Team" organization with eventually a "Project Management Support" which job is to assist the "Project Owner" in the achievement of its project, we can order these technical risks into 3 categories:

• The first category is constituted of the bad coding methods and the lack of version control. It is a category where the responsibility goes to the project development team. A knowledgeable project development team must use a version control tool and have most of the time formal coding methods taught at each engineer working with the project development team
• The second category is at charge of the project owner. They are made of the choices of the project owner. The risks in this category are, the use of an unrealistic calendar, the provision of buggy or unqualified external tools or too many last minute changes
• The third and final category is at charge of the project management support. The risks in this category are communication problems between the project development team and the project owner, the lack of experimented testers or a wrong definition of the architecture of the project.

The last unclassified technical risk, the human factor, can be ascribed to all 3 categories. It is also an irreducible risk common to every project made by man.

Figure 1 : Technical risks in IT project classified in 4 categories

This classification shows that technical risks in IT project are du to every stakeholder of the project. That is why it is important to use quality improvement methods understandable by every actor of the project. The proposition made in the following of this article goes in the direction of putting every actor on a same structured communication framework.

1.1. How to reduce the technical risks of IT projects?

The project development team's technical risks

As shown in the previous classification, the project management technical risks are du to wrong coding methods and the lack of version control in IT project. The only way to reduce those risks is to explain the utility of existing and proven useful methods and tools made increase the security and the productivity gain of IT systems.

The project owner's technical risks

Three risks were identified in this category: An unrealistic calendar, too many last minute changes and the provision of buggy or unqualified third party tools.

An unrealistic calendar

It is complicated to evaluate the workload of a project simply from the project owner's needs. As the Golub’s Laws of Computerdom writes it: "A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long." This shows in a humoristic way, the difficulty of planning the workload of a project. That's why it is important and very useful for an IT project to use methods such as the redaction in the specification plan of a clear tested architecture of the project before putting the project development team at work.

Too many last minute changes

These changes imply last minute coding and increase the risks of defects in the final system. Last minute coding have more chance to add regression in an IT project and force the changing of already coded and tested part of the system. An easy way to reduce last minutes changes risks is to use very short agile development cycle where short part of the system are coded, tested, integrated, validated and version controlled in a regular way and transform last minute changes of an iteration into early needs of the next agile iteration.
What about changes that generate incoherencies in previous requirements? A solution is to use requirement based testable model to apply the new requirements and verify if they don't imply to many changes in the previous requirements.

Buggy or unqualified external tools

Few can be done on a methodological basis to reduce the risks of buggy unqualified external tools. As for IT systems, the best way to ensure that an external tool is going to answer the needs of the project is to apply on it validation tests that will ensure that the external tool adds productivity instead of reducing it.

The project management support's technical risks

There are three technical risks at charge of the project management support: The communication problems risks, the lack of experimented testers risks and finally, the risks du to a wrong definition of the project architecture.

Communication problems

It is clear that, in IT projects, business needs analysis and their feasibility analyses are optimizable processes. In a usual IT project, the project owner does the business needs analysis while the project development team does the feasibility analysis. It adds roundtrip reunions and communication risks. A solution is to analyze the requirements upstream and to write them in a structured language understandable by the project development team. Furthermore, modeling in a simple way the requirements before the beginning of the coding stage will reflect the completeness of the specification plan and also the incoherence between them.

Lack of experimented testers

Test represents an important part of the software development. According to www.basildev.com, test represents between 20 to 50% [2] of the cost of a project. Testers occupy an important part in the software development lifecycle. Without prejudging of the quality of the testers, having automatic test sequences corresponding to the system requirement before the validation stage is an asset for the testers who can prepare themselves and for the developers who can use these test sequence to better understand the meaning of a requirement. It will accelerate the software development lifecycle and increase in the same time the project's quality.

A wrong definition of the architecture

A correct architecture definition is induced by a good knowledge of the business. Here resides the difficulty to offer the project development team a correct architecture. Model testing is a great help for this. Testing a model exclusively made from requirements ensures its quality and its accuracy. It can tell us if the architecture and the specification plan are complete.

1.2. Four recommendations to reduce risks in IT projects

The analysis of the technical risks and their solutions leads us to 4 recommendations that help the risk-agility couple in IT projects:

• Model the system from the requirement in order to verify the completeness of the specification plan, but also the incoherence between 2 requirements,
• Transform a textual requirement into an executable requirement written in a structured and precise language understandable by any project development team,
• Execute each new requirement on the model made with the existing requirements. It will avoid the incoherence of the business needs
• Create automatic test sequences corresponding to the system requirements being released before the release of a first version.

2. The functional risks of IT projects

These risks are different than the technical risk of the previous chapter in a way that we can find them in the project management on the contrary of the first risks that can be found in the project development stages. According to Nathan Hattab, consultant in IT systems and member off the AFAI [3], there are 5 functional risks [4] in an IT project:

• The inexperience of the project leader or his inability to lead a project,
• The inaccuracy of the specification plan,
• The lack of maturity of the project owner,
• The lack of mastery in the engineering process of a third party tool,
• The wrong estimation of the workload of the project.

As for the technical risks chapter, we can classify those five functional risks into the three same categories: the project owner category, the Project management support and the project management categories.

Figure 2: The 5 functional risks in IT project classified in 3 categories

2.1. How to reduce the functional risks of IT projects?

The lack of maturity, the main functional risks of the project owner

The project owner maturity only depends on him. However, giving him recommendations that will help him reduce the risks induced by his need is a win-win situation. If this risk reduction can be made at an affordable cost, it would be a mistake not to apply it.

The estimation of the work load, a risky set for the project management support

Here is a set that can be improved by analyzing the accuracy of the specification plan. In computer science, the sooner we start, the later we finish. This means that it is often quicker to take the necessary time to analyze a specification plan than start coding instead of starting to code without analyzing the specification plan. The accuracy of the specification plan will help estimating the workload and will remove information that would lead to avoidable coding work. Thus spending some time to model, in a simple way, the specification plan of the desired system will help giving an insight of the completeness and the quality of the specification plan and, in the same time, will help estimating the work load of the project thus putting the project development team in the best condition to start coding.

Project management and project tools, the work of the project development team

As for the technical risks, it is very difficult to tell a project development team how to work. Reducing risk inherent to the project development team is made when he must give the proof of his ability to conduct a project. However, giving him structured document easy to understand and without incoherencies will help him lead the project in the best conditions.

2.2. Modeling, a simple way to reduce functional risks in IT projects

According to the risks identified by Nathan Hattab, we can see two key functional risks that can be reduced to improve IT system quality, the inaccuracy of the specification plan and the wrong estimate of the project load. An upstream modeling of the system will help reduce these two key functional risks. The IT system modeling guarantees a good communication between all the stakeholders of a project. It allows the transformation of the literal language of the project owner needs in a structured language understandable by the project development teams.

To resume, modeling the system exclusively from the requirements allows the verification of the completeness of the specification plan, as well as the identification of the incoherencies between two requirements. It will also help in:

• Clarifying the specification plan by testing upstream the requirement of the system,
• Better estimating the work load by having before the estimation a tested and qualified architecture,
• Reducing the risks induced by the project leader by offering him detailed requirements, a qualified model and a set of test to help him lead his project,
• Improving the project owner maturity by showing him how his choice of upstream analysis allowed in increase in the quality of the whole project.

References:

1. http://software-testing-zone.blogspot.com/2008/12/why-are-bugsdefects-in-software.html
2. www.BasilDev.com, Automating the functional tests of embedded real time software
3. AFAI : French Association of Audit and Computer Consulting
4. http://www.afai.asso.fr/index.php?m=76