Business Analysis Project Types: Software Enhancement and Maintenance, COTS, and Outsourcing
The type of project impacts the categories of requirements you elicit, analyze, and communicate in your business analysis. Remember, no one-size-fits-all list exists in business analysis. Instead, make sure you know all the tools that you have at your fingertips to determine how you will complete your project.
Software enhancement or maintenance projects
In software development, software maintenance refers to modifying software products after delivery in order to correct faults, improve performance or other attributes, or to adapt the product to a modified environment.
With these projects, you can implement new features or make performance improvements to keep software up-to-date in a changing, competitive environment. In other words, a software maintenance project can involve any changes (reactive or proactive) to existing software or systems.
Here are some examples of enhancement and maintenance projects:
Adding a new feature or function to an existing system
Implementing a business policy change
Correcting a problem with the current system or improving the performance of operational software
Porting (moving software components) operational software to a different hardware platform
Maintenance or enhancement projects vary in size and complexity. Planning for commonalities across the board with these types of projects is significantly challenging because so many variables are at play, but here are a few tips to keep in mind when outlining your work plan and time estimates:
What to focus on: Spend time focusing on eliciting, analyzing, and communicating functional and nonfunctional requirements more than any other requirements.
How to deal with fast-path or emergency requests: These requests can waylay a project very easily if you’re not careful. To keep your project on track and on time, consider creating the documentation after implementation to save time upfront.
How to deal with other important requests: Perform a cost/benefit evaluation to determine whether the request is viable.
How to do analysis of multiple requests for a single release/iteration: For these projects, you have only one chance to get it right. Perform code-level analysis and build in checkpoints to reduce the risk of redundancy, conflict between requests, and the introduction of errors into production.
A checkpoint is a time in the project when you review deliverables to make sure they’re aligned with the original project objectives and scope. A review of the functional requirements document prior to building the solution is a great example of a checkpoint.
Commercial off-the-shelf projects
People buy commercial off-the-shelf (COTS) software to save development time and cost. A company can implement a COTS package as-is, customize the package, or configure it upon installation.
The ideal scenario when working on a COTS project is one in which you can elicit and analyze business requirements from the stakeholders before selecting a package. In reality, however, some companies purchase software packages and then ask your team to implement the software after the fact.
For COTS projects, your primary focus is on business requirements — including the business processes and data requirements. You should do less work on functional and nonfunctional requirements unless you’re customizing the system.
If you take on a COTS project, the tasks you need to build into your work plan after you’ve determined the business need are typically as follows:
Performing a gap analysis on the existing functionality for the business process to be changed: By performing a gap analysis of the goals, the data requirements, the process mapping between the current process and the process associated with the COTS product, and usability, you can help determine whether a COTS product can be implemented as-is or needs customizations. This process is the as is or how analysis.
Regardless of the size of the COTS product, make sure your work plan gives you enough time to determine the need and impact of customizations or operational process changes. If customizations are necessary, they can get expensive and cause upgrades to be lengthy.
Confirming the recommended solution and determining whether customization is necessary: This is the to be or how analysis.
Outsourced or offshore development projects
Today’s projects usually include team members in multiple locations and often involve outsourcing. These projects have a higher difficulty and risk of failure because of potentially conflicting culture and communication norms.
Stakeholders in different locations can negatively impact the momentum and the team’s ability to all have a clear understanding of the goals and direction of the project. Often, formal planning is necessary to successfully ensure that everyone is clear on how the analysis effort will be conducted. In general, you work with the business directly to understand its needs rather than with development team members in another country.
When dealing with outsourced or offshore development projects, include these kinds of tasks in your work plan:
Conduct a feasibility study to give the team members a sense of what they can accomplish.
Define key objectives and measurements for success so members can point back to them during the project to ensure they’re on track.
Gain agreement (including a formal review process) for the deliverables.
Create a project glossary for all appropriate terms and definitions.
Document and discuss all assumptions, risks, and constraints.
Define clear acceptance criteria for requirements.
Plan activities for team-building communication with the external team.
Additionally, you and your team should look at ways of supplementing your communication efforts by using collaboration tools.
Keep in mind that the decision to outsource or use offshore development is often made outside your project’s scope and your control. Your team needs to clearly prioritize the requirements and take an approach to incrementally work on one function or feature at a time.
Because many offshore development teams are in different time zones from the users and the rest of the team, working on a small subset of features at a time is more manageable than trying to complete the requirements for all features. Working in small chunks makes it more manageable for the team.