Every technical lead has at some point or another failed to deliver a development project on time. Whenever these things happen they have a huge impact on both partner satisfaction and internal goals, so it’s important to analyze and learn from mistakes. When it comes to postmortem analysis on project execution, I always like to run topic-specific reports on projects done by FarShore as well as third party development shops to identify the source of issues. These reports will help bring to light issues that can be addressed now to prevent future development delays. We have built proprietary processes internally to reduce or eliminate issues on our end and to educate our partners on how to create more collaborative working engagements.
I’ll list out the 5 most common causes of almost any project being behind schedule.
1. No clear vision for the project
Vagueness about a project or its requirement at any stage of the project is a potential issue that becomes increasingly dangerous as the project advances. This can be both on the partner’s side or on the development team’s side, or in the worst case – both.
An always scary situation is working on a project where a partner has a solid understanding of their solution but hasn’t invested in understanding the parts that make the project whole. As a result, there is a disconnect between the ultimate end user’s needs which results in a changing scope over time.
At any shop, the development team needs to understand core project goals well in order to build a quality product on time. The later the actual requirements are clear, the more the project will be delayed. Specifically, like with any technical project, if the blueprint or architecture is vague or misinformed, even a small change at the end of a project will require costly (both time and spend) delays. This is primarily caused by a lack of formality in the scope definition process or by different members of our partners’ team having different understandings of what is planned for the project.
2. Poor initial project estimation
Before kicking-off a project, most development shops have several meetings with a partner, reviewing and documenting all requirements and drafting out some sort of scope document. When a shop speeds along this process or provides otherwise insufficient information, a project may end up hugely delayed as the development team struggles to understand the true scope of a project.
Another common mistake occurs when the developers and designers who will actually perform the work are excluded from the estimating process. Often estimates are put together haphazardly in order to secure a contract or make a project more attractive to the partner but actual hours spent during development lead the project to be behind and generate potential revenue loss due to potential penalties.
At FarShore, our first exercise with a partner is a “Phase 1.A” engagement. During this process, we create a functional specification document with high-level descriptions of every feature that will need to be developed, designed, and tested. By doing this, we are able to provide a very accurate estimate for work, thus eliminating delays due to estimation errors. This document eliminates issues caused due to unclear vision or estimation.
Our Phase 1.A Engagement helps FarShore’s development team solidify technical details with our partners.
3. Adding to the Scope
I just recently saw this in a project when we switched one of our partners to a different payment model. Though we added 2 additional developers to speed things up and deliver the desired features for this particular project, we still saw a delay.
This is counterintuitive; adding more developers, it would seem, could only speed up the project. Adding more resources to an already delayed or changed project, however, often causes additional strain on the developers working at full capacity, resulting in lower overall team performance, according to Brooks’ Law. There has to be a solid level of organization and management to justify bringing additional developers on board, which brings us to my next point.
4. Poor project tracking and management
When a project is managed poorly, delays will occur. If there is a solid project plan covering all risks, however, delays in the delivery schedule should be minimal.
At FarShore, we use Gantt charts, elaborate project plans, and roadmaps to mitigate project delays. We also employ issue-tracking tools that force the whole team to be more organized, and issue resolution is addressed frequently so most important tasks are handled in a timely fashioned manner.
FarShore uses an internal ticketing system called Harbor to improve our response to partner issues.
5. Leadership and governance
Project Management is a delicate process. If the project manager lacks interpersonal or organizational skills, this can result in an inability to take full project ownership and resolve hands-on issues as they occur. These traits can also make it hard to to bring people together and make things happen. Lack of experience might also lead to selecting the wrong resource for a certain role.
Certain project managers have a hard time finding the right level of oversight where they either start to micromanage the project (causing the team to become demotivated) or fail to track things sufficiently closely (allowing the project to run out of control), thus getting delayed. At FarShore, we remedy this problem by hiring Architects and PMs who have years of experience both managing and being managed.
For an IT project to be successful, it isn’t always enough to have a good project plan and have good organizational skills to deliver a high quality product. To avoid project delays, a development shop has to make sure it has set the right requirements, created an achievable plan and roadmap, and put strong project leadership in place that can take full ownership of the project.
As an Architect myself, I would say that the most important part of project management is communication. I commit to be completely honest with our partners when I realize that the project is getting off track, and provide solutions or feedback in order to ensure on-time delivery.
Interested in learning more about our Architect-based project management process? Reach out here.
