“Just one more thing,” says the person in charge of the product specification.
Those immortal words will strike fear into the heart of anyone who works in product development. This is because the combination of the word ‘just’ with the phrase ‘one more thing’ rarely results in anything other than a complete derailment of the development process.
Blame shouldn’t be levelled at the person or team behind the specification, either, because there can be all manner of factors behind the product development process suddenly careering towards it’s deadline uncontrollably.
Similarly, some deadlines are tight from the start, with a desire to please or impending financial end of year the driver for saying “yes”, when a “no” might be more appropriate.
This post assumes that you’ve been dealt a tight deadline for one reason or another. There’s no getting out of it; you simply have to face up to the fact that the product needs to be developed by the given date.
Here’s how to do just that without sacrificing product quality or client relationships.
Step 1: Focus on clarity when defining the product
Nothing beats a clear product definition. No matter how tight or loose the deadline, if the definition from which everyone is expected to work is in any way woolly, the project will be derailed at some stage.
Consider the fundamental problem to be solved, the overarching goal and explore every possible roadblock. Leave nothing to chance.
Step 2: Don’t get lost in systems
You probably rely on some form of project management system, and it may well be incredibly powerful, but if you get lost in its intricacies for a project with a tight deadline, you’ll be wasting valuable time.
Instead, focus on creating a simple, prioritised development roadmap. Break it down into bite-sized chunks, and assign each subtask to the relevant team with clearly defined end points and expected ETAs.
If this means ditching the system for a spreadsheet or whiteboard, so be it!
Step 3: Define the metrics
You’ll only ever be able to meet a deadline of any kind if you’re able to rely on solid, measurable statistics and data while the project is being undertaken.
To do this, you need to define clear metrics that the team can rely on throughout the lifecycle of the project. The most common are the following:
- Schedule variances. With your bite-sized subtasks created, any variances in their schedule or ETA should be easily measurable.
- Cost and resources. Providing you have budgeted from the outset, you’ll be able to keep a very close eye on costs and the allocation of resources. Watch out for any that appear to be spiralling out of control.
- Scope change. The big one. Are requests creeping in that weren’t present from the outset? Create a culture of openness, where every project stakeholder feels empowered to speak up when they spot a scope change.
Step 4: Meet daily, Scrum-style
‘Scrum’ is a technique commonly used by software development teams, and while product development needn’t delve into it’s many intricacies, it can benefit from one of the most valuable aspects of this brilliant productivity enhancer.
Hold daily meetings, first thing every morning. Ensure they only last a maximum of fifteen minutes and conduct them standing up. The purpose is for everyone to provide a brief run through of what was achieved the day before, what’s planned for today, and any potential roadblocks that have been discovered.
Step 5: Don’t hide the development plan
A common mistake is to spend considerable time crafting a brilliant development plan, only to effectively consign it to the history books by filing it away when the project starts.
Instead, ensure it’s visible at all times by stapling it to walls, leaving it on desks and reminding everyone that it should be their guiding light throughout.
Step 6: Assess the value of unexpected scope changes
Scope changes will arise - there’s no escaping the fact. For that reason, the team needs to be capable of assessing each one subjectively.
Will the proposed change benefit the project enough to either extend the deadline or increase resources to meet the existing deadline? Is it superfluous or more appropriate for a second iteration of the product?
This step demands tough questioning and an entirely honest approach to product specification. Never accept scope changes without a thorough review first.
Wrap up
The steps presented in this blog post aren’t fool proof, nor are they guaranteed to prevent project overrun, but they will help you meet those deadlines which are unavoidably tight.
