As January comes to a close, we hope your 2024 is off to a great start and you’re already kicking butt at your new year’s resolutions.
If you are the kind of person who sets resolutions each year, we can’t help but wonder about your process. Do you write the list down somewhere you can reference frequently or just keep the list in your head? Do you have a process for creating your list, then holding yourself accountable and tracking your progress – or do you have an ad-hoc approach? If you’ve found a practice that works for you, we would love for you to share it with us in the comments!
No matter how and what time of year you set goals for yourself, clearly defining your intentions and tracking your progress is essential to success. We know from experience that ambiguous new year’s resolutions, especially those not written down, often change or get forgotten as time goes on. For example, the common resolution of “work out more” could mean so many different things – be active for 20 minutes per day, go to the gym 3 times per week, train to run a marathon, etc. On January 1, you could mean go to the gym 3 times per week, but months later, you could forget what you initially meant and decide it was just once per week. How is it possible to hold yourself accountable when you’re not exactly sure what your goal was to begin with in the first place?
Something we know to be true both in the real world and software world is that if something can be misinterpreted, it will be. Don’t let your future-self misinterpret the goals you create today. Set yourself up for success by clearly defining and documenting your intentions. If you fear your new year’s resolutions are too vague, it’s not too late to revise them – BE SPECIFIC!
New Year’s Resolutions Requirements
Similar to how resolutions outline our visions and goals for each year, requirements do the same for software projects. However, unlike your resolutions which are personal, requirements are read by an audience of individuals with a wide range of technical knowledge and understanding (business users, product managers, business analysts, UI/UX designers, developers, and testers) – this means leaving no room for interpretation is even more important. Since requirements are the foundation that all code is built on, getting them right the first time is crucial to preventing unnecessary rework, delays, and costs.
To see how poorly written requirements can be interpreted differently across various departments of an organization, check out the cartoon below that depicts the development of a tree swing:
Although requirements sometime seem like a technical task that can be left to software teams, we encourage software leaders to reconsider their involvement in assuring they are well written and unambiguous. To learn why, read our blog: Why CTOs frustrated with rework should care about requirements.
As we embrace this new year, let’s not just strive to achieve our personal resolutions but channel that same energy into our projects. Writing good requirements isn’t just a tradition for us – it’s a commitment to project success. Here’s to a year filled with well-crafted requirements, successful projects, and leading our teams to excellence. Cheers to a fantastic year ahead!
If your requirements are causing unnecessary confusion, bugs and rework, we can help – let’s chat.
