It’s that time of year, where our thoughts turn to the holidays…the holiday parties, the shopping, the lights, visiting with family!  For many organizations, the end of the year tends to be quiet on the IT front, for no organization wants to risk introducing problems into their production environment at year end.

So as I look back at this year on what was accomplished, I tend to do a mini-retrospective on my year…what went well, what did not, and what can I improve?  Thus looking at those items to improve, I’ve come up with a list of New Year’s Resolutions to focus on for next year:

Use the ROM – Requirements Object Model

Understand what the business problem is trying to be solved for any project that I am working on.  This can be difficult to get on any project, but essentially, every project should be attempting to solve some business problem.  Usually these problems are rooted in money.

Once the business problem has been identified, the business objectives can be defined.  And from there, the strategy to meet those objectives can be defined.

The benefit of understanding the business problem is then you are developing a solution that will provide a return on investment.  No one wants to do a project just because, there should be a purpose and it should be valuable.

Write Clear Concise Requirements

Of course I always try to write clear, concise, testable requirements.  But what seems to be clear, concise and testable to me may not be in reality.  So I always consider this an area of constant improvement.

How can I ensure that I am writing clear, concise, testable requirements?  Reviews are always a great idea.  Get another set of eyes on what you have written.  I like to get a peer to review my work before sending it off to my client, and preferably, someone who is not very familiar with my project.  The less they know the better.  For if they can understand the requirements, and then I feel like I have done a decent job in getting them document.

But these peer reviews do not take the place of reviews by the business.  They are the ultimate authority, and definitely need to be done to ensure correctness and validity.

One final word on this topic and it may sound silly to state this, but I see many mistakes made because of it:  spell check does not replace proof-reading.  Spell check can definitely help you ensure that the words are spelled correctly, but it cannot help you ensure that you have the right words.  I’ve seen embarrassing notes go out…the words were all spelled correctly…but one wrong word could mean big trouble!

Ensure Better Transparency

Transparency means being as clear and upfront with regards to the progress and status of your project.  One way to help ensure transparency is to provide status reports.

I try to send frequent and consistent status reports help provide information on how the project is progressing to those who need to know.  These reports should include information such as what was accomplished that week, what was not and why, what is planned for the next week, and any risks or issues that have arisen.  This information helps me keep a running record of what has happened in the project, and can help refresh memories when people have forgotten what has been done.

They do not have to take long to create, especially if you create a template, and if you are consistent with sending them out, they become part of your routine.

Do Requirements Traceability

I try to ensure that all requirements map back to the stated business objectives.  This helps ensure that no business objectives have been missed, but also helps prevent scope creep.

While we all know that traceability is a good thing to do, it is laborious and tedious to do, especially outside of a requirements management tool.  As requirements are written, reviewed and edited, maintaining traceability can be very difficult.  I try to wait until later in the requirements definition process can save some work; however, I have to be careful about waiting too long.  If I wait too long, then I may miss a chance to add missed requirements, or to prevent scope creep.

Use Models

Finally, I need to use various models to describe requirements.  There is no one model that can demonstrate a set of requirements fully and completely.  A combination of several models allows the requirements team and development to see the requirements from several different perspectives.  It helps us gain a full understanding of what is being requested, and helps ensure that there are few misunderstandings.

While it may be easy to say “use models”, it can be a challenge to get an organization to do so.  People get comfortable with their current process, and can be reluctant to change.  They may resist the introduction of anything that is perceived as more work.  To get around those that are resistant, I try to constantly show how the model s adds value.  I remind other business analysts and product managers ultimately, the models are not for them…they are for the business to confirm their requirements, and they are for development to get a full understanding of what is desired.  We are in the business to help others clearly define what they need, and to help deliver those results.

Finally, I would like to wish all of you healthy, safe and happy holiday season!

Want more on requirements and requirements models? check out our other posts.