Which project practices are right for my IT project? (incl. self-assessment)

If you spend any time at all in IT, you're sure to hear about it: everyone is talking about agility. They say it’s much better to use agile practices than a waterfall model. Is it true? Are agile projects fail-safe? Yes and no.

We’re all familiar with waterfall projects. The project starts. You specify the requirements. It gets developed. All this only to find out that the final product is not necessarily what you initially had in mind. Yet most software projects are nevertheless done as waterfalls. You might be wondering why that is. Waterfall projects offer security, but it’s really more like a feeling of security at best. You have the illusion that you know right from the start what you’ll get and how much you’ll pay for it.

Agile projects, on the other hand, make you feel pretty unsafe if you’re not experienced. You don't feel like you know what you’ll end up with in the end. You also don't quite know what it will cost. But as we’ve now seen, in reality, you don’t actually know that with the waterfall model either. The scope changes in every waterfall project – keyword “change request.” With agile projects, instead of defining all the requirements at once right from the get-go, you add them gradually over the course of the project. This doesn’t mean, though, that agile projects have no goals. Quite the opposite: agile projects continuously pursue the product vision defined at the start of the project. So, you know what direction you want to head in and where you’re going to end up.

Using agile practices means changing your mindset, not just implementing a new process. By extension, this means that switching to agile practices triggers a change within the company that not every company is prepared to embrace. Going agile can be challenging for an organization. To make matters worse, sometimes the project fails anyway.

Based on our project experience, we know what the weak points of the waterfall are. To minimize these as much as possible, we’ve developed a hybrid project approach. On its face, it essentially follows the waterfall model. But in various areas, we’ve borrowed methods from the agile approach in order to compensate for the most dangerous weak points. This combination ensures that we’re not just doing the right things – we’re also doing them the right way.

Getting customers involved as early as possible

The hybrid approach focuses on getting customer feedback on the implemented functions as early as possible. The way we achieve this is by shortening release cycles during the implementation stage of the project. This way, unlike with a conventional waterfall model, our customers have a chance to see what they're getting and test it out very early on. So, over the course of the project, the customer’s knowledge of the new system increases consequently. They also get better at formulating their requirements. As an implementation service provider, we also get timely feedback on the quality of our developments. Plus, we're able to see if we've understood our customer correctly.

Good communication as the key to project success

The hybrid approach also improves communication with the project partner, which has a positive effect on project operations and collaboration. Many projects fail due to insufficient or poor communication. The hybrid approach lets us compensate for these weaknesses.

There’s no one right answer. It’s more about finding the most suitable approach and not being afraid to explore new directions when the old ones don't work out.