Project Initiated by an Opportunity

Many projects are initiated to support a new business opportunity. The definition of opportunity is “a set of circumstances that make it possible to do something.” For example, a new product design may be appealing to potential customers who have not purchased existing products. A simple phone with large buttons appeals to an older population more than standard phones which are very small with a lot of features. When an opportunity is identified, the organization decides if the opportunity is worth pursuing and how it will be implemented.

Opportunities may be identified by an existing customer who asks for a customized product. They may be created by an employee in customer service who hears similar requests from many customers. Opportunities are also often identified by review of competitive offerings. Leveraging and improving on the ideas of others is a common and successful strategy. Of course, be sure that the organization is not violating copyright, trademark, patent, or any other legal ownership. The organization’s legal department will help with these issues.

Some opportunities are very large, like offering a brand new product. Many opportunities are smaller, incremental changes to existing products or processes which will improve customer service, increase quality or efficiency, or decrease costs. The small opportunities often can have a huge impact in an organization. Suppose a supermarket chain identifies a change in its distribution process that would save two cents on every dairy product sold. The savings could quickly reach millions of dollars.

When opportunities are identified, a business case should be built. Most executive-level managers are looking for the benefits to outweigh the costs before they will give approval to go forward and fund a project. Positive cash flow or return on investment is typically required because pursuing an opportunity is purely optional to an organization. Whereas a regulatory change or problem resolution may be considered mandatory, an opportunity is a choice.

The business analysis professional must be aware of the projected benefits of a project. If he or she learns something during requirements analysis that changes the scope or cost of the project, it must be communicated. It is a huge waste of corporate resources to pursue an opportunity that will never pay back its costs unless there is a significant intangible benefit. The PM and sponsor may need to reconsider the project based on the new information. It is better to abandon a bad project than to continue spending money on it when you know that the results will not pay back the costs.

Projects for Marketing or Advertising

Projects requested by marketing or advertising departments differ from other projects in that they are usually focused on selling more products and/or services, similar to opportunities. These projects are driven by an expected increase in revenue. Marketing and advertising projects include queries for direct marketing campaigns, enhancements to screens to capture additional data, new product support, customer relationship management systems, and specialized reporting. Many tend to be short projects that are needed immediately. Because they are often small projects, the BA frequently plays the role of PM and quality assurance analyst in addition to being responsible for the requirements.

These projects often make use of existing data, exploring it for sales opportunities (referred to as data mining). The marketing group may want to target existing customers for repeat purchases or other product offerings. Marketing requests are typically queries with complex criteria. For example: “We want a list of students who have attended class A, have not attended class B, live close to one of our public class locations, and have requested a catalog in the past year.” Analysts need to first ask the why question and then probe for even more criteria because marketing stakeholders frequently assume criteria without realizing it. The more an analyst knows about the data available, the better the questions that will be asked to completely detail the request. For example, the analyst might ask: “What about students who have tested out of class B?” Answer: “Well, of course we don’t want to market to them!” When you hear a stakeholder say “of course,” you are discovering an underlying assumption that the stakeholder has made that should be captured in the requirements because the SME expects that the developer will adhere to it.

For complex query requests, the analyst should not only ask questions to flesh out all of the criteria but should also review the results of the query before providing them to the marketing stakeholder. Initial query results often expose problems or challenges with the request that the analyst may be able to catch. Providing inaccurate data to the requester diminishes credibility and frustrates the requester. Carefully capturing the query criteria and reviewing the results will ensure the request is completed quickly and accurately.