This article is part of an ongoing series by Doug Finnie, titled “In Search of the Perfect E-Commerce Solution Series.” View the rest of the series HERE.

As previously defined, determining the right software and vendor requires you to determine what your business needs are versus your wants. Think of it as if your car breaks down and you need ‘a car’ so you shop for a car and your first test drive is a new car with electric windows, seats, seat warmers, sunroof, 6 CD player with high-end speakers, DVD player, navigation and on and on. After the drive you think you ‘have to have that car;’ that is your WANT. The reality is you NEED a car that can get you from point A to point B. Start with a basic car with basic functions and then add options as you NEED them.

The same goes with software applications: you need a system that can recruit, sell, ship and pay commissions. Do not get caught up in all the bells and whistles. Instead, focus on needs.

Ask yourself what does the business require, and can technology support it? Creating a business requirement is a high-level explanation of a process that is necessary to achieve the overall business objective. Using the example above, a business requirement would be; I need to purchase a car that gets good gas mileage, has four doors and is automatic. Creating business requirements helps transition into the functional requirement phase.
 

What is the Functional Requirement Phase?

The functional requirement documents (FRD) the current business process step by step (both manual and systemic) and the associated data that is created. Understanding the functional flow begins with assessing and creating detailed documentation of the business processes. The FRD is critical to starting your search for software and ensuring you acquire the correct technology.

Producing the FRD can be complicated as it requires a complete understanding of the process being evaluated as well as the human psyche and how they interact. Organizational Psychologists have found employees that perform rote processes form what is called procedural memory where a rote task is stored in the employee’s unconscious memory which results in them literally forgetting what they do when asked about their job even though they are physically performing that action each day.
 

What Does a Business Analyst Do (And Why Do I Need One)?

Because it is so important to ensure you capture each functional step of a process, it is critical that the requirements gathering is done by a qualified Business Analyst (BA), one who is skilled in observing and documenting someone performing tasks. Gathering functional requirements require questioning the subject matter expert on the “what” and “why’s” of the function.

The BA begins by asking “what are you doing” and “why are you doing it.” People can be threatened by such questioning and instead of understanding why the question is being asked, they hear “is my job needed?” and react with “I need to justify my job.” That is not the case at all. The goal of the exercise is to document a set of processes and procedures needed to accomplish the overall objective of the job function while focusing on putting the employee at ease through open, trustworthy and clear communication.

If employees feel threatened, they may withhold information which will result in incomplete or inaccurate requirements. This is why management needs to understand the importance of collecting business and functional requirements and ensuring the process is managed by a qualified person. Failure in managing the process can result in the old adage of “Garbage in Garbage Out” becoming a reality and the requirements process failing costing time and money.
 

The Step So Many Skip: Validation

Once the interview process is complete, the next step is to analyze the information gathered to ensure it is accurate. Once the BA reviews the information and drafts the requirements document, they need to meet with the subject matter expert who participated in the interview, the manager overseeing the function being evaluated and at least one more person who is familiar with the function to review the requirements document. The validation step is important because this is where the impact of procedural memory may show up. Remember earlier it was mentioned that procedural memory is a person’s unconscious memory, therefore steps in a flow can be forgotten.

During management review, managers have an expectation of how a function is to work and once they see the flow on paper they may determine what is actually being done is not what is expected, which results in a gap being defined. The gap should be captured and either resolved by changing the process or changing management’s expectations on the function.

The BA will then take the validation feedback from all parties and update the requirements document. A final draft will be produced for review by those who provided feedback. This process can be repeated until all parties agree on the content. If the process has to be done more than twice, it is recommended that a meeting with all participants be held to finalize the document. Once everyone is satisfied with the document then the functional manager should sign off on the requirements document.
 

Do You Utilize Version Control?

Once signed off, the document then goes into version control which means any changes or updates to the document must be tracked and re-approved by the approving manager. Some companies do version control prior to the sign-off. It is a personal preference as to where in the process it is implemented.

With requirements done, you can think of it as if it is the roadmap to your desired destination. Using the car analogy the next step is to begin looking for the right car to get you there. The same concept applies to software solutions and vendor; begin looking for the one to get you to your roadmap destination. That starts with features and functionality, i.e. four-wheel drive, off-road suspension, cruise control, etc. Now build a checklist of required software functionality.

As you read above you can see the criticality of developing business and functional requirements. Our next post will describe the due diligence in software and vendor management.
 

Need Help Making Your Next Technology Decision?

There’s a lot that goes into choosing the best technology for your company. For direct selling organizations, there are so many factors to consider. That’s why we work with so many direct selling companies to help them navigate these waters confidently and choose the right solution for where they are right now, and where they want to be. We also often step in and take on the “Business Analyst” role for companies that don’t have such a person with the familiarity or bandwidth to do it well. Contact us about working with Doug Finnie or anyone else on the SCP team to help you with your next big technology decision.
And, be sure to create your free account here on the website and get instant access to our library of training for direct selling execs, including a webinar hosted by Doug Finnie, Brett Duncan and Chris Clark titled “Stress Less About Your Software.” Create your free account now!

 

 

About Doug Finnie

Doug has over thirty years of management experience in the technology, direct sales and banking industries holding roles in direct sales organizations such as Origami Owl and Gold Canyon Candles and in other industries such as software development and fulfillment and logistics. As an accomplished CIO his specialties include working with business leaders in defining technology strategies, technical contract and due diligence assessments, project management and systems implementation and migrations. Doug has previously served on the DSA Technology Advisory Council.

Learn more about Doug on his bio page, and contact us at info@strategicchoicepartners.com if you’d like to discuss how Doug and SCP can help your company.