I first started outlining these differences in my team practices and on my projects back in the late 90s. Since that time, I’ve seen a huge jump in the complexity of these implementations. While requirements analysis and implementation analysis for package software have not changed much, the risk of getting it wrong has increased dramatically.
The mindset that needs to change, not the techniques
The BA role remains the same for traditional projects and package software projects: protect and optimize stakeholder and organizational value. Many of the same techniques can be used, but the BA mindset and how it's all documented and facilitated may change.
Worry about fit, gaps and change management
When working on package software projects, a fit/gap analysis mindset is crucial along with a keen focus on how the users world is changing and empathy for these changes.
BAs need to look at how the package "fits" the desired outcomes and processes, and identify gaps between the package functions and the current state functions. BAs should work with stakeholders to determine if gaps need to be “bridged”—can we operate within the package functions or do we need to adapt the process or technology to meet our needs?
Documenting this fit/gap decision process is a key BA role, including facilitating options and alternatives to minimize the gaps. Even when implementing “out of box,” this process and analysis is critical to success. “Out of the box” typically means process or operational changes somewhere, BAs are in the role to identify where the changes will happen and prepare the users for these changes.
Don’t force the templates
Once BAs enter the fit/gap mindset, then they need to determine how to effectively document the package software project.
I often see BA teams struggle as they hold on tightly to their templates, trying to make them work for package software projects. Many typical templates don't serve package software projects well. Typical templates assume a custom development approach, and forcing BAs to use these templates creates a lot of pain and challenges for package software projects.
So PLEASE, challenge traditional practices and templates when participating in package software projects. You still need requirements, but timing, and level of detail/abstraction must be appropriate.
Careful not to waste time on detailed documentation of your organization’s current state. The vendor usually has current state documentation for the package and this will become the future state in most cases. Focus on the future state and what must happen going forward, only looking back to the detailed current state when we need to identify details to carry forward. Also, it’s likely project sponsors purchased the package to gain efficiencies and change processes and business operation—they don’t want an exact replica of current state.
Instead, manage your work at a function level. Before selecting the package, what an actor wants to accomplish and rules are important. After selecting the package, the future state and “how” the actor accomplishes it becomes important as a change management piece for piloting, testing, training, and implementation.
We don't want to document functionality already built. Exactly how it’s done in the package can be redundant to document when the vendor typically has this documented. So, avoid documenting requirements for package software that duplicates functional specs and design of software already built.
Don’t rely on the vendors BA 100% for the BA role
You need an internal BA (or BA team) to support a package software project. If you rely solely on the vendor BA, you will not successfully identify and bridge functionality gaps. The vendor BA understands the product, but does not fully understand your environment—your systems, processes, culture, politics, pain points, exception processing, integration issues, etc.
Both BAs—vendor and internal—are critical to success. The internal BA does not fully understand the product and needs the vendor BA to validate functionality and fill gaps.
Whether it’s two people or two hundred, the internal and vendor teams need to come together like puzzle to teach each other, build trust, and work through issues.
Upgrades need BAs
It’s quite common to hear teams say that package software upgrades don’t need BAs or requirements.
Challenge this assumption! Upgrades almost always have user impact or at least a risk of user impact. If users use the system, there are requirements!
Whether the change is minor or technical, a knowledgeable BA should be consulted. Even if the upgrade has been successful at several other sites, there is still a chance that your organization’s unique configuration or system integration could be negatively affected by the upgrade.
So ask requirement-resistant team members a few questions like: Why are we spending money on the upgrade? How do the users benefit? What would happen if it’s not done? Help them understand potential impacts and how BAs bring value to all projects.
A note about configuration
Most modern package software is highly configurable with hundreds of settings that impact software functionality.
If your project team has not worked with highly configurable software before, be prepared for a new layer of complexity throughout the project lifecycle.
- BAs may need to consider configuration settings when writing business rules or detailed requirements.
- Projects may require a separate phase of “configuration testing” and piloting the package.
- BAs may need to educate testers about configuration settings and help them trouble shoot issues/bugs to determine if the errors are configuration errors or system bugs.
BAs will be supporting even more package software implementations in the future. If you haven’t experienced a package software project yet, you will soon—be ready.
Don't forget to leave your comments below.
Doodle images above provided by Dan Wagner. Learn more about Dan’s doodle art by emailing him at firstname.lastname@example.org