A common challenge of enterprise Business Analysts is the discovery, understanding, and description of requirements in the context of implementing packaged solutions. Management assigns us to projects with a predefined solution, and we struggle to figure our role when there seems to be no significant build activity. What are we supposed to do in this situation when there seems to be no need to produce standard requirement deliverables?
Put a typical Business Analyst in this environment and do not be surprised to hear the phrase “I’m not sure of my role.” Why do packaged solution projects cause discomfort? Three common reasons come to mind:
- We know that our traditional deliverable does not make complete sense in a situation of predefined functionality; creating a series of “system must provide the ability to” statements may not be well-received (or quite frankly value-add)
- We do not necessarily lead the requirements development process; quite often the business or project management constructs an RFP and considers the remainder of requirements work to be an effort of integration and conversion
- We do not automatically act as the primary conduit between IT and the business; other actors are involved in the equation and often the business works directly with external vendors minimizing the role of IT in conversion and integration
So how do we adjust? How do we participate as a value-add contributor in the context of implementing packaged solutions (also called Commercial off-the-shelf, or COTS products)
Here are five tips for success as a Business Analyst from someone who has gone through the experience on multiple occasions. Yes, I struggled on the first couple of projects but have since discovered common practices that have made a difference in my personal success.
1) Understand the Approach for Package Implementation
Understand the different varieties of packaged software implementation:
- Configured: The solution is installed and updated using built-in settings
- Customized: The solution is installed and updated using custom code
- Out-of-the-Box: The solution is installed without any updates from configuration or customization
This is about understanding the boundaries of possible updates to a vendor product. It is very rare that an organization uses a packaged solution without updates. If a product can be configured, the Business Analyst can contribute by understanding predefined mechanisms of the product and assisting in identifying the proper settings that will suit the business. Documentation can take the form of operating procedures or deployment requirements. If a product can be customized, the Business Analyst needs to understand limitations to extending functionality and how much custom coding is supported by the contract between the vendor and the organization. The Business Analyst can produce requirements in this context that focus on gaps between what the organization needs and built-in functionally. Understanding the boundaries keeps this from becoming a runaway activity.
2) Think Integration Requirements
Packaged solutions are rarely “plug and play”. Packaged solutions typically require a connection to existing systems to send and receive information. Focus first on identifying the information (data) requirements. It is important to understand data dependencies of the packaged solution. What information does it require in order to deliver needed functionality? It is equally important to understand the downstream needs of systems that require information related to actions performed by the installed system.
I have found context diagrams to be an invaluable tool in the high-level discovery of integration requirements including potential interface scenarios. A context diagram is just a start. Detail integration requirements typically require an associated mapping of data entities and attributes between the host and target systems. Mapping documents are a standard deliverable on COTS projects. A common step missed in integration requirements is a failure to capture data definitions. On multiple occasions, I have been involved on a project where a simple term like “active” has different meanings that can lead to severe problems when the system goes live. Building and leveraging a data dictionary is an effective way to mitigate this risk.
3) Embrace Iterative Requirements Development
Packaged solution implementation typically relies on multiple deployment simulations before the final go-live event. Simulations (trial deployments) are performed often for the purpose of confirming assumptions and ensuring that conversion and integration activities are accurate and complete. In this context, the Business Analyst needs to recognize that their requirements deliverable(s) will likely be refined and elaborated based on the outcome of deployment simulations.
On a not-so-recent project that involved the implementation of Workday, I had the good fortune to work on conversion requirements with a vendor consultant. We were asked to build a set of conversion requirements in the space of a week to support data migration. The deadline surprised me because my organization typically treated this as a lengthy process requiring documentation, review, and acceptance of deliverables by business partners. One week was not the norm. I subsequently learned the reality that the data conversion was going to be a repeatable activity and that I needed to be flexible and iterative in refining data needs. This project proved to be a success, and I can appreciate how Agile embraces the concept of iteration.
4) Understand the importance of Business Rules
Business Rules are important in the context of packaged solutions. The core essential functionality of a product is usually not updatable. The underlying business rules related to functionally are typically updatable using configuration to suit the client environment. The definition of roles and permissions is a solid example of where the Business Analyst can add value by understanding security parameters of a product and how to subsequently define permissions associated to different roles. Some products allow for the import of a rule set; other products provide settings in the software to reflect the application of business rules.
5) Reset your Role Expectations
Working on a packaged solution implementation means changing expectations. The Business Analyst does not necessarily have exclusive responsibility and accountability of business requirements. In many circumstances, it will become a shared responsibility with vendor representatives and/or implementation experts. The vendor typically understands the product but is not an expert in the installation environment. A Business Analyst typically does not understand the details of the product but is more of an expert in the installation ecosystem. A dialogue is necessary to allow internal and vendor teams to work together.
Resetting role expectations means communicating and clarifying assumptions. I recall on the Workday project that we thought the vendor was in charge of capturing an initial data dictionary. I used an informal meeting to level-set and learned that his understanding was that we were delivering an initial data dictionary. We quickly got on the same page and established a pattern of role communicating and confirmations. This was not a contractual exercise. This was not an antagonistic pointing fingers to establish a throat to choke. It was about collaboration.
Conclusion
No matter your background, age, or experience, we all share something in common—a desire to be successful. As noted in the beginning, being a Business Analyst on a project implementation of a packaged solution can be a struggle for many. Following the five tips listed are an effective start towards addressing that anxiety.
These tips are based on the patterns that I experienced but are certainly not conclusive. What has your experience been? What advice would you provide?
Cheers to your success and future learnings.
Author: Michael Roy, Business Analysis Professional / Requirements Leader
Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.