We all know the phrase, “Diamonds are a girl’s best friend,” right? Maybe it conjures images of Marilyn Monroe in Gentlemen Prefer Blondes, but what does it have to do with business requirements?
The perfect diamond has specific qualities, what experts call the Four Cs (cut, color, clarity, and carat). For me, as an IT project manager at GovWebworks, this parallels something else dear to my heart. My own version of the Four Cs (complete, compliant, clear, and concise) have become my best friend when compiling project requirements
Why are business requirements important?
When I’m in the role of Product Owner, I’m passionate about helping our clients solve business problems and implement solutions that really help people. However, I can’t just ask, “What do you want the system to do?” and expect that the answer will be clear enough to design and develop a solution to meet their needs. I first must gain an understanding of the overall requirements of the project:
- What’s the business problem?
- What results would an effective solution deliver?
- What is the value of the solution to your organization?
It’s important to remember (as cliche as it might sound) that business requirements will make or break a project. We work on many fixed-bid projects in the public sector, and they are destined to fail or go over budget if business requirements are not properly captured.
Here are some of the potential cascading problems that can arise when there’s insufficient clarity around the overall goals and requirements:
- The wrong features are built, and the business problem isn’t solved – “Wait, I can’t edit content on this web application you built for me?“
- Money and time is wasted, and the business may not get the opportunity to solve the whole business problem – “We already spent all of our budget for this fiscal year.”
- Trust and reputations are harmed, the project team loses momentum and confidence in their ability to deliver results is diminished – “We can’t deliver services with this product in the way we need. You’re fired!”
I find the best way to head these issues off early is through the process of gathering crystal-clear business requirements.
The Four Cs of business requirements
So, how do you know you have documented the perfect requirements? The following are the Four Cs that I like to check against.
1. Complete
Carat is the unit of weight for diamonds. The more carats, the more valuable the diamond. With requirements too, the more weight (in term of details) they have, the more valuable they are. That’s why I always strive to make them as complete as possible, including both explicit and implicit needs.
Explicit requirements are the easy ones. These are detailed in the RFP, in discovery sessions, over email, etc., and expressed through existing documentation.
Implicit requirements, on the other hand, are much harder to capture. These may not be told to you directly. Stakeholders either assume you already know, or they can’t imagine an alternative process. Complete requirements are best realized and captured as you work on user stories with business stakeholders and your team. During the process of walking through business problems, I learn about the hidden requirements necessary to design the best solution.
As Henry Ford is believed to have said, “If I’d asked people what they wanted, they would’ve said faster horses.” To avoid delivering just a faster horse it’s up to me as the Product Owner to draw out the other possibilities from stakeholders, and see them articulated in the requirements. This helps ensure the best final solution.
Failure to capture complete requirements can have serious impacts on the design and development of your solution. At best it means rework or delays in the schedule to accommodate scope changes. At worst, it’s a missed opportunity to deliver meaningful improvement.
Bad Requirement: “The user will be able to log into the application.”
Good Requirement: “The user will be able to log into the application using credentials managed in SAP, where the users’ roles and permissions are established. The same roles and permissions are required for this application.”
2. Compliant
Diamond color actually refers to lack of color, with the most colorless being the highest in quality and value. Perhaps the more colorless (thus, valuable) characteristic of perfect business requirements is that they be compliant. Compliant requirements adhere to state and federal regulations – HIPAA, FERPA, NIST, 508, WCAG, etc. These are the privacy, accessibility, and standardization rules necessary to protect and serve your constituents. They are usually an essential part of the final solution.
To ensure compliance, we strive to educate ourselves around the particular requirements regulating your agency and project. I also document organizational standards and other internal policies and procedures that may not be dictated by regulation. Your own subject matter experts may already have this knowledge, but where it is lacking, we can fill in the gaps.
Obviously it’s vital to ensure you have captured all the requirements in relation to compliance since noncompliance can result, at a minimum, in expensive rework (or even project termination), and worse, in data loss, fines, and legal action.
Bad Requirement: “The web application must be tested for accessibility.”
Good Requirement: “The web application must be tested for accessibility standards Section 508 and WCAG 2.0 and WCAG 1.0 for web based intranet and internet information and applications.”
3. Clear
Clarity is an important C for diamonds in reference to the presence of blemishes (surface flaws) and inclusions (internal flaws). Clarity in business requirements is equally valuable. They should be flawless and in no way ambiguous to your design, development, and quality assurance teams.
Equally, client stakeholders must be able to comprehend the requirements since their approval and sign-off is critical. Document workflow and functionality, as well as any assumptions. Project collaboration tools, such as Confluence, are great for this purpose. They help us store all the project documents in one place: versioned, and complimented with a project glossary, wireframe documents, design files, or any other artifact delivered by the project team.
Agile projects value working software over comprehensive documentation, but there is still a need for the project team to know what to build, and why. The key is to avoid “analysis paralysis.” Once the requirements are clear, the team can begin proving them out with incremental software builds and proof of concepts.
While Agile projects welcome change, clear business requirements are still needed to help stakeholders evaluate and prioritize the backlog.
Bad Requirement: “The user must be able to access all the reports.”
Good Requirement: “The administration user must be able to access the reports page from the primary navigation menu on the web application.”
4. Concise
The cut of a diamond is the work of the gem smith, who hews away the flaws to leave a perfect stone behind. Business requirements benefit from the same refinement process, making them more valuable. Leave out words that don’t add to the understanding of the requirement. Should, would, and could are too passive. Don’t use them. Shall, will, or must are better choices. Pick one, and stick to it.
Substance is also important. Examples, metaphors, or analogies of what you think you are trying to express are not necessary; they only cloud understanding and interfere with the clear C. I also suggest leaving out any words that point towards motivation or bias. “Just the facts, ma’am!”.
Concise requirements help project teams understand the meaning and value of the solution. Quality assurance and user acceptance teams will also thank you since concise requirements make test cases much easier to write, create, and execute.
Bad Requirement: “When a user searches for something on the website, it should narrow choices down when the user selects from those little check boxes on the left hand side that say words that help the user find what they are looking for. I like those. Let’s use that. It’s kinda like when you are shopping, and trying to find something in your size. Yes, that.”
Good Requirement: “The search functionality shall use faceted search to help users refine search results.”
Conclusion
Project success relies on getting as close to perfect as possible with our business requirements. As a result, when we keep the Four Cs front-of-mind, we find that:
- The project gets delivered on-time, and on-budget – sighs of relief all around!
- Business needs are met, and regulatory and compliance boxes are checked
- The right product is built and real value is delivered because end user’s needs are more clearly incorporated into the solution
As Marilyn might have sung (if she’d used my four C’s), “Square-cut or pear-shaped, these Reqs don’t lose their shape…”
I hope you find them useful, and that with a little polish, they can help your projects (and teams) shine.
Do you have your own approach to business requirements? Let us know in the comments!
Contact GovWebworks to learn more about how we can help with your next project.
Alison Schestopol has worked in project management for over a decade and is a certified ScrumMaster and Product Owner. She holds the Project Management Professional (PMP), and the PMI Agile Certified Practitioner (PMI-ACP) credentials from the Project Management Institute. Alison loves working with the public sector to modernize systems and processes and deliver better service. She also enjoys jewelry, but doesn’t play favorites!
This article ran previously on the Scum Alliance blog as The 4 Cs: An Agile Project Owner’s Best Friend – How to craft flawless business requirements for high-pressure projects.
