I recently transitioned into a business analyst role. Before that, I was considered a subject matter expert (SME) on the customer end of a software project. This sets the stage for discussing my experience as a SME, how becoming a business analyst expanded my understanding, and what I can take away from being in a role that compliments what I do now.

I was asked to represent an organization as a SME for a company that was providing a replacement Customer Relationship Management (CRM) program. It was an inconvenient of time to be tasked with this role because I was not a part of the initial decision process and defining of the project scope. When I started, the organization was just given the consumer off the shelf (COTS) product. It was my task to find any issues, suggest any customizations, and define the connections to other systems currently in place.

In a way, I was user acceptance testing – even if I did not know it at the time. My experience stemmed far from that though, as I quickly learned the details of the overall process and started to more clearly define scope for my organization.  Scope when I started to work on the project was to connect the CRM to webpage application and another third party program. From there, I had to assist in explaining the process, defining what  should be automated, presenting what should be migrated from the old system, and recommending to either approve or deny changes based on costs and benefits (usually in the form of time saved) that would be realized.

The transition into a business analyst brought countless changes to my perspective on projects. Some changes that are most apparent so far have included: visually representing information through models, defining requirements for software to be developed, and taking high level ideas down to sea level so developers can dive into the process of creating the software.

Furthermore, the additional context provided by going into business analysis allows me to figure in an additional perspective into my previous situation as a SME. Ultimately, what I think complicated the project was that the providers of the COTS product also acted as the business analysts and developers. In other words, business analysis and development was handled by the same people. This was ideal for defining constraints. Since they developed the software they knew the limits of the software by heart. Whatever questions were asked, the team was able to answer them with the utmost precision.

However, I think this also became a shortcoming of the project because obtaining the right information (on which to base scope and requirement decisions) was dependent on my organization asking the right questions. Inquiring about relevant adjustments and detailed acceptance criteria was often overlooked due to focusing on the underlying problem, which fixated on the idea that the previous program is expensive and time consuming. My organization had no one to elicit the responses necessary to further define the project’s essential demands. It was not that we were incapable of asking those questions, it delved more into the fact that we did not have the time or software development experience to quickly formulate the questions. Everyone in the organization, including myself, was occupied attending to the other everyday roles on our plates.

In other words, the business analysts’ knowledge of product overshadowed deriving requirements; therefore, putting the project way behind schedule due to relying on trial and error to determine what was acceptable. This became extremely problematic when it came to trying to connect third party software to the CRM because they had neglected the fact that it was run remotely instead of solely licensed, which required additional third party negotiations. Setting up time at the start to converse with the business analysts on all aspects, or portions, of the project in detail could have resolved this earlier in the project development cycle.

In essence, the biggest take away from my experience as a SME to apply to my business analyst role is the importance of defining well thought out requirements from elicitation. The project I worked on left a lot to the imagination in terms of the current status on completion and was frustrating because requirements were trying to be defined through experimentation. Time is money and, ultimately, a lot of time was spent deriving requirements after the fact. The time spent resulted in delaying the projects full launch date by four months. The time saved upfront is not worth the project risks associated with deriving requirements by trial and error.