7 tips for a predictable and successful IT project

The changes happening in the e-commerce segment force merchants to act quickly, which makes them want to conclude IT developments as soon as possible. How can we carry out IT developments in a predictable way so that they do not become more costly and do not take longer than expected?

Most IT-development projects are delayed by the following 7 factors

No matter if it’s a webshop or mobile application that is being developed, or a new website is being launched, the most important customer wish for the project is to be implemented quickly and not to overstep the planned budget. Based on the experience LogiNet gained in the previous years, if companies consider the following 7 factors, they can make the projects more predictable in terms of costs and timing. Read on for advice from Zsigmond Máriás, LogiNet’s CEO.

1. Incomplete or missing business specification

The precise description of the business demand is prepared in the specification phase, based on which the developer team will estimate the needed working hours and the IT supplier will calculate total delivery time. If the specification is detailed enough, the estimation of costs and processing time will be more precise, which means a more predictable outcome. If there is no specification, a large number of ad hoc decisions are made during development, which makes the process unpredictable.

Writing specifications is maybe the task with the highest added value in the project, however, there are certain biases, according to which specifying the business demand is just a waste of time and only programming is real work. And if we apply agile development, there is no need for a specification at all.

Tips for avoiding this problem

• Insist on having specifications with different levels of detail in the different project phases.
• Don’t aim to plan everything down to the last nail right at the beginning, but there should be no blind spots left either.
• A couple days of writing specifications may save you a couple of months of writing code.
• As a client, get ready to make decisions and make time for it.

2. Changing requirements and priorities during the project

It’s inevitable that the requirements will be changing during project implementation, due to the changes of the market and the environment. New requirements may also arise, or it can come to light that the concept was incorrect, there are loose ends or something has been forgotten.

If the changes are received ad hoc, they might cause serious timing and quality issues.

Tips for avoiding this problem

• It’s important to have a specification in the beginning of the project, since this way it will be clear against which base we are making the changes.
• An impact analysis should be prepared for each new requirement.
• MVP approach (Minimum Viable Product, meaning an operable prototype, which is the fastest to prepare): the company should start with the functionality that is essential for the business operation, and this needs to be adhered to (on client side as well).
• Clear prioritisation and CR process (Change Request) should be in place.
• Backlog (the full list of tasks to be completed) building for later use, preparing for continuous development or further phases.
• If the company is introducing a software product, it might happen faster, since they can instantly purchase the result of many years of development engineering work (you can walk to the tenth floor faster, if you start from the seventh, and you do not have to climb all the way from the first). However, it’s worth taking the time to look for the product that fits your needs best, to get to know to the introduced system during a consultation first, to prepare a gap analysis, determining the gaps (individual needs) and making compromises in order to stay within budget.

3. The number of tasks and actors needed to perform the integration is underestimated

Connecting the elements of IT infrastructure into a cooperative system is key: a webshop software usually needs to be integrated with ERP, CRM, invoicing and delivery systems and marketing automation systems.

Supposing that when the existing infrastructure has been working with something else properly up until now, then introducing a new system should not be a problem, is wrong. If it’s not analysed if our other corporate software are compatible with our new webshop, then numerous unnecessary change requests will be burdening our project.

Tips for avoiding this problem

• Recognise that this project has multiple actors.
• Involve the suppliers of the other systems right from the beginning of the project.
• Plan testing in collaboration with the other supplier, dedicate time to the testing process.

4. The migration an data upload process are underestimated

This problem is less relevant for green-field (completely new system) projects. However, sometimes there is a lot of data that has to be migrated from the old system to the new one (users, products, previous orders, marketing campaigns, URLs, images, contents, user preferences, etc.) and companies tend to underestimate the resources needed for this task. Usually they think that sending a few Excel files will suffice, the developer will quickly upload the data and the process is concluded. However, in practice this might result in serious delays.

Tips for avoiding this problem

• Plan the data that needs to be migrated right from the beginning.
• Make sure that data can be easily retrieved from the previous system.
• Ensure that sufficient capacity is provided for the upload (time, workforce).
• Less qualified employees may also be able to process the upload.

5. Incorrect application of agile project methodology

Companies tend to think that if the development follows the agile methodology, then there is no need for specification, describing the business demand is only a waste of time, coding is the real work. In reality however, the company might find that in case the developers prepare what they want, then they are not able to tell how long and how much it will be, or if they can tell when and for how much, then they cannot predict the exact result.

Tips for avoiding this problem

• It is possible to conclude agile projects correctly, but: serious dedication is needed from the client side as well (Product Owner appointed in the client’s organisation).
• It seems to be a better approach if we benefit from the agile methodology but we know why we are doing it. For example using sprints and rolling planning enables us to react better to changes, while demos, retros and stand-ups ensure that we won’t be progressing too far into a wrong direction, prioritisation ensures better change management, the MVP approach makes it easier to determine targets and active client communication ensures transparency.

6. Missing client-side dedication

Numerous decisions must be made during the project (requirements, migration, scope changes and setting priorities), for which a client-side team is needed, with the right authorisation and dedication. A development project is not only an IT project, rather a business project, however, it’s frequent that the business area is not represented in the project.

Tips for avoiding this problem

• The availability of a team of experts on the client side is essential, with time dedicated for the project (the cross section of the IT and business area)Suitable forums for escalation, where actors can reconcile their views in a regular and structured way.
• Resource needs (time, money, client-side dedication) must be clarified at project start.

7. Resource problems (at the supplier or at the client)

A large part of delays is caused by this factor. If the project is getting in a delay due to one of the six reasons mentioned above, it can cause a resourcing problem either on supplier or client side (the actors dedicated for the project are supposed to be working on another task already), which will probably further delay the project.

Tips for avoiding this problem

• The team of experts must be available according to plan both on client and supplier side.
• Have proper resource planning and update it with change management. Changes in timing are also changes, they need to be considered.