Revisions are necessary in order to make software great.
But when revisions aren’t made strategically, they can threaten project timelines and budgets — or even derail a project entirely.
At Worthwhile, we take time before beginning a software project to explain how the revisions process works, and to make sure a client understands before they sign on the bottom line.
Here are some principles that our team and our clients have found that lead to more effective revisions, both for clients giving feedback on software projects and for internal software development teams.
Early Is Better Than Late
The flexibility of software means that a change can be made at any time. But it’s usually better to make changes as early as possible.
When you make changes early in a project’s development cycle, it affects fewer aspects of the project. As a result, it requires less time to implement and test these revisions.
Imagine building a house. It’s easier to make changes before the drywall is installed than it is after. And it’s easiest to make changes when you’re looking at blueprint drawings, before the first nail has been hammered. The same is true when developing a web app, mobile app, or other custom software.
Early revisions also create less risk than late ones. Because software is interconnected, a late revision can affect sections of software beyond the view you’re revising. This means that making a change requires additional tests in order to avoid creating bugs by making a revision.
All Is Better Than One
When you sit down to make revisions, a best practice is to provide all your feedback at once, rather than in drips and drabs.
This takes discipline, especially for a client that’s not used to testing software. It takes time and focus to do a thorough round of testing to provide all feedback at once.
But this discipline brings benefits.
- It leads to more clarity about where revisions are.
- It creates a clear distinction in terms of moving on to the next milestone.
- It keeps the momentum of the project moving in a positive direction.
That’s why we encourage clients to submit one round of revisions for each milestone in development. This focus ensures quality feedback and leads to a more successful project.
‘I Know’ Is Better Than ‘I Guess’
It’s important to draw a distinction in revisions between changes needed to ensure functionality and changes driven by assumptions and opinions.
That’s because your assumptions and opinions might be wrong. And your developer’s assumptions and opinions might be wrong too.
So instead of forcing an opinion into software via a revision, it’s better to wait until the software launches so you can get actual user feedback.
The truth is that your users will teach you a lot about what your software needs. They always do. As a result, it’s important to view uncertainty as an opportunity, instead of the enemy.
Instead of opinion, your revisions should focus on functionality. You don’t need to guess what users might want, but you do need to know that users can do what the software is supposed to do.
Once you get user feedback, you can use actual data to make improvements that aren’t based on guesses. The good news is that your users will be delighted as you continue to roll out features that benefit them by improving user experience.
The Django and Python technology stack provides flexibility to make these changes efficiently. For example, we install the Django CMS to give our clients wide-ranging control over the words and images on their websites and web applications.
A strategic approach to revisions will lead to a more successful and more timely project launch. That’s worth the effort and focus during the revision process.