Common Software Development Challenges

Over a third of IT projects fail due to lack of defined objectives and milestones, according to research by professional project management organization PMI.

Similarly, 80% of companies admit to spending half their project time on rework.

These are both issues that can be solved by a thorough requirements gathering process and clear, consistent communication between stakeholders and your software development team. While running a good requirements gathering exercise sounds like a simple solution to a whole host of problems, there are numerous challenges you’ll face along the way from a software development point of view.

Understanding and anticipating these challenges is the key to overcoming them, which is why we’ve identified three important software engineering issues commonly faced during the requirements gathering phase and offer solutions to overcome them.

Miscommunication Between Departments

Make no mistake about it, your team of software engineers is super smart. They are also very invested in the things they create – arguably no one is closer to the product than the ones whose job it is to code it from scratch. And while this super-involved, detail-oriented approach is beneficial, when left unchecked this leaves the potential for a gap in how your team interprets requirements and what stakeholders originally envisioned.

We’ve probably all seen those ‘what the client asked for/what the client described’ cartoons (and if you haven’t, here’s the classic); this is exactly the issue here. How your stakeholders describe their requirements vs. how they are interpreted by a software development team looking through a more technical lens can differ somewhat, and this can tank your project time and budget if not caught early.

How to overcome this challenge

• Have your senior development talent sit in on all requirements gathering activity – meetings, email threads, you name it. This will help everyone remain on the same page and avoid misunderstandings about what each requirement constitutes.
• Update your stakeholders regularly. This will help catch any miscommunications early and save hours of confusion and wasted time further down the line.

Managing Competing Priorities

A successful requirements gathering effort needs input from key stakeholders.

The issue? As soon as you open up your project to input from those outside your software engineering team, it becomes subject to competing stakeholder priorities – and try as you might, you won’t be able to make everyone happy. Even if your company is the most congenial organization in the world, you’re going to have to employ some tact to avoid your project becoming the next battleground for the whims of workplace politics.

Without taking the right steps, it’s all too easy for your project requirements stage to turn into a massive, company-wide wishlist that you’ll have the enviable job of saying ‘no’ to. While it would be lovely if your software engineers could solve everyone’s issues, ultimately you’re constrained by time, budget, and personnel – just like any other department.

How to overcome this challenge

• Be clear about project scope. Circulate detailed information about your project scope at the start of the process – you can then refer back to it when creating a requirements shortlist. You’ll receive fewer left-field requests and the ones that do come through can be dismissed immediately and reasonably as ‘out of scope.’
• It’s all about compromise! Involving your key stakeholders in every stage of the process will help them come around to others’ points of view. While you, ultimately, get the power of veto, call a meeting to agree on your ‘must haves’, ‘nice-to-haves’ and ‘maybe next updates’ – the more involved everyone feels, the happier they will be with the final product requirements doc.

Agreeing On Success Criteria

‘How will we know if this project has been a success or not?’ is a question that gets overlooked far too often at the requirements gathering stage.

It is tempting to consider that project success means meeting 100% of your requirements. This certainly isn’t a bad goal to aim for, but it also might be over-idealistic. Your team of software engineers know that over the course of the project, you might have to make changes, drop certain requirements in favor of others.

For example, you might realize that in order to fulfill one requirement, you might fail another requirement. Your options are to pour time into resolving the problem (potentially taking the project past deadline, leaving you open to scope creep and cost increases) or to sacrifice one of the requirements at the expense of the other. And where does that leave the success of your product?

How to overcome this challenge

• If your project is product-based, agree on what constitutes a minimum viable product with your stakeholders and include it in your product requirements document. This gives everyone a baseline for what success looks like right from the start of the process, and contains the potential for budget overruns and scope creep.
• Break your project down into stages. Basing your success on adherence to absolute, end-of-project goals is setting yourself up for failure. Set a percentage completion timeline so that you’re working towards smaller, more manageable targets. Look at your performance across similar projects as a realistic baseline, and set yourself manageable improvement goals.
• During the requirements gathering phase, ask your senior engineers to identify any potential clashes amongst your top requirements and gain agreement from stakeholders which should be prioritized over the others.

These are just some of the challenges you might face in the requirements gathering process. Your key to overall project success depends on your ability It’s anticipate and/or identify challenges beforehand and manage them appropriately.