How to prevent project management failure?
There should be a requirements discussion with the Developers and Designers before you start writing code, ensuring designs and time frames are feasible.
Delivery dates should be agreed upon by all parties ahead of project kickoff; when scope creep, or unexpected delays occur, re-evaluate your deadlines.
Managers should insist on providing documentation on client systems for the development team upfront. If no documentation exists, arrange for knowledge transfer between the development team and an expert on the client APIs; consider this when agreeing with deadlines. If prudent, there should be an iteration zero to identify risks and estimate stories better.
If you see any red flags that may suggest inappropriate practices by the customer, investigate and raise these issues as soon as possible; for legal reasons and financial ones. Ensure transparency and open communication within the Team to maintain trust.
As a software engineer for mobile platforms, I have worked on teams where the Project Managers displayed excellent and poor management practices. This article is about observations I’ve made while working as an outsourced staff augmentation professional; one where the project was, in my opinion, and measured by outcomes, poorly managed.
Full disclosure, I am not a credentialed project manager, but I have learned that much pain would be endured for all stakeholders when the management lacks. I hope that detailing some of the suggestions in this post will improve the coordination between Project Managers and software development professionals. Budget owners and creatives should consider these ideas as well. Project stakeholders would do well to heed the following suggestions and avoid software delivery pitfalls.
1. Always Discuss Product Design Requirements with your Team
A project that was to have a mobile system intended to run on Android and iOS began with requirements interpreted from a web designer with limited mobile platforms experience. It happens. UI/UX designers can put their best foot forward, assuming that they understand the requirements, and still miss the mark. Mobile developers know this when they see it, and it can be easily avoided by having the designer sit down and work with the developers to build a wireframe. The work cannot start without knowing the limitations of the mobile platform you’re developing for. In this case, the issues went beyond a lousy design. The project was better suited for mobile web and not for mobile devices. The app brought significant battery and data demands that hampered performance. The development team had to correct the designs. We had scope creep to deal with, user stories needed updating, and we lost time. Aligning on requirements upfront is an absolute necessity. Working from a vision of assumptions on design and layout is a recipe for failure.
2. Establish Timelines with Your Engineering Team
Referencing the same project in the first section, we lost time redesigning to a consistent, but native mobile design. The delivery dates, which were unclear from the start, were disrupted. Coupled with this, the marketing team determined the deadlines without any technical input regarding how long the work would take. There should have been more discussion with the Product Owner, Designers, and Developers before project kickoff, committing to delivery dates. As a development professional, effective discovery on the projected timeline is essential. Do not agree to something unreasonable – start by following my first point above. In this case, the client promised their customers before having signed an agreement with our Team. That is something that was out of our hands as contracted professionals. The client-side agreement put a strain on the development team, which hampered the quality of the product. We cut corners and agreed to undesirable refactors to meet deadlines not decided upon or effectively discovered from the start. Sometimes asking “why?” is enough to help you determine if you should accept the project at all.
3. Establish the Viability of Any Existing Platforms
It is difficult to comment on a client’s internal systems, especially when no documentation exists to help the development team integrate with its functionality. Documentation or access to their system should be requested, provided, or discovered up-front. Catching this early will organize knowledge transfers, demos and encourage the writing of additional documentation. In one case, with limited documentation and exposure to the existing system, the development team was drip-fed bits of the API through emails. I could only data transfer objects required by the API by investigating error messages and output logs. The biggest issue that blocked the Team for weeks was an app-crashing bug that appeared when using the client’s third-party systems.
The crash occurred on Android and iOS, and after much testing, the only remaining place for the bug to hide was in the client’s code. They assured us there was no bug on their end; otherwise, they would have seen it in their desktop app, which was in production and used globally. After diplomatically asking them to check, they returned within 12 hours and informed us they found a system-crashing bug in their third-party software. Twenty-four hours later, the bug that had held the Team up for multiple sprints was resolved.
4. Work with Your Account Management Professionals
If there are team members on your side who liaison with the customers on a contract and finance level, establish a connection with them. At Unosquare, we have Project Managers on staff that intend to maintain consistent communication and the project’s health. Not intermediaries, mind you, but communication support.
Our development professionals work directly with our clients, and they weren’t communicating well to anyone. In one instance, while the development team was bumping into requirements issues, red flags were being raised by our Accounts Payable Team. When this news made it to the development team, there was some erosion of trust on all sides.
Around this time, the customer requested some unusual changes for a ‘demo.’ The changes were notable because, once implemented, they would make the app appear to be a complete product, but it wasn’t done – we knew what was in the backlog. The app would be skipping many features and testing, practically jumping from ‘In Progress’ straight to the ‘Done’ column.
When the messages started arriving to cease all engineering efforts immediately, it was clear what had happened. And, it’s heartbreaking to experience a team’s work vanishing after doing their best to deliver.
How to prevent project management failure?
- There should be a requirements discussion with the Developers and Designers before you start writing code, ensuring designs and time frames are feasible.
- Delivery dates should be agreed upon by all parties ahead of project kickoff; when scope creep, or unexpected delays occur, re-evaluate your deadlines.
- Managers should insist on providing documentation on client systems for the development team upfront. If no documentation exists, arrange for knowledge transfer between the development team and an expert on the client APIs; consider this when agreeing with deadlines. If prudent, there should be an iteration zero to identify risks and estimate stories better.
- If you see any red flags that may suggest inappropriate practices by the customer, investigate and raise these issues as soon as possible; for legal reasons and financial ones. Ensure transparency and open communication within the Team to maintain trust.
