Against the Clock: Deadline Rescue Tips for Product Owners

Imagine this happening - a serious threat of missing deadlines looms over your project. For an entrepreneur developing an app, the consequences can be very serious. At the very least, this means overspending the budget, but it's usually much more than that.

This can also be forever missed opportunities to participate in a significant industry event, which the release was timed to. Or undermined trust of investors and partners, disappointed user expectations, and marketing efforts gone to waste.

All these prospects are extremely unpleasant - which means it's time for a crisis plan. What does it consist of? This article outlines, briefly and to the point, the specific steps that help quickly take control of the situation.

Step 1. Quick Retrospective - What's Holding Back Development?

The first step is to understand the situation. What went off track? What was overlooked when setting deadlines?

Our experience shows that in most cases, one of three things is revealed:

1. Developers overestimated their capacity. This led to setting unrealistic initial deadlines.
2. Developers are struggling with unexpected additional work. This could involve additional features the customer envisioned during the development process, a phenomenon known as scope creep. Or, a technical problem no one anticipated might surface. Alternatively, an external event, like a policy change by Google, could demand modifications.
3. Much of developers' time is consumed by reworking. Constant customer feedback during the workflow, indicating flaws, is a usual practice. But in an optimized process, such revisions are minimal. If excessive, they can greatly delay and add to the project's budget.

Having pinpointed the problem's core and grasped the situation, it's now possible to proceed with decisive actions. This generally involves a universal tactic comprising 5 key steps.

Step 2. Facing Reality - What's Achievable by This Deadline?

The only way to realistically estimate how long a task will take is by relying on the team's actual experience, based on the time similar work has taken before.

Therefore, an experienced team means reduced risk, having already navigated these tasks before, understanding the hidden challenges, and knowing the right amount of buffer time to prevent slowdowns and unexpected issues.

Setting unrealistic deadlines is more common among inexperienced teams. Apart from misjudging timelines, they also make additional errors that worsen the challenge of adhering to deadlines:

• Falling into the trap of overestimating their skills.
• The temptation to assure the customer of quicker completion.
• Rushing work, leading to technical debt - minor oversights that can grow and eventually stall the project.

So, how can we accurately gauge what the team can achieve within the established timelines? - Draw from the experience of this very project. Confront reality and estimate how much more can be done if development continues at the current pace. Or at the pace that can reasonably be anticipated after we've done everything in our power to speed it up.

Step 3. Reexamining the Backlog - What's Crucial for This Deadline?

We must identify the features that the application cannot survive without at the time of the deadline.

This is far from easy - after all, we want only the very best for our users. We've invested so much care and effort into considering all these features - they all seem incredibly important, and discarding any of them feels almost physically painful. But it's always like this; regrettably, it's an essential part of the app development process.

Developers joke that every entrepreneur who walks through their door wants to create exactly three times more features than we have resources for. And this task of dividing "must-haves" and "nice-to-haves" arises right from the first conversation - there's no escaping it in any project.

How do we decide which features are essential and which ones we can skip for now? - Special optics may help. Let's consider: what would be more unfortunate, missing the deadline or launching the app now without this feature? After all, we don't have to completely discard it - just delay it until the next release or implement it in a simplified form.

In this manner, we're choosing a set of tasks that the team really can tackle. Also, remember to account for the time required to solve any technical problems, if they exist.

Step 4. Confronting Inefficiencies - Are We Facing Extensive Code Reworkings?

When the customer sees the completed feature, they may realize it could have been done better and request changes. Sometimes, even the new version needs improvements, leading to repeated revisions. Eventually, the feature takes the shape we want, but the cost is rewriting the same code multiple times, which is a waste of resources.

So, what are the ways to decrease this inefficiency caused by continuous reworking? It's the primary objective of various software project management systems. This is why the industry commonly adopts short, 1-2 week iterations. Developers work in small portions and don't progress further until the customer confirms everything is OK. This approach ensures that if an error slips through, the rework required is minimal.

This tactic has proven its effectiveness. So, what could go wrong? Let's discuss the most common scenarios.

Code Reworkings Due to the Absence of App Design Mockup

In the absence of a designer on a project, developers resort to using pre-made design elements from a library for app creation. If customers detect visual imperfections like colors that don't go well together, they often request adjustments.

Of course, it's fairly simple. The main problem is it requires time. Developers are missing convenient design tools that would allow them to quickly generate various page designs to offer to the customer. They can only randomly alter colors, rebuild the code, and hope for the best.

When you realize developers lack the designer's trained eye for color harmony, it's clear app appearance issues will recur, resulting in significant time wasted on revisions.

Code Reworkings Due to Late-Discovered Bugs

It is assumed that each new code build, delivered weekly, will be tested immediately - either by a QA engineer, developers, or the customer themselves. In this way, any identified bugs can be quickly addressed before proceeding further.

But sometimes, the customer prefers the QA engineer to join the project only before the release, to test the entire app at once. As for the developers and the customer themselves, they don't have enough time for thorough testing during the process. As a result, bugs are discovered late when fixing them requires significant code rework.

Code Reworkings Due to Insufficient Input Info

It's not uncommon for developers to receive tasks that are vaguely, ambiguously, or incompletely formulated. In these situations, they'll attempt to seek out the missing details from the customer. However, this may not be feasible if the customer cannot provide prompt responses.

In situations like these, developers have no option but to resort to guesswork, and any inaccuracies translate into the need for rework.

How to Combat Code Reworkings?

• Handing off design, testing, and other non-programmer tasks to the appropriate professionals. The developer's time is the most costly resource - quite literally. Their hourly rate is much higher compared to that of a designer or a tester. So, if it's feasible to decrease the occurrences where developers are compelled to rework by involving these specialists in the team, you are saving, not the other way around.
• Refining feature requests prior to their submission to developers. As an example, a potential feature can be visualized as a schematic representation of app screens or even as a detailed prototype. This allows you to evaluate and dismiss unsuitable options without the need to physically develop that part of the app.
• Dedicating extra time to address developers' inquiries. Just 15 min a day for a brief call or messaging response can make a big difference. Developers will be able to ask instead of guessing, and everything will be done as per your wishes the first time - it proceeds significantly faster and at a lower cost!

Step 5. Considering Team Extension - Is It Worthwhile to Involve Additional Developers?

The expansion of the team is the last resort, usually reserved for situations where there is no other way out. Its drawbacks are obvious - it increases the project's cost. Additionally, it's essential not to forget that newcomers will need time to understand the app, and initially, they may not speed up but rather impede work by asking questions.

However, if, after a detailed analysis, you've determined that the team won't be able to manage the required amount of work by the deadline, the only solution is to bring in extra developers. Is it worth doing this - one can only say after considering each specific case.

Step 6. Considering Project Audit - Is It Time to Seek External Help?

There are no teams that never encounter problems. Professionals are aware of this and, moreover, prepare for problems, always having an emergency plan. When facing the risk of missing deadlines, how professionally does your team perform?

When they endeavor to hide the truth, when their words don't correlate with actions, and when project issues persistently plague despite numerous attempts to take control - it might point to developer incompetence. In such a case, improving the situation from the inside is a long shot.

There is a common scenario that unavoidably causes project delays:

1. Developers promise to meet obviously unrealistic deadlines and budget to win the project.
2. They assemble a team comprising juniors, lacking adequate guidance from seasoned developers, to stay within budget.
3. The development starts off swiftly, to the customer's satisfaction, but this speed comes at the expense of ignoring code quality checks.
4. Sooner or later, the moment arrives when the accumulation of half-done work hits critical mass. It's a struggle for even the skilled to manage this mess, and for newbies, it often results in a dead end, with progress either inching forward or grinding to a halt.

The only escape from this dead-end situation is to switch teams. And the first step in saving the project is to suspect this problem and then verify your suspicions by consulting with trusted independent experts.

Final Thought - Prevention is Always Preferable

The steps we described are the same ones we personally use when project deadlines are in jeopardy. All that's left is to add one more thing - you don't have to wait for a crisis to strike. The optimal deadline crisis plan is the one designed to preclude crises.

It's both possible and advisable to apply this algorithm continuously throughout your project, reducing the likelihood of facing issues.

At the end of every weekly iteration, we stumbled upon something new. And before planning the next iteration, it's necessary to absorb this newfound information into the plan.

Is everything on schedule? How would changing our approach to this feature impact the backlog? We resolved this issue, but it could arise with future features; shouldn't we spend time addressing the root cause? Are we excessively reworking, and how can we cut down on this?

In a capable team, this preventive work naturally blends into the development workflow.

Here're the features of our universal development process that help us effectively avoid delays in most cases:

1. Short, one-week development iterations. Small, new app builds are immediately delivered to the customer and tested to ensure everything is fine, so we’ll not face major overhauls in the future.
2. Effective communication mechanism with the customer, including a verbal briefing on the task every Monday, ongoing message exchanges for any clarifications throughout the week, and a verbal briefing on the completed feature on Friday. This allows developers to hit the target with minimal revisions.
3. Daily reports that offer full transparency in the development process. The customer spots schedule delays at once.
4. Weekly checks on schedule adherence. Every Monday at our planning briefing, we check if progress matches the plan, whether the workload has increased, and if there's a need to revise the backlog.
5. Appropriate experts handle all work unrelated to programming. Designers, QA engineers, and business analysts handle all the support work, freeing up developers' time.
6. Strict code quality checks. This ensures that the app has the robustness and versatility to expand infinitely without being hindered by the limitations of half-baked features.

Need advice on how to straighten your project? We'll take a fresh look at the situation, apply all our experience, and make every effort to assist.