Importance of Gathering Requirements
Personal Experince Gathering Requirements:
As a leader in my organization requiring technology changes to software and hardware. The need for good change requirements is an absolute must. I have been a part of many projects with poorly written requirements that caused the result to be over budget and not delivered anywhere within the expected time deliverable.
In my current position as well as my entrepreneurial aspirations I work with business leaders and their teams to understand the problem they are trying to solve. Too often I get requirements that point to a similar product in the market or programming language that may not address the real issue. Many times, the problem they think they have is a result of a different issue not being considered.
This is where poor requirements lead to rework causing time, and scope creep. Especially if the referenced requirements involve contracts and now the contracts must be rewritten to cover the added changes required to accurately solve the problem being addressed. No matter the size of the organization a proper policy and process should be in place to help determine, document, and vet new requirements within an organization to control cost and time overruns.
Case Studies of poorly written requirements:
CASE STUDY 1:
An example would be the leadership of an organization realizing their computer operating systems (OS) are all coming to end of life. The looming deadline the vendor of the OS has established is approximately 8 months away. Leadership could make the case for their technical staff to go ahead and upgrade all the OSs in the organization. This scenario could be a recipe for disaster. Many companies today have lots of customized applications running on their systems and networks. Even small operations have applications with customized settings that work specifically to their operations.
Unfortunately, not all organizations do a great job of documenting and keep available these customized settings. Let's say the technical staff do as leadership asks and upgrade all OSs in place. The upgrade instructions said all files and settings would be safe and maintained during the upgrade. The upgrade commences, systems are rebooted and at first glance all is operational.
Then users start calling in saying they are getting unstable, or wrong information when they try to process their work. Now all technical staff, any developers, and supporting contract staff are frantically working to figure out what was changed from the upgrade. Two options stand out here for leadership to consider. 1. Backout the OS upgrade and hope everything recovers to previous working conditions, or 2. Allow the technical teams to continue to troubleshoot and find a fix.
How could this scenario have been handled better? The technical team responsible for the upgrades should have met with the business teams to understand the impact on the organization if something goes sideways. This will help the technical staff understand the importance of understanding all the applications and their settings as they exist. One practice would be to take a week or two and go through all the applications to retrieve the settings as they are configured for the applications today. Then reach out to the vendor of the applications and explain the plan to upgrade all OSs in the environment. If there are changes to the application that need to be considered now is the time to know that. The vendor can provide these and even help with providing instructions to make the changes once the OS has been updated (in my experience - may depend on maintenance agreements in place).
With a better understanding of the applications and their nuances on the servers or workstations the technical staff can build a thorough requirements document that will provide guidance for the project plan. Taking the time to perform these activities upfront can save money, time, and aggravation for leadership and its employees. We have all heard of the nightmare upgrades breaking systems for weeks and cost way more than was planned and budgeted for. In just about every case poor planning and understanding of the real scope and requirements caused the project to slide to the right.
CASE STUDY 2:
A website development project I was asked to consider for an individual. Initially I wasn't sure I wanted to venture into the project as I was already swamped with my current job, teaching at our local community college, and working on a side project for a non-profit. I did agree to meet with the business owner.
His request was, "I need a website for my business that could incorporate my other businesses also." Had I just started to build a website from a template such as WordPress or even a Django site I would only be able to provide a skeleton. What problem is at the heart for the site to address, who is the audience, what content should be presented for the audience?
Instead, I took the time to walk him through a series of questions to understand which of his businesses was to be focused on the site. We concluded that only one business would be represented so as not to confuse his customer base. Then we broke down out of all the potential customers, who were the actual focal customers he wanted to reach. What does that customer look like, how would they use his services, and how would he continue to support them in the future with his site?
Understanding the real problem allowed me to narrow the scope of work and determine his actual needs and best solution to meet those needs. Time and experience have taught me how to help business leaders see the true problem that may not have been obvious from the outset. Being able to assist customers, provide their requirements and realize opportunities for improvements they weren't originally seeing has been my recipe for success.
CASE STUDY 3:
The previous two examples had to do with technology and software/hardware projects. I have always paralleled the work I do with technology to that of the construction industry. Both industries require the need for blueprints, precise use of tools, accurate measurement of services and support (before, during, and after a project). The major difference in software development is we can often start to build a new technology with little financial outlay where in the construction industry requires substantial financial commitment just to buy the materials to start the project.
I brought this up because I had a discussion with a home builder who was talking to me about a project he recently picked up. The client wanted an office building and provided the specifications to which the building was to be built. Knowing the client has spent a lot of money getting the plans drawn up and some of the meticulous design that was on the blueprint. The contractor didn't ask a lot of questions and agreed to do the work. Going from the blueprint and experience in building structures for many years he quickly drew up a contract and provided a price.
It didn't take long for the customer to start asking for changes to the building plans once he could see the building starting to take shape. Putting the ideas on paper and drawing out dimensions are not the same as seeing the building. This started a snowball effect of little changes here and there (per the customer); that were major design changes for the contractor and his staff. This led to at times weeks of redo work to move a wall, or plumbing as the customer realized his original plans to account for certain design considerations.
The contractor confessed that had he taken the time upfront to ask the questions that I asked of the website customer he would have identified at least seventy percent of the changes before even drawing up the contract. The project was still successful, and the customer was happy, but the project ran over by two months, and he ate some of the cost overrun and the customer agreed to the rest.
What Constitutes Good Requirements Gathering:
Before any work should be agreed upon by the business leaders, our customer needs to fully understand the problem. Start with a clear understanding of the problem or opportunity: Before gathering requirements, it's important to have a clear understanding of the problem or opportunity that the software system is intended to address (Casebier, 2023).
- Start by asking what the problem is.
- Then ask to observe what is happening when the issue or requested enhancement need occurs.
- Ask what the impact is if the problem continues without resolution? Who is impacted the most? Are there significant savings if the problem is resolved? Are there current workarounds that are being used to address the issue now? How are these workarounds affecting employee morale and performance?
- After asking the above questions and any others you think of relative to the project being requested consider what was observed. Think about what could be causing the issue they want to solve. Is there another upstream problem that needs to be addressed that would in effect resolve this need altogether? All these discoveries need to be thoroughly documented and presented back to leadership.
- Working with the proper teams now gets all the questions and answers, observations, and potential other findings from your discussions with the customer or stakeholder. Work with those that will develop the solution to make sure you have not missed something important that needs to be considered for the project.
- Present the full requirements documentation to the respective parties and get agreement on the actual work to be addressed.
- Draw up a project plan complete with stages of design, development, and testing to include deliverable timelines. This will help your client to understand what they agree to, and the impact of any changes they want to make. Making it easier to show scope creep (project timeline increase to the right, additional work not planned for, and possible cost impacts) that the stakeholders or client need to agree to before that work is considered.
Establish a process for requirements
Too often we wait until a need exists to create a policy or procedure. In my experience this usually does not bode well for teams or customers trying to complete a project. No one likes for the rules to change or suddenly pop up in the middle of working to complete a task. Yet it happens usually because the proper attention to the procedure or process wasn't applied in advance.
Take a little time to build out a model for requesting changes. A change management process is imperative for large organizations but is no less important for smaller companies too. What worked for a single person operation often breaks down once more decision makers and staff are involved on a project. Create a process for who can make requests, who vets the request for approval to even be considered, how are requirements gathered and prepared for consideration, and create a template that captures the most critical components of information and has an area for comments should anyone in the vetting process have ideas that need to be captured.
Setup meetings with the technical teams, business teams, and stakeholders at set intervals to work together honing the requirements so the actual scope of work is designated. At no time should a contracted vendor agree to a contract that is not backed by solid requirement statements specifying the exact scope of work to be delivered. Any wording that says a company and its leadership can adjust or change these requirements as needed should be followed by a clause that specifies there will be an adjustment to the contract to account for the increase in scope and cost of changes.
Conclusion
Requirements gathering is not a trivial aspect of a project. I hear all the time with the acceptance of Agile Methodology, "we can just change the project as we go." This is not the purpose of Agile to replace the need for thorough thought-out requirements. Organizations and their staff believe they can just make a change as needed in a project. In many instances do not deliver their projects on time and on budget. This is not to say that changes to a project should not be considered. Just the contrary is true, but changes should be kept to a minimum even with Agile Methodology.
Thinking through the true need, developing a solid requirements statement and documentation, and planning of the project the scope of work should be sound for most if not all the progress of the project. Proper management of projects whether technology, construction, or any other industry provides improved stakeholder and customer experiences. With improved experiences comes recommendations to other future clients for your business and repeat services to the stakeholders you have provided services to.