Predefined product requirements and a limited budget is not as good as it might seem. We have recently completed our partnership with a SaaS company that had those exactly, and unfortunately, the entire project failed.
To not overcomplicate the article and to respect the NDA, I will avoid describing everything in detail. This article is a compilation of lessons we learned from, and hopefully, it will help you to avoid repeating my mistakes.
So, when you get a client with predefined requirements and a limited budget, following the rules will help you to drive value to your clients and end users.
Lesson 1: Roadmap created by developers is a must
Usually, clients want to develop a complicated project and have predefined features to develop. You need to help the client to prioritize the requests, analyze them with developers and product managers, and create a detailed plan of the project, a Roadmap.
How much will it cost to develop a software solution from scratch? It is one of the most complicated questions one can ever ask. Software development is an ongoing process. Thus, technically speaking, the software development price is infinite.
That is why, during the pricing estimation period, it is important to evaluate the product vision and evaluate a definitive scope, aka list of features to be developed. Developers shall estimate everything in detail.
Lesson 2: Document each modification to the initial plan
If the initial plan changes, document every modification, plan everything again, set up new deadlines, make a new roadmap, and agree on a new budget.
While this rule applies usually to project managers, it is better when the whole team follows it. All the decisions and modifications to the requirements must be documented.
Every team member and the client shall understand that any modification affects the final deadline. There might be some minor changes that don't seem to play a big role; still, there’s the accumulation effect, so the rule should apply to everything.
I would recommend having one document (or space) where all the business requirements are registered. Changes can be stored separately as Change Log.
In the project I mentioned, this requirement was ignored. We were overstressed fighting tight deadlines and simply didn’t have enough time to step back and maintain product requirements documentation.
Lesson 3: A new unplanned feature means new deadlines and a modified roadmap
Does your client request you to add a new feature? Set up new deadlines, modify the Roadmap, and document the modification.
Let’s say your client wants to add a priority feature. Update your Roadmap to make sure you, your team, and your client understand the situation.
New features = New deadlines = New budget.
Lesson 4: Automated tests are needed
Write automated tests from the very start.
Plan tests and the time needed to write them from the very beginning. It is never late to start writing automated tests. But it is much better if you write them from the very start.
Otherwise, you will need to perform regression testing. It means that you will spend a lot of time on things that could have been automated.
Automated tests save your time and allow you to deploy changes to master without waiting for QA to give initial feedback. Every unsuccessful production deployment means that the IT team will be working overtime until the issue is solved. The further you omit automated tests the longer it will take to develop a feature.
Lesson 5: No accurate estimates for black box solutions
It is not always possible to give accurate estimates.
You cannot know everything. If you see that the project requires some knowledge and skills that you don’t have, consider it when setting up deadlines. Another option is to indicate these problematic tasks and specify that you would need more time to complete them. Indicate the risks involved, too.
From my experience, I know that it is dangerous to be optimistic in such cases. Always consider the worst scenario to avoid unpleasant situations with the client.
Lesson 6: Include pre-release testing (all its stages) in the project roadmap
Always include pre-release testing in the initial estimate for the projects with limited time and budget.
Every project shall include pre-release testing. Don't ignore it even if you have very specific requirements and deadlines. Plan pre-release testing from the very start.
How many releases shall you plan? I recommend that you plan as many of them as you can. They will give you feedback on every release. You will be able to see the goal and monitor your team moving towards it.
Do not sacrifice testing for new features. Your task is to deliver a quality product, not a bunch of untested features that might not function properly. Your client shall be confident that your team develops features that work properly and consistently.
I would like to mention that it shall not be combined with a weekly Demo to show your team's progress.
Testing involves collecting feedback from your client. Then, you arrange alfa-testing with the participation of other teams in your company. Or you can perform alfa-testing with the friends of your client, for example.
After that, you initiate beta-testing. At this stage, you involve more people. You can get them either by sending special invitations, or you can use your list of users if you have one. Some teams organize a small marketing campaign for beta-testing purposes or ask for assistance from their acquaintances.
Bottom line
All the lessons learned are very logical. But the thing is that when you have loads of work, the deadlines are pressing, and you might not notice many details. That's why, once more, when you are working on a project, make sure you:
- Are absolutely clear with your client and team.
- Document all the business and technology logic.
- Create a Roadmap and aren't afraid to modify it.
- Plan every stage carefully.
- Don’t forget about testing
It will help you to avoid the gravest mistakes and lead your team towards success.
Latest articles here
