Successfully pulling off a project can be challenging at the best of times, and when you add tricky software development into the mix things can get a little out of control. Pitfalls pop up unannounced, from correctly time-scoping development stages to latent stakeholder lethargy. While it’s all too easy for project managers to fall foul of these 5 common problems in the software development life cycle, getting a handle on pain points can help improve management practices and streamline any future software development undertakings. Ultimately, a pain and problem free project results in lower costs, a better product and fewer headaches for the project team.
1 – Planning timeframes
A well-planned schedule is one of the keystones of a successful software development project. And while PM tools are great, even the most sophisticated tool won’t save you from unexpected glitches. Smoothing the way for the development team requires canny prioritization, clear values, and an ability to predict the true impact of team actions.
Related Article: Avoiding Top Project Pitfalls
When planning SDLC timeframes, create a detailed task list: you can find templates that will help you organize all the smaller activities needed to bring to fruition a larger goal. Writing down all the steps required to meet a target ensures that a) fewer steps are overlooked and b) each step is less likely to be under-estimated in terms of time taken to completion. Also, if a deadline starts to creep up on you, a detailed task list will help you redefine the scope: you can either adjust the schedule, reduce the number of things you were going to do, or add resources.
With a task list, nasty surprises are less likely to crop up mid-development, and it will be easier to see at a glance where you can add or pull resources or activities without negatively impacting coding.
2 – Prototyping too infrequently
Early-stage prototyping and mid-stage iterating are vital to smooth project progress, especially in agile development methodologies. Running through the full family of prototypes will iron out potential pain points without increasing spend: use paper wireframes on user testers in initial stages to work out IA; present clickable mockups when explaining the idea to the development team; build a high fidelity prototypes when you’re nearing the final stages and need to convey the highest fidelity to clients or stakeholders.
3 – Failing to anticipate problems
There’s one big reason why Project Managers don’t spend enough time planning for problems. Because they don’t want them to happen! Sadly the ostrich technique isn’t so effective. A better strategy is risk management. Risk management can be done visually in a work flowchart, which is then checked against resource conflicts and component dependencies. Once identified, you can plan around these potential problems – lengthening lead-ups, prioritizing certain pathways and freeing up resources just in case. Building pauses into the SDLC around these potential obstacles can be a great point to build in mid-cycle quality testing.
4 – Failing to allocate tasks properly
Software development is a competitive field, and sometimes everyone wants to be the hero. But ‘heroics culture’ – pulling 20-hour shifts and moving heaven and earth to get the project done – can ruin a project. Isn’t it better to be organized and obviate the need for heroics in the first place? Creating a realistic schedule in which activities and responsibilities and wisely allocated is the best approach. For example, if you’re at the coding stage, let the developers know what tasks they’ll receive through the API and the results you expect to see in their code. Then leave them alone.
In terms of team organization, be wary of putting one person onto two projects and expecting equal investment in both, and make sure you’re providing enough staff and support for each team.
5 – Failing to engage stakeholders
Even the best PM can struggle when faced with difficult or disinterested stakeholders. Trying to keep stakeholders happy and still respect scope and spend can seem impossible. If you’re managing requirements within the project, try keeping stakeholders engaged by swapping out text-heavy requirements documentation for more streamlined tech such as a prototyping tool. Within this, you can add stakeholders as a user and have them collaborate on requirements, and everyone has access to the version history – everything is traceable. Plus confirming implementation of each requirement within the tool will keep your stakeholders in the loop.