Key Concepts
Gather requirements in two phases: initial requirements for the company and detailed requirements for the first sites
Prioritize requirements based on objective criteria
Establish a process to deal with requirement changes
Avoid excessive requirement changes in the middle of development
As every executive knows, when a company decides to engage in a new project, the first step must be to establish the scope of the project and to develop a clear project plan, which must be followed during the lifetime of the project. The project plan is typically designed with some flexibility so that any subsequent scope changes are reviewed and then accepted or rejected.
Just like any traditional project, development of an e-commerce platform, and implementation of multiple sites on such a platform, must be closely controlled by project management. The presence of multiple players from different parts of the company who compete for the same development resources makes close control even more important.
The pressures can be enormous, with all participating players trying to sneak in as many of their specific requirements as possible.
The reality is that during the initial requirements gathering phase, when the shared commerce platform project is just beginning, the lines of business might not be interested in spending any time to help the project team understand the requirements. From their point of view, their priority is to generate maximum revenue and profit, hopefully in the short term. When the commerce project is merely a concept and its anticipated implementation seems distant, the lines of business have little interest in spending time and resources to educate the implementation team about their requirements.
However, later in the cycle, when development of the project is in the advanced stages, suddenly the various lines of business start to realize that this is their chance to ensure that the commerce platform suits their needs, and to improve upon the current commerce solution that they use. At this point, the lines of business are likely to start coming up with all kinds of requirements that had not been thought of before. If these requirements are not anticipated and not managed well, potentially they can lead to the collapse of the entire effort.
One possibility is that as new requirements are accepted, the project scope will increase way beyond what is achievable. Naturally this leads to the project running over time and over budget. In the worst case, this can lead to the cancellation of the project.
On the other hand, if the new business requirements are always rejected, it can lead to the lines of business stopping their support for the project. From their point of view, they have a perception that the new platform does not answer their needs, and they cannot transfer their sites to this shared infrastructure.
Both of these possible situations are unacceptable and eliminate the entire benefit of having a single platform for all sites operated by the business. Therefore, it is important for the project team to be careful both about gathering requirements in the inception phase of the project and about examining and accepting new requirements after the project development is under way.
Two phases of requirements gathering are necessary to establish the scope of the project.
Initially, it is necessary to understand the business of the entire company at a high level. That is, the project team must have an understanding of the major market needs in the area of commerce of all lines of business that would potentially take advantage of the new commerce platform. They must also understand the major difficulties and pain points that the lines of business are experiencing and the key strategies that are in place for the future.
The second phase of requirements gathering must focus mostly on the initial sites that are to be implemented. This phase is much more focused and restricted in scope, and its intent is not just to get high level requirements, but also for the implementation team to collect and understand as deeply as possible all requirements for the sites to be implemented.
An important reason to study the company’s overall high level requirements at the outset of the project is to determine the scope of the project and to select the lines of business and the sites that would be the most appropriate to be the first users of the new shared commerce platform. Ideally, these lines of business are the ones that have the most to gain from a single multisite platform. At the same time, these sites should be the ones whose requirements are the least difficult to implement.
A good example of difficulties involved in putting sites on a single platform is changes to the company’s existing infrastructure. When the project team understands the requirements of the many different divisions and their sites, they can select those sites that require the least effort to create the first version of the platform, as we describe in the next section.
One of the most difficult aspects of a project to create a new commerce platform is changing the company’s infrastructure. Let’s say that there are two divisions, each one having its own site. One division’s site captures the orders with bill-to and ship-to information and then transfers them to the division’s order management system that is the basis for the processes involved in handling payment and fulfilling the order.
The other division’s site captures the order, approves the payment, and only then transfers the order to this division’s order management system.
You can see a comparison of the two processes in Figure 10.1.
When both sites use the same common commerce platform, it is theoretically possible to preserve the unique order management processes of each division for each site. However, for consistency and cost effectiveness, it would be much better to ensure that all divisions follow the same basic order flow, even if they do continue employing their own order management systems. In our example, perhaps they would agree on the standardized flow, as is shown in Figure 10.2.
With the standardized flow, all payment approval is handled by the commerce platform, rather than by the order management systems. This way, the basic process to hand off the order to the various back-end systems is consistent, and from the company’s point of view, the commerce platform is responsible for all payment approvals.
Although this arrangement might be beneficial, it requires that changes be made to existing infrastructure. Previously, the order management system of Division 1 implemented the integration with its payment provider. With the new approach, the order management system must be modified so that it no longer requests payment authorization from this payment provider before processing the order. Instead, it relies on the authorization already received when the order was captured on the site.
At the same time, with this new arrangement the shared commerce platform must provide integration with all the payment providers of the sites that use the platform. This in itself is a nontrivial effort that is likely to carry a significant cost.
We see that the introduction of a common commerce platform might imply changes to existing processes and to the systems that implement them. Such changes can be very expensive and time-consuming.
When the project team selects the first few sites to use the new platform, it is better to select those sites that have similar order flows and that do not require re-engineering the order processing systems. Perhaps there is another division in the company that does payment approval by its order management system, similar to Division 1, and therefore the order flow can remain unchanged. In this case, we would have Division 1 and Division 3 as initial participants on the new platform. The order flow in this case is illustrated in Figure 10.3.
Another reason to get an overall high level understanding of the needs of the entire company is to determine the correct architecture of the new platform at the outset. Certainly, there is no need to implement any requirement that is not necessary for the initial sites that will use the platform. At the same time, however, the architecture of the platform must be flexible enough and forward-looking enough that additional functionality can be added later.
To illustrate this, imagine a company that sells to consumers in many countries around the world. Let’s say that the initial use of the new platform is planned for the site in the United States, and the Canadian site is to be added in the next phase. One important requirement for the Canadian site would be to allow customers to choose between the English and French languages, whereas there is no need for any language other than English on the U.S. site. This means that initially multilanguage support is not needed for the new platform.
However, the design of the platform needs to allow for adding translations of all materials at a later time. This way, when the Canadian site is added, there will be no need to redesign catalog presentation logic to enable it to show material in the customer’s preferred language. Instead, at the time when the Canadian site is created, French language catalog data will be loaded into the catalog, and customers will automatically be able to see the catalog in French.
Similarly, there is no need initially to design the home page of the site in such a way that customers can select the language of preference. However, the platform must fundamentally support the ability of the customer to set the preferences, such as language preference.
We see the initial phase language support must be designed into the commerce platform’s architecture, even though at that point actual translations of data are not necessary.
The second phase of the initial requirements gathering must focus mostly on the sites that are implemented. This phase is much more focused and restricted in scope, and its intent is not just to get high-level requirements, but also to collect and understand as deeply as possible all requirements for the sites to be implemented.
As mentioned before, it might be difficult to get the attention of the line of business managers who are familiar with requirements at this early stage in the project. The core implementation team must therefore not only gather the requirements, but also understand the business. They must learn the business deeply enough that they can get a feeling whether the requirements gathered are sufficiently complete to justify proceeding, or whether the requirements are too unclear.
It is unavoidable that some new requirements will come up during the lifetime of the project, and the project plan can be made with built-in contingency and flexibility to allow for limited changes or additions. However, it is impossible to plan for a project when the requirements are not settled at all but are constantly changing.
Therefore, part of the responsibility of the project team is to make an evaluation as to the reliability and completeness of requirements. You might wonder about this: How can the implementation team realize that there are aspects of requirements that it doesn’t know enough about? In other words: How is it possible to know that there are things that you do not know?
The answer to this is experience. Good project managers, business analysts, and technical architects that have practiced their trades for many years, usually develop an intuitive sense of completeness of requirements. Someone who has been through many project cycles, and has experienced both successes and failures, knows when requirements are insufficient for the project to proceed. Experienced project leaders can also know when enough of the requirements are understood to the point that the unknown can be dealt with in the contingencies of the project plan.
Even though the initial feel that the requirements are insufficient often depends on the experience and intuition of the project leaders, these leaders can then quantify somewhat this intuitive feel for lack of requirements. For example, they can do this by pointing out contradictions between opinions of different subject matter experts, or by contradictory requirements from different lines of business. They can also list major areas where requirements are unclear and give examples of major unanswered questions. It is important for them to point out how, depending on the answer to the big questions, implementation needs to take a different direction. In some cases, requirements change even while they are being gathered—this is also a bad sign, and such changes must be noted.
With such quantification, you can build a reasonably objective case why the project is bogged down in requirements gathering and request greater cooperation of the lines of business. The project team can then approach the executive sponsor and present the case, asking for help to get greater attention from the relevant lines of business to make greater effort in explaining the requirements, or in resolving the contradictions. Ultimately, the executive sponsor is appointed precisely for this purpose—to bridge the gaps between different departments within the company and to ensure that necessary cooperation takes place.
We see that the success or failure of the project in large measure depends on the intuitive feel of the project team at the early stage in the project, as to whether requirements are understood. It also depends on the ability of the project team to clarify and quantify its perception, and ultimately only the executive sponsor can cause different departments to cooperatively arrive at a reasonable set of requirements.
It might not be comforting that the life or death of a large project depends on such subjective factors; however, this is the reality of the life of all projects. Ultimately, the most important thing is to avoid launching an expensive development effort without clearly understanding the requirements. There is an old joke about a programmer who is relaxing by his computer. When asked why he’s not busy, he answers: “I was told the project is urgent and work must start before requirements are finished. There’s no point working—the project will die anyway.”
One common scenario is that a business rule is truly specific to only one geography and is not perceived to be important to the platform overall. For example, in South America it is common to make credit card payment in installments. So a customer often requests to split the payment for a purchase into several monthly installments. The payment providers operating in that geography provide services to commerce sites that make such payments easy to configure.
However, in North America such installment plans are uncommon for the vast majority of commerce sites. Although installment plans are widely used for big-ticket items such as cars or furniture, they are generally not available for smaller online purchases.
Now imagine a company that operates both in North America and in South America. If most of its business is in North America, the IT department might be unwilling to accept the requirement of installment plans because they would consider it to be of marginal benefit to the company, compared with other improvements that can be made for the North American sites.
As a result, the installment plan requirement might be rejected. However, without this support, the South American sites end up under-performing because many customers there will be unwilling to place their orders.
The project team must therefore have a mechanism to weigh the different requirements and to prioritize them. Most likely, there are a lot more requirements than the project schedule allows, and those requirements that are most needed for the company’s sites need to be selected.
To make such a prioritization objective, it is a good idea to create a set of simple criteria. Table 10.1 shows an example of a few characteristics that you can use for this assessment.
Certainly, each company needs to decide on its own set of requirement evaluation criteria. The overall idea though is that the project team must collect this input for all requirements so that it has a clear picture of the consequences of accepting or rejecting each requirement. The team can then make prioritization a reasonably objective process, which is inherently not subject to constant challenges and disputes.
Although we have insisted up to now that requirements must be gathered before a major work effort is launched, the reality of large projects is that it is impossible to know all the requirements from the start. There are many scenarios that lead to changes in requirements even as the work progresses.
One possibility is that due to market conditions, the business has somehow changed, and a new capability is necessary to be competitive. For example, the competition might have started offering their customers the ability to authorize returns online, rather than asking them to go through a call center. This way, customers can be more comfortable buying products on the site because they are assured of a quick-and-easy self-service returns process that requires no complicated approvals. To compete, the business might request that the sites on the platform also have this capability, even though it was not in the original requirements.
Another scenario can be that the business has taken the decision to offer a new product line, and the new products require a new capability that was not originally requested. For example, perhaps the new product line requires customers to enter additional specifications on the product, such as engraved text or instructions to the installer. If the original requirements did not specify allowing customers to put in extra comments on the order, this would be a new requirement.
One of the most common scenarios is that, as the project develops, the business starts assigning more resources to review it, or for personnel to be educated about it. Even though during initial requirements gathering, it might have assigned several subject matter experts, invariably new comments will be accumulated after the larger business team has a chance to understand what is being developed. In some cases, business managers might have suggestions to modify the original requirements to improve either the customers’ experience on the commerce site or to make it easier to administer. Examples of this might be additional shortcut keys, additional reports, or links between pages. Similarly, new suggestions might be made to implement additional features that improve some aspects of the sites or provide additional features for site administrators.
With all these possible reasons for plan changes, typically the lines of business are the ones that propose changes or additions, whereas the responsibility to respond to these proposals rests with the implementation team. Occasionally, however, the roles can be reversed. Sometimes the source of proposed additions or changes is actually the technical implementers, rather than the lines of business. Their suggestions usually are based on improved understanding of what is possible as a result of deeper design and experience by the developers.
For example, let’s say the original requirement was that a new site must be reviewed and approved by two levels of authorization before it can be used by customers. The technical implementers might suggest that rather than implementing a complex approval workflow, they can save time and effort if instead a single approval were to be sufficient. With such a suggestion from implementers, it is now the job of the business to respond as to whether it can tolerate the proposed change.
Producing a system from a specification is like walking on water; it’s easier if it’s frozen.
We have seen that for a large commerce project, especially one that affects multiple lines of business, requirement changes are unavoidable. Such changes invariably affect both the cost of the project and its duration, and if not managed properly, they can affect the success of the new platform. Therefore, there must be a formal process to articulate new requirements, justify them, review them, and decide whether they should be accepted and implemented.
Typically, each proposed change must be described, including not only what is needed, but also why it should be done. Justification can be based on increased revenue estimates, cost reductions, improved system security, or other factors but must be clearly quantified. Typically there is a committee that is responsible to review these changes and to prioritize them. The high-priority proposals are then examined in more detail to determine their impact on the plan both in terms of cost and time. Then the committee makes a decision on which changes are approved and which are rejected. For a project to create a shared commerce platform for multiple lines of business, this process is no different than for any other large project. However, there is an extra factor that comes into play that makes the process a little more intricate.
In some cases, change proposals might be rejected not because they are difficult to implement but because they clash with other requirements. Typically, each line of business is only concerned about its own business and only worries about its own requirements. There might be requirements that focus entirely on its business and which contradict requirements from other divisions. The following is an example of such contradictory requirements.
Example of Clash of Requirements
Let’s say the company decides to create a site for each country in which it does business. The company does not want to create separate sites for business customers and consumers but wants to use the same sites for both types of customers. For consumers, the requirement is to self-register on each site quickly and easily with no need for approval by a customer service representative. On the other hand, the company does not want business customers to register automatically; instead, they want all registration requests from business customers to be reviewed by sales representatives, to make sure the customer is not already registered, and also to ensure that this business is in good standing.
If this contradiction were discovered in the initial requirements phase, perhaps the implementers could have suggested that business customers and consumers should use different sites so that each site can implement processes specific to its customers. However, once the project is under way, it is difficult to redesign the platform. This is because the change affects not only the technical details of the platform, but also the entire infrastructure that the business sets up, such as administrators, sales representatives, call center, and help desk. It is unfortunate that a contradiction in requirements has been discovered late in the cycle, but still the implementation team must decide what to do.
One possible solution might allow all customers to self-register but to also maintain a special attribute that indicates whether the customer is a consumer or a business. The registration process for business customers would then consist of them creating their own profile on the site, and then call a customer service representative to mark their profile as belonging to a business user.
This is an imperfect solution because it requires more complexity from the site’s business processes and business logic, but it might be enough to resolve the problem to the satisfaction of both the B2C and B2B lines of business. In this solution, preference is given to the requirements of the consumers, who can self-register on the site quickly and easily. Business customers have a more cumbersome process to follow, but it might be deemed acceptable within that market segment.
Fundamentally, the plan change process for a shared commerce platform deals with the politics of resolving and prioritizing requirements of one line of business over those of another line of business. The key to success is making decisions that do not totally alienate any of the participating players but which are both reasonable and acceptable to the business.
However, there can be cases where the requirements truly clash and the contradictions cannot be resolved. The new requirement can also be deemed to be too large in scope and clash with the project schedule. The two possible approaches to resolve such serious clashes are the rejection of one of the requirements or changing the project scope.
Rejection of a requirement can mean that it will not be looked at again. However, more often rejection simply means that the requirement is not accepted into the current phase, but it will be looked at when planning a future release of the platform.
Rejection of requirements is sometimes seen to be bad for the business that proposed them but good for the implementers who have one less headache to worry about. To make the rejection palatable to the business, it is very important to establish a process where it is completely clear to everyone involved that both perceptions are false.
It must be clear that requirements are not accepted or rejected because technical implementers like or dislike them, but only because of their ability to implement them. In the end, the shared commerce platform is paid for, and serves the needs of, the lines of business, and therefore it must be completely subservient to the lines of business. The following example illustrates this relationship between IT and lines of business.
Example of Rejection of Requirements Leading to Project Failure
There was a large corporation that was trying to implement a shared commerce platform, and the business had the requirement that all pricing calculations be done upfront when the order is calculated. This had been a constant irritant to the business with its previous sites because due to complexities of the pricing process, the customer only saw the approximate price when placing the order. The final calculations were performed later when the order was processed, and as a result, the price shown on the invoice would sometimes differ from the price presented on the site during checkout. Usually the difference would be no more than a few pennies, but still this was seen as an irritant to the customers.
Although the requirement was quite clear, the technical implementation team was unwilling to even explore possible ways of how it could be implemented. It was faced with an array of legacy systems and processes, where many pricing calculations were done after the order is placed, and changing these processes would require an in-depth review of system capabilities, and a redesign of many business processes.
In the end, due to the implementers’ resistance, the new platform did not change this pricing process. Instead, the new platform continued using the same policy of only providing preliminary pricing during checkout, with an advisory warning that the actual invoice might be different.
It is hard to say that this is the most important factor, but certainly it was one of the reasons why the shared commerce platform was never fully adopted. After a few years, the entire system was scrapped, requiring an expensive effort to create a new platform.
As much as it is important for the implementation team to be responsive to requirements, it is equally important for the lines of business to be understanding of what is possible and what should not be attempted. If the implementation team cannot commit to a business requirement, rather than voice complaints, the two organizations should work together to come up with an acceptable alternative.
Again on the issue of pricing, a large company selling to businesses with prearranged price contracts had the requirement to give discounts on entire categories, but also to exempt certain products or subcategories from the discounts. The implementation team found it difficult to provide visual tools that can do all this within the time and budget allocated to the project. Instead, they proposed to load the pricing rules from a spreadsheet. Although this is not a perfect solution, it did achieve what the business wanted, even though it required more training for the staff. Thanks to the compromise the new platform became successful, and the implementers started thinking about improving the tools in subsequent releases.
To summarize, requirements must not be rejected haphazardly but only when several conditions have been met. The first condition is that the reasons for rejection are articulated and are based on clear and objective analysis of the issues. The second condition for rejecting a requirement is that the business must be given an alternative, even if uncomfortable, as a way to meet its business goals. If both conditions are met, and if both the implementation team and the lines of business understand this process, rejection of a requirement will not lead to subsequent dissatisfaction and dispute, but instead will lay the groundwork for future releases of the platform.
Changing the scope of the project is an extreme measure, which should only be done with the approval of the executive sponsor of the project. Scope change can only be the result of a drastic change in requirements in which the magnitude of change is such that the original plan cannot accommodate the changes.
Even though sometimes it is hard to distinguish between them, it is important to differentiate between scope changes and implementation problems. Both situations lead to the same result, namely greater expenses and late delivery; however, their perceptions are very different. Late delivery due to scope changes is justified and is understood to be unavoidable by all parties involved in the project. However, late delivery due to implementation problems is a symptom of planning or delivery failure, which must be investigated and corrected to avoid its repetition later.
The “acid test” of an anticipated scope change is the appearance of new players involved in the project. An example of a justified scope change is that the line of business whose site was to be the first deployed on the new platform has been sold, or has been merged with other lines of business. Such circumstances necessarily change a re-evaluation of the platform, and the need to determine the new high-priority sites that will be the first ones to be built on the new platform. Because the other sites will likely serve the needs of different lines of business, clearly major requirement changes are to be anticipated.
On the other hand, if none of the players have changed, but the project is late, this should be a cause for concern. Is it late because the implementation team simply didn’t implement all the requirements on time? Or is it late because proposals for requirement changes were not managed properly? Or perhaps the project was mismanaged from the start because the plan was created and the implementation effort was launched when requirements were not yet clearly understood? In the worst case, fluidity in requirements can be indicative of chronic infighting within the company about what the scope should be and what the best requirements are.
Whatever the case is, if the project scope change request is put forward, only the company executives, led by the project sponsor, can ensure survival of this new commerce platform. Before authorizing a scope change, the project sponsor must be sure that the requirements have changed significantly and at the same time understand what caused the change. Authorizing the extension of delivery date, or approving additional costs, is justified only if the executives have been given reasons to believe that this is the last such change that is necessary before the project is delivered.
To develop a multisite commerce platform, the initial requirements gathering phase is necessary to know the scope of the project and also to prioritize which sites will be developed first. Subsequently, detailed requirements must be gathered for the commerce platform. These detailed requirements are given to the implementers by the lines of business that take part in the first phase of the project.
Experienced project managers and technical architects must make a determination whether requirements are sufficiently complete so that development can begin. Until this determination, it is better to avoid investing too much into development.
Requirements must be prioritized based on clear and objective criteria. Only the high-priority requirements must be adopted to make sure the project meets the cost and schedule constraints.
As the project progresses, requests for changes in requirements might come up due to the changing needs of the business that are initiated by the technical implementers or by divisions.
Requirement and plan change proposals must be evaluated in an objective and transparent manner. Acceptance or rejection of requirements must be based on clear objective criteria. If the proposed changes are rejected, a reason for the rejection by the implementation team needs to be given, and an alternative approached should be suggested.
It might sometimes be necessary to change the scope of the project. If so, the change should be given executive approval because it increases the cost of the project and delays the delivery date. Project scope change should be approved only if the reason for it is justified.
Scope changes must be distinguished from delays and cost overruns. The former can be approved by the executive sponsor if the reason for it is justified. However, project delays might indicate management problems in the project and, therefore, should be approved only if the underlying causes have been corrected.