Steps to follow in an IT project

It is never easy to carry out an IT project within a company. In most cases, it requires significant human, financial and technical resources and it leads to a change and evolution at the strategic and operational level of the company.

To maximise the project’s outcome, it is essential to follow a series of key steps. Regardless of the size or nature (development of an application, a website or any other IT tool) of the project, these steps represent crucial stages in project management. You will, of course, need to adapt them according to the resources you allocate to your project. I will detail these steps in this article and I will illustrate them with an example. Let’s take the example of a textile company that wants to increase its online sales.

An IT project can be structured by answering 3 simple questions:

1. Why? Why are we launching this IT project, what are the objectives we want to achieve? If we take our example, the textile company’s objective is to increase its online sales.
2. What? What will we put in place to meet the project’s objectives? This is where we define the scope of the project. In our example, during this phase, the project team estimated that it was necessary to develop an e-commerce site for the textile company.
3. How? How will the objectives be met? The functional and technical analysis as well as the definition of the design and wireframes will help to answer this question. For our example, following the analysis made, we could estimate that an e-commerce site developed with WordPress is an optimal response to the client’s needs.

To answer the above questions, the project is divided into several phases which I will describe below.

Initiation

At the beginning of the project, different elements should be defined in order to answer the questions « Why » and « What »:

The objectives and the scope

First of all, there is the objective of the project, which corresponds in fine to the result you wish to achieve. It is strongly recommended to define SMART objectives: specific, measurable, acceptable and temporally defined.

Next, we look at the high-level analysis of the needs: here we define the EPICS which correspond to the main functionalities to be implemented. For our example, we will put a sales website online, which will be translated into French and Dutch. There is also a contact form, a link to social networks, etc.

Finally, we will define in this part the scope of the project: among the identified needs, which are included and which are not in the development of the project. This removes all expectations and misunderstandings and allows the supplier and the client to be aligned on the result.

The stakeholders

We define, for each stakeholder, a role and responsibilities using a RACI matrix.  For each step of a process we will define which actor(s) is/are Responsible, Accountable, Consulted and Informed.

The budget

We must define the budgets required for the entire project (definition, analysis, development, testing, production, customer follow-up and maintenance). We often speak in terms of man-days, which is a unit of measurement corresponding to the work of one person for one day.

The planning

Regarding this point, a good practice is to define a retroplanning. This allows you to organise the project from A to Z by defining the human and financial resources available to the project, while having a clear view of the tasks and deadlines. Retroplanning offers several advantages:

• better resource allocation because they are calculated according to the time available,
• clearer definition of the budget because all the necessary resources are known,
• the time to market, defining the precise date of the product launch, is known from the start.

In theory, retroplanning is an excellent tool for meeting deadlines, in practice it is always complicated to apply it strictly and to meet the deadlines set. Make sure you meet the deadlines as closely as possible.

An alternative is the Gantt chart, which allows you to define the hierarchy, duration and sequence of tasks to be carried out.

The methodology

Depending on a series of parameters, we recommend either a more agile or a waterfall approach. As a reminder, the agile approach is an evolutionary method with development as it goes along. It is a flexible method that allows the product to evolve gradually. The advantage is that the functionalities and requirements are not fixed.

The waterfall method is a single block development. At the start of the project, all the requirements are listed in a specification. After validation by the project stakeholders, this specification cannot be changed and must be strictly followed. In this article we focus on the agile approach.

The analysis

The project analysis also helps to answer the what question. What are we going to put in place in order to answer this question? Following the definition of the epics at the start of the project, they will be detailed by listing all the functionalities to be put in place. These will be defined in the form of user stories (« As …, I would like … to … »).

In order to define this, the business analyst will conduct interviews with the stakeholders to capture the explicit and implicit needs. Based on this, the business analyst lists the functional and non-functional requirements and formalises this information by writing user stories, wireframes (functional mock-ups) presenting the structure of the various interfaces of a system or process modelling. Among the latter we find the most commonly used: BPMN, activity, sequence and class diagrams. The business analyst will also design a risk matrix. This matrix helps us to identify risks and to establish a series of actions to limit their probability and impact.

In the agile approach, the requirements are listed in the product backlog. The product owner is defined by the Scrum Guide as being « responsible for maximising the value of the product resulting from the work of the development team ». He will prioritise the requirements using a MoSCow matrix and estimate the workload in collaboration with the development team. On the basis of this, he will organise the features to be implemented in sprints. The most valuable requirements will be developed first in the first sprints.

The development

We have now answered the three questions: Why, What and How, so it is time to develop the solution.

The development team will be responsible for developing the product on the basis of the established analysis documents and within the timeframe estimated in the retroplanning. It is the team’s responsibility to choose the human and technical resources (technologies, languages, etc.). It is strongly recommended to define the financial resources at the beginning of the project; at least a maximum budget not to be exceeded. This budget will then be challenged by the teams during the analysis phases and particularly before any development! The architect’s role is to define the technologies needed to meet the requirements defined during the analysis. The development is done in close collaboration with the business analyst, who will ensure that questions are answered and that any unclear aspects are clarified.

Testing & maintenance

Once the work of the development team is complete, the business analyst is responsible for ensuring that the product works and that it fully meets the customer’s needs. Testing will detect any anomalies in the product, and maintenance is intended to maintain the product over time, correct possible security vulnerabilities or implement new features.

Conclusion

I insist on the fact that these steps should not be strictly applied, as each IT project is different and should therefore be treated differently too. These are good practices to follow in order to carry out an IT project successfully. They must of course be adapted according to the financial, technical and human resources available within the company.