Challenges in Software Development Projects: Experience Gained by the Innovecs Tech Team

By reading this post up to the end, you will find out what an engineering team can do to get clear project requirements, how to quickly fill a manpower gap, how to make communications productive, and a lot more helpful stuff you always wanted to know but were afraid to ask. Let’s get straight to the point now!

When obstacles get in the way, technical issues like inaccurate project estimates usually attract the most attention. However, it is the lack of leadership that is often the root cause of the problem.

By leadership, I mean the art of being first and it has nothing to do with seniority or titles. You should take the lead and find out the true business goals and pains of the client, come up with suggestions before you are asked, and initiate sending performance reports earlier than expected.

Growing these skills encourages managers to take a bigger responsibility for their actions. They will never take the risk of hiding some data and hindering the client from seeing the whole picture. They would rather share the risk register and suggest precautions to take in case vulnerabilities are found.

This proactive approach also contributes to better communication. If you ask a question about what button to make blue or pink, you may get a client reply like “it sounds good.” Instead, what you need to do is offer one clear solution and give the reasons why it works better.

Another big challenge is to maintain smooth user experience. Everything we do is intended for people; it makes sense to double-check if colors, buttons, menus, navigation, and whatnot are built in line with UI and UX guidelines. The user experience should never be put aside in engineering project management. A user hardly notices the huge work done on the back-end side, while the front-end is visible and always evaluated first.

As a Project Manager, I stick to one simple rule: keep everything noted. You may think it too meticulous, but it becomes a matter of habit. Whatever transformations occur to software development projects, it allows working in sync and getting up-to-date information.

As for project requirements, I prefer following the standards prescribed by PMI® PMBoK and keeping a requirements management plan with guidelines on how to collect, structure and store data. This favors clarity and traceability. When all changes are fixed and Jira tasks are updated in a timely manner, coding and testing are way easier.

Management pitfalls can be eliminated at the engineering design stage through testing projects requirements. In a flexible product development like Agile, software engineers hold kickoffs and brainstorm about what to do, what can be improved, how to address client pain points and more.

A client may not realize something he requires is not something he really needs. I once had a case when customizing a report form as a client initially requested turned out to be 20 times more laborious than the few minor tweaks developers suggested making. This is when the 5-whys rule works perfectly. It helps carry out a root-cause analysis and sort out project requirements received from clients.

By doing so, teams avoid getting into the trap of “doing tasks without solving a client problem.” Businesses do not pay solely for software development. They pay for getting their issues tackled with a feasible technology solution. To be an efficient PM means keeping your team well-informed about these issues as well as the final goals to reach. It motivates and lets everyone stay on the same page.

One of the biggest challenges is to find manpower within a short time frame. It is a huge stumbling block, especially for small-scale projects and startups.  

It can make conducting code reviews impossible which is why the architecture is badly damaged. DevOps is another snag for projects with a growing complexity level. In this case, we get client approval for cross-project advising. This practice shows great results.  

Once, we had a VR project developed in React Native and it turned out some devices required native code written for both platforms, iOS, and Android. We hired developers from other projects for a part-time job giving them the opportunity to expand their expertise and increase income. This is how we plugged a manpower gap quickly and boosted retention of the engineers as they got a chance to gain a new experience working on projects from different industries and initiated knowledge-sharing. 

One more hitch to avoid is a careless choice of the technology stack. Prior to making any decision on that, my recommendation is to go to recruiters for advice. They can say which tech experts are missing or in high demand and give estimates as to how long it may take to find them. Based on their findings, tech leads should then decide on the specialists to hire.     

Missing out on DevOps may lead to pitiful outcomes, as I have already noted. DevOps is a process closely tied with software engineering. Therefore, these specialists should be involved as early as possible. They contribute much to the overall software performance and enable secure code development, continuous integration, delivery, and deployment. If there is no DevOps expert on your team, invite an external specialist. It is essential for every project, to say nothing of software based on cloud services and enterprise solutions. 

On top of DevOps, tech leads should learn how to use engineering practices in the best way possible. I mean writing a ton of project documentation for startups does not make sense, nor does it help to create loads of automatic tests since project requirements are always changing. I would advise being picky with practices, applying new technologies like Gherkin, and keeping pace with the times.  

Talking about challenges in IT projects, I would like to point out risk and scope management as well as project dependencies.  

As for the project scope management, you always need to carry out a thorough analysis to find the answers to these questions:  What is the problem you are trying to solve, to what degree you want to try to solve it, who you are trying to solve it for, why it needs a solution. If you do not get the right answers to these questions, you are going to have a never-ending project.  

Another thing to consider is risk management, which is really about establishing transparency. For instance, you might decide that your product is going to be a blender bottle. Suppose you need 500,000 of them, but the maximum quantity you can get is only 50,000. So, this is the hindrance you need to predict and avoid. Considering the risks to being successful and all possible ways to mitigate them is always a big challenge, so take time to do this right. 

Now comes the turn of dependencies. Let’s assume that we develop some software with an application programming interface (API). So you have a laptop, a screen and a cable between them. You want to provide the ability for someone to use the cable and plug it in anywhere. To make it happen, you need to consider what it is going to be plugged into, who is the manufacturer of this stuff, and how many screen models you want to support. If you do not understand these problems, you will build an interface that does not serve the purpose.  

Fundamentally, the major issue is that people go on making wrong assumptions. When building project scope and dependencies, your assumptions need to be precise. That’s the point. 

P.S.: To make your communication with software development providers a breeze, make use of our latest e-book. Get your free copy by email!