Development Protocols – Hunters Consulting

The Inquiry: Development Process Framework

Recently, I was posed an intriguing question:
“1.12.2 Development Process: A streamlined framework detailing each step, from task reception to deployment and documentation. With clearly defined roles, responsibilities, and escalation points, how can we ensure smooth operations and impeccable quality control? Do you, by chance, have a development process to share?”

The Response:

Certainly! It’s simpler than you might think. However, a brief disclaimer before we dive in:
Every organization and development team will have its unique spin on the development process and associated protocols. What I’m providing below is a foundational framework, a starting point if you will, that can be adapted to fit specific operational nuances.

Blueprint for Development Project Execution and Establishing Protocols.

To truly understand development protocols, we need to delve deep into them. So, let’s embark on this journey together and demystify each step!

Project Development Flow:

Business Needs and Stakeholders:
Stakeholders: They are responsible for pinpointing the primary business needs.
Project Owner Nomination: Based on the identified needs, stakeholders appoint a project owner. This individual has two primary responsibilities:
Ensuring comprehensive and accurate collection of all business requirements.
Possessing the authority to make decisive calls related to the project, without necessitating consultation with the stakeholders.
From Business Requirements to Technical Specifications:
Requirement Establishment: Once the business requirements have been solidified,
Collaboration: The project owner, armed with these requirements, joins forces with a technical expert or solution architect.
Objective: Together, their aim is to draft the necessary technical specifications for the project.
Drafting Technical Specifications:
Clarification: After thorough discussions and clarifications with the project owner,
Formulation: The solution architect constructs a technical specification rooted in the given business requirements.
Review and Alignment Meeting:
Engagement: The project owner and solution architect come together, potentially across multiple sessions, to scrutinize the drafted technical specification.
Objective: The paramount goal is alignment. The proposed technical solutions must seamlessly complement the established business requirements.
Cautionary Note: Overlooking this phase poses a considerable risk. Should the architect’s output fall short of the project owner’s expectations, this could trigger substantial modifications or even total rework.
Establishing Ground Rules for Change Management:
Engagement: Within the alignment meeting, the solution architect and project owner lay down the foundational guidelines for managing changes.
Objective: The focus is on considering several facets, including:
Project scale
Complexity
Deadlines (and their flexibility)
Mechanics: Deliberations occur regarding the management of changes:
Will modifications be addressed post-go-live?
Will they be immediately implemented?
And anything else that could be considered to be relevant.
Readying for Fixed Launch Dates:
When a project is bound by a strict launch timeline, a heightened level of planning and prioritization is necessitated:

Feature Prioritization: It’s pivotal to distinguish between essential (“must-have”) features and those that are desirable but not mandatory (“nice-to-have”).
Risk Assessment: A proactive approach involves identifying potential challenges and plotting them out in advance.
Contingency Blueprint: Design strategies in anticipation to manage unexpected setbacks or delays, ensuring the project adheres to its established launch window.

Case Study: Navigating a Website Launch with a Fixed Go-Live Date

Scenario:
Suppose a company sets a go-live date for a new website just 5 weeks away. The marketing team, enthusiastic as always, has already promoted this date extensively to potential customers. This scenario, regrettably common, illustrates the occasional mismatch between marketing timelines and development realities. (The dynamics between development and marketing teams is a deep topic, deserving its own discussion.)

Given this timeframe, one entire week should be reserved for User Acceptance Testing (UAT) and final launch preparations. This constraint provides the team only 4 weeks for project completion and thorough quality assurance.

Implications and Actions:

a) Must-Have vs. Nice-to-Have Features:
Business requirements must clearly demarcate the essentials from the non-essentials.
Warehouse Integration: Essential. Without it, product shipment is halted.
ERP Integration: Not immediately crucial. As long as integration occurs within an agreed-upon timeframe with ERP stakeholders, initial launch can proceed. ERP primarily addresses internal business concerns, not customer-facing ones.
GA4 Services: Non-essential for launch. Customers aren't affected by the absence of tracking mechanisms, and it doesn't hinder order processing.
Payment Processor Integration: Undoubtedly essential. The company needs a reliable mechanism to handle customer payments.

b) Risk Management:
The business requirements should have a dedicated section for potential risks.
If stakeholders have already discussed and agreed on risk mitigation strategies, then it's a step in the right direction.
If risks aren't adequately defined or if new risks emerge, they need immediate attention. Addressing these issues might require stakeholders' involvement.

Example: Let's assume the business requirements didn't anticipate the risk associated with potential delays. Upon review, the team realizes there might not be sufficient time to integrate the chosen payment processor before the launch. As a mitigation strategy, the team could:
Opt for an alternative payment processor with a quicker integration timeframe.
Request an extension to properly integrate the initially chosen payment processor.
In such cases, stakeholders' inputs become invaluable. Open dialogue ensures that everyone remains on the same page and that the most effective solutions are employed.

Technical Specification Confirmation and Approval:
After finalizing the technical specification, it’s vital to obtain confirmation and endorsement of the proposed solution. For clarity and to ensure alignment, always aim to receive a tangible acknowledgment. This could be in the form of a signed document or an explicit email confirmation, which essentially conveys, “I’ve reviewed, understood, and am in agreement with the details and approach outlined. Please proceed.”
Transitioning from Specification to Execution:
With the approved technical specification in hand, the next step for the architect is to dissect it into individual tasks to guide the development process.
The mode of this exercise can vary based on the vendor or organization’s practices. It could involve a collaborative session between the architect and the team lead, or it may extend to encompass the entire development team.
The overarching objective is straightforward: Transform the comprehensive technical specification into a clear, actionable task list for the development team to embark on.
Task Completion and Quality Assurance:
For each task, a standardized process is implemented:
A developer (or a group of developers) takes on the task and works towards its completion.
Once finished, the task is handed over to the Quality Assurance (QA) team for verification.
Concurrently, the developer can proceed with the subsequent task. However, if any issues arise during the QA process, the developer might need to pause the new task, rectify the previous one, and then resume.
After QA validation, tasks deemed complete are deployed to the staging environment.
Gradually, this environment becomes populated with various completed elements, progressively reflecting the final product.

It’s highly recommended that project owners actively review and validate tasks as they’re rolled out on the staging environment. This active involvement yields several key benefits:
Ensuring Alignment with Vision:
While a delivered functionality might technically meet the requirements, it may not always align with the project owner’s envisioned outcome.
Early validation serves as a checkpoint to spot such divergences. This can lead to timely change requests, ensuring that adjustments are made while they are still manageable and less disruptive.

Benefits of Early Change Requests:
Ease on Development: Early change requests, contrary to last-minute adjustments, are generally more manageable for the development team. Addressing these in real-time can stave off larger, more complicated revisions later in the development process.
Higher Quality Results: The outcome is not only more aligned with the explicit business requirements set by stakeholders but also resonates with the underlying vision and spirit they intended.

Engaging Stakeholders:
When project owners and stakeholders are actively engaged, they feel an integral part of the journey. This sense of ownership and involvement fosters trust and ensures that the team is wholly dedicated to the project, aiming for an end result of the highest caliber.

Approaching Project Completion and Preparing for Launch:
When the project nears its end, specific preparations need to be initiated for the final deployment.

There are two key elements worth mentioning;

11.1 First: User Acceptance Testing (UAT) phase:

The Role of UAT:
This critical phase involves the project owner and the solutions architect presenting the completed work to the stakeholders.
While some instances might have the project owner handling the UAT solo, this method can often lead to complications.
A frequent scenario observed is the project owner presenting the solution alone, only for stakeholders to reject it based on misunderstandings or lack of technical clarity.
Such scenarios necessitate a follow-up meeting, this time involving both the project owner and a technical expert. In most cases, it’s revealed that the project does adhere to the tech specifications and caters to the changes requested. Sometimes, the only real contention might be minor, like adjusting a button color.

Recommendation: To mitigate potential miscommunications or misinterpretations, always ensure a technical expert accompanies the project owner during the UAT. This dual-representation ensures the stakeholders receive a comprehensive understanding of the completed project, minimizing ambiguities.

11.2 Second: Planning the Go-Live Phase:
The phase leading to the actual deployment of the project is as crucial as the development itself. This involves meticulous preparation to ensure a smooth transition to the live environment. The chief architect typically spearheads this planning, covering several pivotal aspects:

a) Go-Live Plan:
This comprehensive plan outlines each step and activity leading up to the go-live moment.
The plan meticulously delineates roles and responsibilities, detailing who is in charge of specific tasks, their timing, oversight mechanisms, and the custodians of crucial credentials.

A Cautionary Tale About Credentials:
A few years ago, a distant company embarked on launching a brand-new website. 
Given their past experiences with similar complex projects, there wasn't an air of apprehension. The team went through the usual preparatory phases, had backup plans in place, and then went live. The rollout was smoothalmost too perfect.

However, during post-launch testing, a snag emerged: the payment method credentials. The sole possessor of these credentials? A stakeholder who was, at that very moment, vacationing in Fiji. As you can imagine, this oversight put the entire project on pause for roughly 12 hours, awaiting the wake-up call for this sunbathing stakeholder. Once alerted, the needed credentials were finally shared.

This anecdote underscores the fact that even minor oversights can disrupt the most well-prepared go-live plans. Notably, the IT team had voiced concerns about this potential credential bottleneck repeatedly in the lead-up to the launch. Yet, each time, they were reassured by project management that "it's all taken care of." A classic example of overconfidence, perhaps?

And now, let's continue back to our primary topic.

b) Mitigation Strategies:
Anticipating challenges is a hallmark of a well-prepared project.
Key questions to consider include:
What measures are in place if things don’t go as planned?
In case of unforeseen issues, do we opt for an immediate rollback or troubleshoot in real-time?

c) Deployment Testing:
Ideally, before the actual deployment, a test run should be performed to identify any potential hiccups.
This isn’t just about functionality but also about ensuring the infrastructure can handle the deployment.

d) The “Go or No Go” Meeting:
This pivotal meeting gathers all essential players, including stakeholders, the project owner, and the technical lead, to make a crucial decision: go-live or don’t go live: and reschedule it.

Orrespective of the outcome of decisions, documenting them is essential, with special emphasis on the reasoning behind such choices.

Consider this scenario:
Senior manager is reviewing a project’s documentation. This manager is responsible for end-of-year KPI performance reviews, a fairly standard practice in the corporate world.
Now, counting he’s your immediate supervisor, how likely is it that he’d be remembering the nuances of every project you have been part of?
And between the two scenario’s – below – which one is more likely to result in positive EOY performance review;
And which one is more likely to result in independent performance review?

Scenario 1:
The project had three go/no-go meetings. Two of those meetings resulted in a “no-go” decision, but the project went live successfully on the third attempt.

Scenario 2:
The project also had three go/no-go meetings, with the first two resulting in a “no-go” decision. However, the delays were due to external factors: the payment processor was taking an unusually long time to review the necessary paperwork and activate the business account. By the time of the third go/no-go meeting, the payment processor had finally set up the required account and provided the necessary credentials to the business.

When comparing these scenarios, the latter paints a clearer picture. It not only communicates the challenges faced but also underscores that the delays were outside the control of the project team. Such precise documentation can be a deciding factor during performance reviews, ensuring that teams or individuals aren’t unduly penalized for factors beyond their control.

Irrelevant to the decisions made:
It’s crucical to document it, and most importantly: document the reasons behind such a decision.

Let's step back for a moment, and review project's paperwork from the POV of the senior manager:
Who's performing EOY KPI performance reviews (and those are give or take standard in the corporate world)
To a person, who's technically - your boss:
But practically - quite likely can't remember the intricates of all the projects you've been involved with;
Which use case will look better, and which use case will likely result in "positive" KPI and which one may result in "negative" KPI?
Use case one:
Project had 3 go/no-go meetings, 2 times project received no-go, went live successfully on the third time. 
Use case two:
Project had 3 go/no-go meetings, 2 times project received no-go: due to the delays on the payment processor:
They haven't activated the business account, and was taking unusually long time to review the papework.
By the time of the third go/no-go meeting payment processor created required account, and passed over relevant credentials to the business.

Question was rhetorical, obviosly use case 2: will result in something positive to the team;
While use case 1: will result in either negative; or nothing at all.

When a collective decision to move forward is reached, it’s beneficial to formalize this consensus.
A simple but effective method is to have every participant sign a document confirming their agreement.

Why adopt such a formality? Beyond mere procedure, signing a document, even if it lacks legal implications, carries weight.
It signifies personal commitment and underlines the gravity of the decision. It’s a psychological affirmation of one’s accountability and alignment with the project’s direction.

Go-Live:
Congratulations!
Successfully navigating this phase means you’ve adhered to the established steps and hopefully achieved a smooth transition.
Post Go-Live Activities:

The post go-live phase extends beyond merely addressing immediate post-launch concerns.
It may range from offering continued support to integrating additional features that weren’t initially included in the project’s scope.

Key activities to ensure in this phase include:

13.1 Project Documentation:
Throughout the project, several essential documents would have been accumulated, such as:
Business Requirements
Technical Specifications
Change Documentation (if applicable)
These should be consolidated and archived in the company’s knowledge base. Ideally, they should be complemented with user guides detailing how to utilize the implemented solutions.

13.2 Retrospective Meeting:
Organize a session to reflect on the entire project, focusing on:
a) Successes and areas that were executed well
b) Challenges and points of contention
c) Learnings and aspects that could be approached differently in future projects.

This reflective process ensures continuous improvement, refining best practices for future initiatives.

In summary:
When establishing development protocols, the goal is to create a standardized approach for any project undertaken by the company.
This ensures consistency, quality, and efficiency. Here’s a simplified framework for such protocols:

Key Steps Of Establishing Development Protocols:

Project Definition: Start by clearly defining the project’s objectives, irrespective of its scale or nature. This step revolves around setting clear business requirements for any given project.
Technical Framework: For every project, create a technical specification that is derived from its business requirements. This offers a technological roadmap for the development team.
Collaborative Development: Develop the solution, ensuring it aligns with the established protocols. Maintain open channels for regular feedback, allowing for agility and adaptability in the development process.
User Acceptance Testing (UAT): As part of the protocol, always run a UAT phase. This not only validates the project’s deliverables against its objectives but also assures stakeholders of its quality and functionality.
Deployment Strategy: Formulate a standardized go-live plan, which can be adapted to fit any project’s specifics. The focus here is on preparing, securing approvals, and launching the solution seamlessly.
Post-Implementation Review: After every project’s completion, it’s essential to review its successes and challenges. This step helps in refining the protocols further, recognizing outstanding efforts, and addressing any gaps in the process.

Key Definitions & Descriptions Used To Establish Development Protocols:

Roles & Responsibilities:
Stakeholders:
Description: These are individuals or groups with a vested interest in the outcome of the project. They are typically the ones initiating or sponsoring the project.
Responsibilities: Provide project vision, set objectives, allocate resources, and assess project results against initial expectations.

Project Owner:
Description: The Project Owner is a pivotal figure in the project's lifecycle, endowed with the authority to make critical decisions pertaining to the project. Their role transcends simply aligning the project with business goals; they have the autonomy and responsibility to shape the project's direction based on a combination of stakeholder expectations and their own judgment.
Responsibilities:
Decision-making: Empowered to make any and all decisions related to the project, ensuring its alignment with business objectives.
Direction & Vision: Sets and adjusts the project's course, ensuring it aligns with both immediate needs and long-term business strategy.
Task Prioritization: Determines the urgency and order of tasks based on strategic value and immediate needs.
Stakeholder Liaison: Serves as the primary bridge between the technical team and stakeholders, ensuring clear communication and mutual understanding.
Delivery Assurance: Oversees project progress to ensure timely and accurate delivery of all milestones and deliverables.

Tech Expert/Solutions Architect:
Description: A professional responsible for designing the technical structure of the project, ensuring it is scalable, secure, and meets the business needs.
Responsibilities: Create technical specifications, select appropriate technologies, oversee technical aspects of the project, and ensure the technical team has clear direction.

Development Team:
Description:  The Development Team consists of skilled developers responsible for translating design and requirements into functional code, constructing the envisioned product or solution.
Responsibilities: Code the solution, test individual components, rectify issues, and collaborate with other teams to ensure seamless integration.

QA (Quality Assurance) Engineers:
Description: QA Engineers play a pivotal role in verifying and validating the product to ensure its optimal performance and adherence to specifications. They are instrumental in ensuring that the solution delivered is of the highest quality and meets the defined standards.
Responsibilities: Test the solution, identify defects, document issues, and ensure they are addressed before deployment.

Infrastructure Team:
Description: Focuses on the underlying systems and platforms that support the solution, ensuring they are optimized, secure, and reliable.
Responsibilities: Manage servers, databases, networks, and other infrastructure elements crucial for the project's success.

Additional Team Members: Depending on the project, other roles might come into play, such as UX/UI designers, database administrators, or business analysts. These individuals bring specialized skills to address specific project needs.

By clearly defining these roles, a company sets clear expectations and responsibilities, ensuring a coordinated and efficient approach to project development.

Escalation Points & Exception Handling:

Business Side Escalation:
Issue with Project Owner: Should any issue arise with the project owner, for example, when a business requirement is deemed unfeasible, the matter should be escalated to the stakeholders.

Technical Side Escalation:
Issue with Technical Expert: If the tech expert or solutions architect is not meeting their responsibilities or is underperforming, the escalation point is the individual or team overseeing the vendor relationship within the company.

General Escalation:
Group Discussions: For broader issues that do not fall under the above categories, a group meeting involving stakeholders, the project owner, and the technical expert or solutions architect should be convened. The objective of such meetings is to collaboratively diagnose the problem, evaluate its impact, and identify strategies to either mitigate or completely resolve the challenge. Establishing a consensus and collaborative approach ensures that everyone is aligned and working towards the best possible solution.

Technical Specification:
Universal Understanding: The technical specification should be clear and comprehensible for both the project owner and the technical team. It acts as a bridge between business goals and technical execution.
Direct Reference to Business Requirements: Each element within the technical specification should link directly back to a specific business requirement.
Example: If the business requirement states, "Integration with Warehouse X is needed to facilitate product shipments," the technical specification might detail:
a) Introduction of a flat file export system that logs unshipped order details.
b) Establishment of a cron job responsible for automating the export of order data.
Dual-Readability: Technical specifications need to be structured to cater to both non-technical and technical audiences. This ensures that the business intent is captured accurately while providing the technical team with the necessary details for implementation. The document should strike a balance between high-level overviews and technical particulars.

Change Management:
Change management is an integral component of any project, ensuring adaptability without compromising on consistency and clarity.
As such, it’s imperative that any modifications or alterations be meticulously documented and echoed in both the Business Requirements Document (BRD) and Technical Specification Document (TSD).
Documentation in BRD: Any alteration or addition to the initial business requirements should be updated in the BRD.
This ensures that stakeholders and the project owner remain aligned on the project’s objectives and desired outcomes. A version history and a log of amendments can be useful to track changes over time.
Reflection in TSD: Once changes have been updated in the BRD, corresponding updates should be made in the Technical Specification Document. This ensures that the technical team has the latest information and can adapt their work accordingly. A change log or revision history within the TSD can help trace the evolution of technical requirements and their corresponding business needs.
Change Approval Process: Establishing a formal process for proposing, reviewing, and implementing changes ensures that all parties involved are on the same page. This might include predefined stages like submission, evaluation, approval, and documentation.
Communication: Every time a change is approved and documented, relevant team members should be notified. This prevents any oversight and ensures that the project stays on track, even as modifications are made.
Incorporating these practices ensures that change management operates smoothly, minimizing disruptions and maintaining the integrity of the project’s goals and technical execution.

Knowledge Database:
A knowledge database is a valuable repository where everything related to a project is stored.
Its primary purpose is to serve as a comprehensive resource for future reference, ensuring that when there's a need to revisit any detail of a past project, the information is available at one's fingertips.
However, maintaining an effective knowledge database requires more than just dumping data into it. It's essential to be discerning about what goes into the database to keep it relevant and user-friendly:
Focused Content: While changes during a project's lifecycle are necessary and should be documented, the knowledge database doesn't need a blow-by-blow account. For instance, it doesn't require knowledge of initial concepts that were later replaced or modified. The primary focus should be on the final, implemented version.
Version Control: If you're keen on preserving different versions of a document, structure it sensibly. Show the latest version upfront and archive older ones separately. Ensure older versions don't clutter search results, unless specifically sought by the user.
Establish Clear Protocols: Decide what goes into the knowledge database and what doesn't. This ensures that the database remains a useful tool rather than an overwhelming repository of outdated or irrelevant information.

Here's another tale for you, directly related to the nuances of Knowledge Bases!

    "Whoops! The Chronicles of Mister S. and the Great Database Delete Debacle"
    In a kingdom not so far away, known to you as "Company X," change was brewing. The halls echoed with the chatter of many teams, each with their own language, all striving to build the next best thing.
    Enter our intrepid hero, "Mister S." An ordinary fellow with extraordinary organizational skills, he was tasked with the epic quest of, well, getting everything organized. With glasses perpetually perched on his nose, he wandered from realm to realm (or rather, team to team) within this vast corporate empire, collecting scrolls, tales, and enchanted USBs.
    One team, the Wizards of Backend, had ancient spells scribbled on napkins. Another, the Elven Designers, spoke in mystical tongues about "user journeys" and "UX." Undeterred, Mister S. befriended them all, collected their data, and resisted the urge to pull out his already thinning hair.
    His crowning achievement? The "Knowledge Crystal Ball" a digital fortress that contained the DNA of every project ever conceived. Legends say you could get lost for days within its intricate corridors filled with flowcharts, diagrams, and videos.
    Having created something of legendary status, Mister S. felt a sense of fulfillment. He decided to set sail for new adventures, confident he'd left behind an indelible legacy.
    But... in the twistiest of plot twists, a few sun cycles later, the upper echelons of Company X convened for a spring-cleaning meeting.
    "Ah, what's this massive blob taking up our cloud?" mused Sir J Clueless the Third, the newest senior manager notorious for deleting everything in sight.
    "It's just the Knowledge Crystal Ball or something," replied Mister K. Overlook, who was aptly named for his tendency to overlook crucial details.
    "Sounds unnecessary," Sir Clueless responded, munching on a donut. "OK TO DELETE?"
    "Sure," shrugged Overlook, as he darted off to another Very Important Meeting With Very Important People.
    And just like that, poof! The culmination of Mister S.'s relentless efforts vanished into the digital ether.
    Rumors say that when the news reached Mister S., his jaw dropped so low it's still rolling somewhere. Meanwhile, the employees of Company X were left scratching their heads, wondering why they couldn't access the fabled "Knowledge Crystal Ball."
    The legend of Mister S.'s efforts and the "Great Database Delete Debacle" is still shared around water coolers, usually with chuckles, facepalms, and a sigh of "classic Company X."
    The end? Well, until the next corporate mishap, anyway.

    Point of the Story:
    No matter the brilliance and effort behind a project or initiative, its value is truly understood and appreciated only when its importance is recognized by everyone involved, especially those in decision-making capacities.
    Mister S. poured his heart, soul, and countless hours into constructing a resource that was nothing short of a goldmine. He envisioned a legacy for Company X, one that would streamline operations, enhance team collaborations, and serve as a beacon of knowledge for years to come. It was the embodiment of foresight, capturing the essence of countless projects and collaborative efforts.
    Yet, without adequate understanding and appreciation of its worth, even the most invaluable asset can be dismissed and discarded. Knowledge, often said to be power, becomes powerless if not respected.
    Deleting the knowledge database was not just about erasing files or clearing storage space. It was about disregarding the cumulative wisdom and experience of countless professionals. It demonstrated a lapse in judgment, a missed opportunity, and a stark reminder that the most significant achievements can be easily overshadowed by uninformed decisions.
    The onus, therefore, falls on both creators and custodians. Creators, like Mister S., should endeavor to ensure their work's importance is communicated and acknowledged. In contrast, custodians, especially those in leadership roles, must take the time to understand and appreciate the assets they oversee.
    In essence, the story underscores the timeless lesson that knowledge is only as valuable as the reverence it's given. As companies grow and evolve, they must ensure that the pillars of their success, the knowledge and tools they rely on, are not just preserved but cherished. For in the end, it's not just about what you've built; it's about what you choose to keep.

Business Requirements Document (BRD): An Overview
A Business Requirements Document (BRD) outlines the needs and expectations of a particular project from a business perspective. It is an essential tool in ensuring that the final product meets business objectives and that both the technical and business teams are aligned. It’s crucial for the business team to be specific in what they need, and let the technical team decide the “how.”

Project Description:
Objective: Detail what the team is building. This section should provide a comprehensive overview of the project, its purpose, and its expected outcome.
Functionality & Benefits:
Expected Functionality: Describe how the project is supposed to function from a business perspective.
Expected Gains: List what the business expects to achieve upon the project’s completion, such as cost savings, increased revenue, improved efficiency, etc.
Timeline:
Due Dates: List the major milestones and their corresponding due dates.
Time Sensitivity: Specify whether the project is time-sensitive and the implications of any delays.
Risks & Mitigation:
Potential Risks: Highlight any foreseeable risks that might hinder the project’s success.
Mitigation Plans: Outline strategies to manage or avoid these risks.
Disaster Recovery: Describe a plan to recover and restore business operations in case of major disruptions or failures.
Requirements Classification:
Must-Have: List the absolute essential features that the project cannot function without.
Nice-to-Have: Identify any features that would be beneficial but are not critical to the project’s core functionality.

Note on Implementation:
Business requirements should solely focus on “what” the business needs and expects. The “how” – or the technical aspect of achieving those needs – should be left to the technical team. For instance, instead of specifying the use of a particular tool or software (like Amasty modules), the business should describe the desired result (e.g., “a report like the one generated by Amasty, as shown in this example”). This approach gives the technical team the flexibility and authority to decide the best technical solution.

Example:
Instead of saying “We want Amasty modules,” the business requirement should state, “We require a reporting feature that showcases XYZ metrics, similar to the ones produced by Amasty.”

By keeping technical decisions out of business requirements, we ensure a smoother project flow, avoid potential pitfalls, and reduce the chance of project derailment.

To conclude, let me regale you with a couple of pertinent anecdotes.

A Glimpse into the Past: Lessons on Expertise and Decision-making

Navigating the Storm: The Cloud Migration Tale
In the corridors of the far-off company "X", the winds of change were blowing. The decision-makers were enamored with the allure of transitioning from a traditional hosting environment to cloud services, primarily driven by the siren song of cost savings.
However, their resident technical guru saw through the mist. He adamantly declared, "This won't work, not by a long shot!" Yet, the business leaders were unyielding, responding with a firm, "Make it happen regardless."
Left with little to no choice, the technical guru rallied his team of seasoned professionals. Recognizing the importance of concrete evidence, he initiated a series of load tests comparing the current environment with the proposed cloud solution. Armed with the results, he forwarded them to the senior management. His message was clear: "As anticipated, the numbers don't lie. Kindly review the load test results attached. They clearly indicate a potential drop of 70-80% in our performance. My vehement recommendation is to rethink this migration, as the proposed hosting platform seems untenable."
The business was unyielding. "The task stands. Make it happen or face the consequences." Talk about incentive, right?
With his back against the wall, our protagonist crafted a shrewd strategy:
"Let's capitalize on our strengths. We know the current environment is robust and the forthcoming one has its weaknesses. So, our logical step is to employ the old servers to their full potential. We initiate the upgrade in our old environment, set everything in place, and subsequently, migrate the updated codebase and database to the new system. Admittedly, network bandwidth is our bottleneck here. However, with some negotiations, perhaps our current provider might allow an upgrade. This strategy is arguably our best shot."
However, the migration of the updated database to the new cloud environment took a staggering 12 hours. In stark contrast, the process had previously taken a swift 40 minutes in the original environment. The prolonged duration can be attributed to network bottlenecks in the new setup, extraordinarily slow hard drives, and a barely functional MySQL service. Despite these challenges, after relentless efforts, the site was finally up and running.
In the wake of the project, the atmosphere wasn't one of celebration or applause. Senior management laid blame squarely on the shoulders of the technical specialist, attributing the prolonged downtime and sluggish site performance to his alleged shortcomings. Their first step was to commission a review from an external company. However, this initial assessment was so misaligned with the reality that the guru couldn't help but mockingly claim he could replicate such a report against any website, Magento or otherwise, in mere hours.
Recognizing the need for a deeper analysis, the executives turned to a well-known corporate entity, a company they had collaborated with before. This organization was known for their meticulous attention to detail and expertise. Their approach was holistic; they delved deep into the Magento upgrade and the migration process, evaluating the documentation, codebase, and server setups. Beyond that, they set foot in the company, conducting interviews, analyzing the infrastructure, and running independent tests.
Their conclusion contrasted sharply with the initial assessment. They commended the technical team, remarking, "You've achieved the near-impossible. Given the inferior infrastructure, Magento 2 shouldn't operate as it does, but here it stands, running effectively despite the evident challenges."
After the storm had passed, the specialist took a moment to introspect. He pondered whether letting the migration face a setback might have been a better lesson for the business. Maybe, just maybe, a hiccup in the project would have prompted the top brass to revisit their hasty decision.
And here's where irony played its part: the shift to the cloud, initially envisioned as a cost-saving measure, ended up doubling the company's hosting expenses. From a manageable $7,000 monthly fee, the costs soared to an astounding $15,000 in the so-called "more affordable" cloud setup. It was a staggering half a million dollars and six exhaustive years later when the tech maestro finally persuaded the executives to address the glaring oversight.
Moral of this corporate comedy:
Would Usain Bolt pilot a spaceship? Would Adele captain a submarine? Then why allow someone non-technical from business to dictate IT decisions? The saga underscores the need for every player to stick to their strengths. Because in the mismatched game of tech and uninformed decisions, everyone loses. Especially the company's coffers.

This brings to mind another apt analogy, rooted deep in the annals of evolution.

    A Glimpse from Prehistory: Dinosaur's Tale

    Picture, if you will, a colossal dinosaur. And by colossal, we're talking about a COLOSSAL making T-Rex look like a housecat. This gentle giant, stretching an astounding 400 meters from its snoot to tail-tip, ambled about like the world's largest vegetarian. Every once in a while, amid his leisurely strolls, he'd munch on palm fronds because, you know, even massive dinosaurs fancy a light salad now and then!

    Suddenly, out of the blue, a pint-sized predator springs from the bushes, grabbing onto the dino's tail with a chomp and a chew.  The tail, sensing the unexpected assault, goes into panic mode and sends a frantic signal: "Intruder alert! Tail under siege! Immediate action required!"
    Now, here's where things get tricky: this message must travel a staggering 400 meters to reach the dinosaur's main control room, aka its brain. That's 5 seconds of travel time! The brain, once it processes the urgency, dispatches a retaliatory command, "Shake off the attacker!" which takes another 5 seconds to reach the tail. That's a grand total of 10 seconds, giving the audacious attacker ample time to savor a sizable snack from the dino's unfortunate hindmost part.

    Nature, in its infinite wisdom, devised a solution: bestow upon the dinosaur a secondary "brain", situated closer to its hindquarters, dramatically reducing the lag in tail defense. Thanks to this nifty upgrade, any sneaky tail-biting shenanigans could be parried within mere seconds, sending the audacious attacker back to the bushes with nothing more than a bite-size appetizer, ensuring the majority of the tail remained intact.
    with only a bite-sized appetizer,

    So, what's the takeaway? Ever been baffled by some of the eyebrow-raising choices companies make? I'll let the story simmer for a moment... 
    But it sure makes you wonder about the, ahem, 'expertise' of those calling the shots, doesn't it?

A Hearty Thanks to Our Readers!

Kudos to those who’ve journeyed with us to this point in the article! Your dedication is sincerely appreciated.

We’ve endeavored to shed light on the intricacies of development protocols. However, if any aspect remains ambiguous or prompts further queries, please don’t hesitate to get in touch.

Here’s to our next exploration together!