Respect Requirements Specs: They Can Bite
Yet another article on Project Specifications, I’m afraid. I just heard this week of yet another omission in a specification. Only this time, the dreaded assumptions were the root of the issue. Fortunately, the impact is minimal, so the resolution need not be rushed out the door. It was such a low priority that I would hesitate to call it a failure. Frustrating, certainly.
Disclosure. I use Generative AI tools to help me when writing. From outline suggestions to topics or subtleties, I had yet to think of.
See more articles, posts, and discussions about business, project management, Generative AI and Creative Writing on Medium here. If you have not already, subscribe to Medium. Or follow me here on Substack.
Software projects fail for many reasons, but one of the most common causes is a lack of precise requirements. Without a clear understanding of the business requirements and user needs, it is difficult for the project team to understand what the project must accomplish and how it should function.
Exploring for Spec Sharpness
Whenever an organisation produces a requirements specification for a new function, they will naturally ensure that the specification is complete, accurate, and unambiguous to the best of their knowledge. They will be confident that they’ve covered all bases and aspects of the desired function.
Unfortunately, the exceptions are often missed, the one per cent of the process that doesn’t or can’t follow the normal logical flow of the process. It is always these minority cases that cause the most headaches further down the line, where they’re picked up at the end of the project, usually during the testing and acceptance phase.
But all is not lost; ensuring that the specification of requirements is cold-eye reviewed, preferably before the project has been sent out for tenders, will likely pick up most of these use cases. Most, but not all, the best of us forget these infrequent occurrences. So there will always be the odd occasions when one does sneak through undocumented.
Cutting Through the Crap
Many techniques and methodologies exist to produce the best and most complete Project Requirements document. However, none are 5-minute fixes, requiring time to execute correctly. The most important is to involve all Stakeholders from the get-go. Who are these stakeholders? You may think you know already, from the project’s sponsors to the Project Management team and, of course, the Developers. Maybe one or two end-users should be enough.
Identifying your stakeholders sounds simple, but many times, the end-users are either forgotten or a couple of token key users may be included. A stakeholder is anyone who has an interest in the product or service that’s being produced or provided. They may be internal stakeholders (employees) or external stakeholders (customers, regulators, or suppliers). Every stakeholder has specific needs or requirements that they want to be fulfilled.
Each of these needs must be balanced during the project. Often, stakeholders have competing needs, which can impact the project’s schedule, budget, and scope if not managed effectively. Changes will have a knock-on effect regarding pricing, materials and design, ultimately slowing down the project.
When a stakeholder happens to be your customer, you must ensure that you’re eliciting their exact requirements to deliver your product or service. If the right questions are not asked using the suitable method, you will not meet customer needs, and, in the end, the project may have failed.
Honing Specs through Feedback
There are several ways to collect requirements that vary depending on the type and complexity of the project. There are advantages and drawbacks to each method. It’s best to combine these techniques and avoid taking shortcuts when collecting project requirements.
The project’s success is directly related to how well requirements are communicated, documented, and carried out. A best practice is to include as many stakeholders as possible. No fixed method or technique exists to gather business requirements; it depends on the scenario. For some projects, the Interview technique might work; for others, you might be required to use joint sessions or group interviews.
We can capture and draft a quality business requirements document with the nine requirement-gathering techniques described below. Each requirement-gathering technique has its pros and cons; therefore, we should choose the ones which are the best fit for the project and the situation.
These are the nine common methods that may be used, grouped according to their general importance during the entire project development life-cycle, although several may be applicable at any stage of the project depending on the individual project:
Initial Analysis
- One-to-one Interviews.
- Group Interviews.
- Brainstorming.
- Document Analysis.
- Questionnaires and Surveys.
Initial Analysis and During Development
- Focus Groups.
- Requirements Workshops.
- User and System Observation.
- Prototyping and Wire-framing.
Most of these techniques are focused on the initial requirements analysis and as a constant feedback mechanism during the development process to ensure that the finished product is as accurate and fully functional as possible. Workshops, for example, are exceptionally informative, assessing the several pre-release candidates during the development life-cycle. Similarly, Prototyping is valuable for verifying implemented functionality during development.
From Fog to Focus
We briefly mentioned the roles of workshops and prototyping in clarifying project specifications, but they are equally important during the several stages of development. For example, think about holding workshop sessions as each project milestone is met. They are extremely useful for picking up problems in good time, reducing or eliminating potentially costly rework and delays. Let’s look at two scenarios.
The first and most obvious is when, no matter how thorough the requirements analysis was, there will sometimes be an omission sneaking through the net. It’s better to pick this up as early as possible when there may be no impact on the overall cost and delivery of the project.
I could try and illustrate this with an example, but to do so would only be able to focus on a single industry and ultimately confuse many unfamiliar readers. It’s sufficient to imagine a rarely occurring scenario that was handled manually or with a workaround in the past. The issue has been encountered so seldomly that many users were unaware of the possibility. Fortunately, the issue has finally been identified in good time to ensure it can be handled in the delivered product.
The second and more common scenario is when a documented feature, when implemented, is seen to be inefficient or unworkable. The workshops can help refine the documented specification towards a solution that fully retains the requirement in an optimised format. The stakeholders invited to the workshops are a diverse selection of people, which then dramatically improves any feedback gleaned from the session. The different points of view and user requirements are the most critical resource for any project.
Final Thoughts
Perhaps not the most riveting subject in the world, but one that continues to fascinate. It seems that some organisations never learn and are doomed to repeat the same mistakes repeatedly. It doesn’t help that people move on, leaving for a new position and taking their hard-won experience with them. “Once bitten, twice shy” is a wonderful expression but requires one to be bitten in the first place, unfortunately—deep sigh.
What is clear is that procedures and standard documentation are sadly lacking, which is a shame, as investing upfront in these can save a fortune in the medium to long term. A vital investment, you would think.
See more articles, posts, and discussions about business, project management, human nature, Generative AI and Creative Writing on Medium here. If you have not already, subscribe to Medium. Or follow me here on Substack. The KodifyIT Substack newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. I would appreciate the support; you won’t regret it. 👍
I apologise to my readers for some of the spellings you may feel are incorrect. I was born and brought up in the United Kingdom, and this is the spelling I am comfortable with (Grammarly is happy with it anyway).
It’s very interesting! If you need help, look here: ARA Agency