Posted on

NO_symbolHello all – BobtheBA here. Sometimes we can be inspired by the littlest things like a bee, a mosquito, or a play on words. Such was the case for me last month in all three examples, where the last of which I was inspired by one of my students who accidentally substituted “illiciting” for “eliciting” during a class exercise. We all knew what was meant and in class spelling does not count (which is the beauty of it happening during training – a safe environment!). However, in that moment I was immediately drawn to the concept of illicit requirements and what that might mean. Illicit is an adjective meaning “contrary to accepted morality or convention”. Is it possible to have requirements that do not fit accepted convention, i.e. “illicit” requirements? Absolutely!

So what would make a requirement illicit? Let’s explore this short list of illicit requirements.

1. Requirements that are not in scope. It is very important when conducting our elicitation that we guard against scope creep (BABOK® section 3.2.4). Tracing requirements back to the business goals and objectives will help us validate whether the requirement(s) should be included or not. If we are eliciting and documenting requirements that are not in scope they are by their very nature illicit. I have run into this very issue three times in the last month where BAs have been eliciting and documenting requirements that are out of scope. Requirements that were not generating new ideas for business or addressing current business needs. A considerable amount of resources, project hours and budget were inappropriately used.

2. Misunderstood requirements. It is very important that we have set criteria to ensure the quality of our requirements. Our requirements should be cohesive, consistent, complete, correct, feasible, modifiable, unambiguous and testable (BABOK® section 6.5.4). If the requirement has any ambiguity it fails. Ambiguity can lead to misunderstanding. Additionally, the requirement must be communicated (BABOK® section 4.5.1) to bring our stakeholders to a common understanding. If we communicate that ambiguity the implementation of the solution could be adversely affected because our requirements are misunderstood by our stakeholders (BABOK® section 4.4.2). This can lead to rework, increased costs, increase or decrease in resources and more. Misunderstood requirements are illicit requirements.

3. Requirements that jump to the solution. After we have elicited requirements we document the results which will include stated requirements and stakeholder concerns (BABOK® section 3.3). Stated requirements describe the stakeholder’s need from the stakeholder’s perspective. We must be wary of technical design in sheep’s (requirements) clothing. If we immediately jump to the solution we may ignore the stakeholder need or simply take away from their perspective which can lead to a design that will not cover the true need. Technical design(s) disguised as requirements are illicit.

4. Gathering requirements. Okay, while technically not an illicit requirement in itself, I find this to be one of the contributing factors to why requirements end up being illicit in the long run. The idea that we “gather” requirements is contrary to “elicit”. Elicit means to draw forth or bring out (something latent or potential) or to call forth or draw out (as information or a response). Gathering requirements as a term is more synonymous with simply taking in and documenting what is heard which I would call the job of a scribe. BAs are more than just scribes. Scribing what you hear without true elicitation and active engagement of your stakeholders in defining requirements (BABOK® section 3) which could be a root cause of illicit requirements!

Well I hope that you have the opportunity to discuss these things during some business analysis elicitation training in a safe environment but if not, be aware that illicit requirements do happen. Do you have other examples of illicit requirements? Do you think there is ever a time when illicit requirements actually work? I am all for breaking the rules, taking risks to innovate and in general push boundaries as long as we truly meet the needs of the business. What do you think? Yea or nay?

2 thoughts on “Illicit Requirements

  1. I have to question your summary of item 1. While I agree that we should not spend a significant amount of time on out-of-scope requirements, listening to what the business wants to do in the future is not always a waste of time.

    While these requirements should be identified as out-of-scope for the current project (we had a section called “future enhancements” where these were listed), and we usually left them high-level, not spending a lot of time getting to the details and making them testable, they were often a good view into the future of the system. By giving us a better idea of where the business wanted to go in the future, it also gave us an idea of potential challenges to the architecture.

    In some instances, these future requirements led us away from an architecture choice that would not have supported these enhancements and toward one that would be more scalable or flexible. If you know where your customer is headed in the next few iterations, even though they may not apply to the current project, it can help your technical team make better decisions and judgments with the current project.

    I’ve seen too many projects take longer than necessary because the architecture needed major re-work since no one knew the direction the business was moving.

    • Hi there! Thanks so much for responding and offering your comments. Sharing is so important. You know I find that one of the hardest things about a 500 word blog is being too succinct at times for my own good (lol). In my old job we also used a “future enhancements” in our documents as a way of capturing ideas of the business that could be used in the future. In fact, it was a process that I had to push and many people did not like taking the time or the idea of doing it. So if we both agree that this process works what was I really trying to say? Beware of spending too much time on these types of requirements. In the three instances I cited, it was not a mere case of capturing ideas or insights into the business mindset. The BAs were spending hours and hours eliciting and documenting things that were completely out of scope. Hence – illicit. So it is one thing to capture a requirement that is not in scope and document it in your future enhancement section and another entirely to elicit, document, prototype, process flow and data model entire sections of requirements that are out of scope. Thanks again for your comments and keeping me on track!

Leave a Reply

Your email address will not be published. Required fields are marked *

PMBOK, PMI-PBA, PMP, PMI-ACP and CAPM are registered marks of the Project Management Institute, Inc.