Industry specific risk management (managing ecommerce initiatives in traditional enterprises)
With the collapse of the dot.com economy, many start-up organizations that integrated eCommerce into their business practices, have since folded due to the lack of realistic business plans, sustainable revenue models and stable operations. While traditional “brick and mortar” enterprises have developed much more feasible business models, they too have been affected by the downturn in the economy. As these enterprises struggle to introduce eCommerce into their core business practices, they are often challenged with unrealistic sales targets and poor project planning.
In 1996, for example, most large enterprises feared being “Amazoned” — that is, swiftly being made to look irrelevant by a newcomer with ample capital and a penchant for direct sales. This was particularly the case when the larger book retailers panicked and began to immediately establish online ordering facilities, often at substantial cost and with serious flaws in the design and deployment of their software. This presentation serves as an educational tool to help large enterprises:
- Understand the project risks associated with many eCommerce initiatives of established enterprises
- Identify early warning signs that can be monitored and quantified to different stakeholders of each project
- Respond rapidly and cost-effectively to those risks without undermining corporate and project goals
The principles outlined in this approach promote active risk management and can be applied to eCommerce projects as well as others.
Risk management discussed here is based on lessons learned from real-world experience with eCommerce projects for large enterprises and dot.com start-ups. The project issues presented are mapped to the Project Management Book Of Knowledge (PMBOK®) knowledge areas. The issues and risks presented are the synthesis of key issues we faced in our experiences in real life projects. Although we touch on all PMBOK® knowledge areas, our primary focus area is the interrelationship of Risk Management to the knowledge areas of Scope Management, Time Management and Human Resources Management. In this document we have introduced a sample of those risks and “knowledge areas”, which we will be elaborating in our presentation.
We discuss how the outputs from each of these knowledge areas are affected due to different business issues. We have in this presentation attempted to provide a framework to help project managers map appropriate PMBOK® knowledge areas to the potential issues and leverage the PMBOK® tools and techniques in those knowledge areas to address the risks methodically.
Following are some of the risks the team identified during “Risk Identification” process in the initial stages of the project.
- Dealer Channel not embracing the system leading to failure of alternate online channel emergence
- Lack of widespread consumer acceptance leading to channel failure
- Customer dissatisfaction leading to channel failure
- Aborted transactions resulting in loss of revenue and customer dissatisfaction
- Immature technologies resulting in unpredictable behaviour
- Declining project morale leading to missed deadlines
The project scope is initially defined by a small representative set of users. As the project progresses through it's lifecycle, different user communities become involved at varying levels. Hence towards the latter stages, the unexpected complexity is inevitably discovered, and is not covered by the schedule. Moreover, It is difficult to obtain good stakeholder representation, especially for the customer community
The examples identified below require significant involvement from the direct and indirect user population, including dealers and consumers, to make sure the system will be well received. Inadequate involvement of these users during various phases of the project leads to issues during acceptance testing and rollout, creating a serious scope problem during the later stages of the project.
- Minimize competitive and comparison pricing
- Calculate tax based on local tax laws
- Facilitate returns
- Fulfil orders from dealer's inventory
The following section uses the specific requirements listed above from the project, to highlight the PMBOK® processes and tools applied, to address the identified risks as illustrated in Exhibit 1
Minimize competitive and comparison pricing
A typical defined requirement for dealer locator is to allow consumers to select a dealer from a list of dealers returned by a zip code search. Since dealers have the ability to set the prices for each item they sell online, the price for the same item can vary from one dealership to another. While dealers can set their own retail price, they are restricted by a floor and ceiling price set by original equipment manufacturer's corporate pricing rules. Herein lies the challenge.
Consumers want to be offered the best available price, and the ability to search an item by price across dealers. However the dealers would like to differentiate their storefront by the value added services they provide rather than facilitating a commoditized “purely price based shopping”.
The project team reviewed this requirement against the “Business Needs” documented in the “Project Charter” and found the early warning signs of the “Identified Risk” “Dealer Channel not embracing the system”. Specifically, the early warning signs observed were:
- Too easy for the dealers to lose a customer - Consumers could easily change their dealers and subsequently break the sales relationship
- Too easy to use the application as a quotation tool rather than an ordering mechanism for part and accessory sales
The mitigation plan developed was to improve stakeholder representation. The “Project Stakeholders” were involved based on their relative significance and impact on the project charter. In this case, the stakeholders were the corporate users, the dealer advisory board, and the consumers. However, the requirements workshops were conducted with only the corporate users and the dealer advisory board – and did not involve the consumers or their representative bodies.
Applying the above PMBOK® tools and techniques, the original requirement evolved to include the following features thus addressing the above risk.
- Allow consumers to select from an expanded list of dealers.
- Empty all items from the shopping basket, if a consumer changes, his or her affiliated dealer.
- Restrict consumers from changing their affiliated dealer, if they navigate from dealer's website
Calculate tax based on local tax laws
Selling items online requires a keen awareness and deep understanding of taxation issues. While compliance with government regulations is a fundamental business practice, there are many complex tax issues that have to be taken into consideration when designing an eCommerce site. Thus, dealers who wish to sell items online must complete the necessary paperwork acknowledging their understanding, that they are responsible for declaring all taxes from online sales to their local jurisdictions.
Dealers must also meet internal restrictions the manufacturer imposes, such as agreeing to price restrictions, returns policy, prior to performing online business. Dealers who do not comply with these regulations will be excluded from affiliate programs that would otherwise provide access to consumers for their parts and accessories purchases. Because taxation rules vary from state to state across America, to enable online transactions, it is imperative that business requirements meet the rules of each of these states.
The requirement of this particular automotive manufacturer was to charge consumers and independent repair shops the appropriate tax amounts based on the tax rate of the jurisdiction where the product will be shipped.
When reviewing these requirements against the “Constraints” identified during the “Initiation” process, the project team discovered the early warning signs of the “Identified Risk” “Lack of widespread consumer acceptance”. The early warning signs related to this risk were:
- Taxes need to be calculated based on the taxation policy of the jurisdiction where the product will be shipped. Therefore, having the shipping address information was critical when an item is added to the basket. However, this critical piece of information was captured only in the latter stages of the process.
- Dealerships must opt-in to jurisdictions to sell certain products. If no dealers within a state have opted into a jurisdiction, consumers within that state can't buy the product.
- Zip codes can contain multiple geo-codes. Tax is calculated at the geo-code level. Different customers living in the same zip code can get charged different tax rates and hence pay a different price for the same product.
This perceived inconsistent behaviour would result in consumer dissatisfaction leading to lack of acceptance.
By following the above process the project team recommended the “Corrective Action” of introducing a new stakeholder community. In this case, the additional stakeholder community was the enterprise's Tax Department. They provided the expert judgment on how to evolve these requirements. As recognized in PMBOK®, “stakeholder identification is often especially difficult”(PMI, 2000, p.24). Since this project adopted active risk management and had a-well defined set of outputs from the initiation process, we were able to include additional stakeholder representation and increase their participation.
The Tax Department and the Dealer Advisory Board resolved the above risks by modifying the requirements to present the estimated tax based on the dealers address when adding items to the basket. This was decided because the majority of orders will be delivered to the dealership, and subsequently used in that geographical location. The actual tax is calculated based on the customer's shipping address, prior to checking out and confirming the order.
Returning any product purchased online has been a challenging situation for online businesses. In fact, certain businesses, for example deep discount retailers, depending upon their specific business model, do not even accept returns for merchandise purchased online.
An enterprise concerned about customer satisfaction must be able to facilitate returns. However, the franchises must also participate in this process. The original defined requirement outlined within the project charter stipulated that users should be able to return any product purchased via the web site within thirty days. If the return happens after the thirty-day window, then it is the dealer's discretion if they wish to process the return. When evaluating this requirement, it is crucial to evaluate the needs of both the consumers and the franchises.
Applying the PMBOK® tools and techniques of “Scope Definition”, specifically “Decomposition”, the following early warning signs were identified with the stated requirement:
- Any dealer other than the selling dealer couldn't process returns.
- Should shipping, labour and other charges be refunded?
- What happens if the original credit card is no longer valid?
The project team reviewed these early warning signs against the “Identified Risks” and realized that Customer dissatisfaction with the inflexible return policies could significantly undermine short-term sales and long-term customer loyalty. The project team implemented an explicit “Scope verification” process to review the requirement and the associated risks. Thus, the policy on returns had to be clearly defined and made accessible to the consumer up front.
Due to the significance of the risk, the executive level project stakeholders were requested to clearly rethink how they handle and process returns. After reviewing the requirements and carefully considering the risks and alternative options, the executive stakeholders decided to adopt “Acceptance” as the “Risk Response” strategy. Although the risk remained, the project team and the stakeholders were satisfied with the resolution, as they had adopted widely accepted processes and procedures.
Fulfilling orders from Dealer inventory
Once online orders within a traditional enterprise have been authenticated, they will integrate with legacy fulfilment systems to allocate and fulfil the order. Hence it is expected there would be few enhancements to legacy systems to fulfil these orders, as the orders should integrate into the existing fulfilment processes. The orders will then be allocated from one of the parts warehouses.
However, dealers may already have the items ordered by the consumer in stock. If the order is to be installed at the dealership, and the dealer has an abundance of these items, then the dealers should be allowed to fulfil the order from their inventory. Therefore, the requirement was to provide dealers with the opportunity to fulfil dealer installed orders from their local inventory.
This initial requirement was decomposed into several specific requirements, which produced the following early warning signs:
- Dealers need more time to fulfil an online order. Processing orders that night does not give dealerships throughout the various time zones and equal opportunity to fulfil these orders. Also a dealer does not know when an online order has been placed.
- Dealers had the ability to fulfil the entire order and not a portion of the order. This significantly reduced the opportunity for dealers to fill the order.
- If a dealer fulfils a portion of the order, and the remaining items are backordered, can the customer pickup the fulfilled items at the dealership?
The team reviewed the early warning signs of this issue against the “IdentifiedRisks” and realized there was a high risk of the “Dealer Channel not embracing the system”. Even though the application is a consumer centric web site, without resolving these issues, the dealers would not buy into this process, and would be reluctant to sign up to sell items online.
While the Dealer Advisory board represented the entire dealer community, they were not able to come up with a recommendation for addressing this risk. As part of the Risk Mitigation strategy, it was decided to extend the “Scope Verification Process” to the larger set of dealers by providing access to the pilot system. This led to the recommendation to expand the scope by providing dealers an interface to fulfil partial or complete orders from their inventory, and giving them a minimum of twenty-four hours to fulfil these orders, irrespective of their individual time zone.
In this section we present examples of integration points in a project, which typically exists as one or two milestones in the respective project plans. Since a different vendor manages each plan, it typically does not provide for multiple integration iterations for each module. Even if the plan provides for those integration milestones, no time is allocated for testing the upstream vendor integration points. This leads to having the downstream vendors absorb the cost and the schedule lapses, which introduces more issues to the project, jeopardizing its overall success. This segment addresses the key challenges from a cost and schedule perspective, how to effectively surmount those challenges.
Following are the modules that were used in the project. We are utilizing one example of integrating a vendor's commercial software product and a sub-contractor's custom developed application to illustrate the above points.
- Commercial software products: Taxation module, Credit card module
- Custom developed applications: Dealer locator, ERP systems, Dealer systems
Prior to the project engagement, the enterprise conducted an exhaustive analyses of “off the shelf” packages which featured Basket Management, Credit Card Processing and Tax Calculation capabilities. The analysis on these products was performed more from a technical rather than a functional perspective. Factors such as technical architecture, long term maintainability and support were key selection criteria. The online parts and accessories store project needed to be developed with interfaces into these products.
As part of the checkout process, taxation is calculated based on the dollar amount of the order, and the geographical location of the consumer's shipping address. In addition to calculating tax to be paid, the application is also designed to refund all relevant money to the consumer including a full refund for the product, shipping, labour and tax. During the Integration Testing, the quality assurance personnel attempted to return orders consisting of more than one line item. The interfaces were designed to process each retuned line item separately. The first line item would be successfully returned and all relevant monies associated to this line item were credited back to the purchasing credit card. However, when the second line item was processed as a return, the tax calculation product would incorrectly calculate the returned tax. There was a rounding issue with the taxation application and the returned tax exceeded the original tax amount by one cent. The resulting effect was that the consumer would not receive a credit on their credit card for the second line item, as the refunded amount would exceed the original transaction amount.
Because the development team's knowledge for the above-mentioned packages was limited, the project plan was developed with significant contingencies for tasks associated with integrating these products. Since the risk of “Immature technologies” was perceived to be high, the “Risk Response Planning” supported building sufficient contingencies as a “Mitigation” strategy. However, the assumption was that all these products would not have critical defects.
Even though we had significant contingencies incorporated into the plan for activities such as prototyping and integration testing, these contingencies were consumed exclusively for skill development. The schedule did not accommodate addressing the defects found in vendor products. These were critical defects that would prevent the project from meeting the stated objectives. During the project “Initiation Process” the project team had established scope as the primary “Triple Constraint” and obtained buy-in from the executive sponsors. This enabled the project manager to request additional cost and schedule changes from the executive sponsors.
The dealer locator module was developed to provide a common web interface to retrieve dealerships based on a zip code geographical search. The dealer locator module had to be integrated with multiple modules such as the parts catalogue system and accessories catalogue system. The requirements for the dealer locator module were finalized prior to developing the requirements of other modules. The dealer locator module functioned as per the specifications in an isolated environment with no other applications integrating with it. The online parts and accessories store facilitated the ability to sell accessories, subscriptions, parts and other licensed products. The dealer selection process involves the implementation of a large number of multiple business rules. Specifically, each dealer must be “business certified” on the basis of individual dealer profile such as volume of sales. In addition, dealers must also be certified for each product category they sell. Furthermore, dealers must also be “technically certified” for credit card processing and settlement processes at the bank.
In order to actually sell parts and accessories to consumers, each dealer with a merchant number has to be set up to sell online and have a store created for them. Although it is possible for the dealer locator to list dealerships regardless of whether the dealer has an online store setup or not, it is not possible for consumers to actually purchase products online from any dealer who does not have an online store.
The requirements for the dealer locator changed during latter stages of the requirements definition of the online store. Since the team representing the dealer locator module was not represented in the requirements definition process of the online store there was no opportunity to determine that the new requirements of the applications would lead to additional requirements for the Dealer locator.
Once the requirements of the online store was finalized the team performed “ProjectAssumptions Testing” as part of Qualitative Risk Analysis, against all key dependencies. This highlighted the fact that the dealer locator module did not meet the evolved requirements for locating the dealer. This was mapped to the “Identified Risk” “Aborted transactions”
The dealer locator vendor performed the assessment to make the changes, and the projected schedule changes were incorporated into the master project plan. The resulting impact was that the dealer locator module became a critical path task. Since there were multiple applications dependent on the dealer locator, an impact analysis was performed and determined that the risk of not meeting the overall schedule was very high. During the project “Initiation Process” the project team had established schedule as the secondary “Triple Constraint” over cost after scope.
It was decided to incur the additional cost of implementing the new requirement of filtering the results of the dealer locator based on the business rules in the online parts and accessories store modules like “My Profile”, “Checkout” and “Change Dealer”. Exhibit 2 illustrates that the changes were made in multiple modules instead of performing once in the dealer locator module and if the “high risk” option was chosen the schedule for both website I and website II would have been impacted. Instead additional cost of performing the change in multiple modules was justified based on the precedence of the triple constraints.
Human Resources Management
Initially, when large enterprises prepare to launch eCommerce initiatives, they create a separate division to run these initiatives. This division has its own budget, charter and reporting structure. Invariably this entity functions independently and has its own processes and systems. However, there are often significant challenges with integrating a new division into the overall enterprise's existing business processes and systems. Through our experience we've gained valuable insight into some practical action steps enterprises can take to integrate their organizations—with minimal disruption to their existing operations, budgets and project schedules.
“Organizational Planning Process” within “Human Resource Management” addresses the following three areas, namely “Technical interfaces, Organizational interfaces and Interpersonal interfaces”. Within our discussion, we will be focusing on the latter two areas, by addressing the following subjects:
- Integrating new business processes and the eBiz department into the overall corporate structure
- Facilitating change management and promoting adoption of the new culture
Integrating new business processes and eBiz department into corporate structure
Prior to the introduction of the online parts and accessories store, dealers could place orders through the traditional systems already in place. When a consumer required a part, they would call or visit their local dealership's parts department, which would place the order through the allocation system. The only time a dealer would be charged an additional amount was when an order was urgent, and in many of these cases the additional costs were passed onto the customer. Dealers wouldn't have to pay any additional charges for submitting regular orders via the existing allocation system.
With the introduction of the eCommerce initiative for consumers to place orders, dealers were now charged an additional electronic surcharge to process the orders through the same allocation system, as shown in Exhibit 3.
As part of “Organizational Planning” process, the project team performed “Stakeholder Analysis” and identified early warning signs of “Dealer Channel not embracing the system”. The following early warning signs were identified with regards to this risk:
- Dealers were being charged for a service that was free before.
- Dealers did not have any influence on how the order was fulfilled.
The “Scope Management process” and the “Risk Mitigation” process illustrated in this document above, effectively addressed this issue by expanding the scope to provide dealers an interface to fulfil partial or complete orders from their inventory. The dealers would have a minimum of twenty-four hours to fulfil these orders, irrespective of time zone. Dealers would now be able to place the orders online and indicate they would fulfil the order from inventory, thereby not incurring the electronic surcharge.
Integrating new culture
Enterprises traditionally have team members, who have a lot of history within the organization. These tenured members are aware of the key stakeholders and business processes interwoven within the organization. Members of the eBusiness department are traditionally younger people with relatively little experience and exposure to the enterprise culture and processes. These individuals are overly optimistic and aggressive in their approach, and therefore make decisions that are unrealistic and develop schedules that are unattainable within the enterprise model. Tenured members are relatively more cautious with regard to estimating and committing to deliverables, as they are aware of the issues that typically emerge in their environment.
These two conflicting approaches on the project leads to miscommunication, as illustrated in Exhibit 4. This leads to missed deliverables, incorrect status reporting, and personnel conflicts.
The stakeholders realized early on in the project, that “Declining project morale” was a significant risk and they had to address this issue. The risk mitigation strategy they adopted was to collocate the team. Even though there were issues with “collocation”, as it disturbed the social structure and the work patterns of enterprise team members, the stakeholders adopted this approach.
As part of the Communication Management Practices, the project status reports and project meetings were being held on a regular basis. However, the information exchange across the groups wasn't happening at the level required for project success. Specifically, members of the various groups were providing updates, but were using their own colloquialisms, which were not helping the information exchange across the groups. As a result the early warning signs of “Declining project morale” were identified.
To address the declining project morale risk, the “Team Development” tools and techniques recommended by PMBOK® were adopted. The option chosen was to apply “Training” as a team development tool. Formal cross team training was introduced to improve the communication channels between the dependent groups. The training provided a platform for the team members to educate the entire project team and put them in a position of power. As illustrated in Exhibit 5, it also helped break the barriers between the different schools of thoughts, since the training was conducted in the form of off-site team building sessions. This enabled the team members to engage in more healthy informal information exchanges, thereby providing more meaningful status reports and more quickly achieving issue resolution.
We have in the above sections walked through real life examples of eCommerce projects and the tools and techniques from PMBOK® that were adopted to resolve the issues as encountered by the project team. The project manager need to recognize the early warning signs of the risk, prior to that risk occurring and address every risk event based on its impact. Mapping the requirements to “Business Needs” within the “Project Charter” in the context of “Identified risks” provides a powerful tool for appropriate risk resolution. The Scope management section thus provided a framework for not only addressing the risk but also to identify their occurrence early on. The Time Management section illustrated the importance of establishing precedence in “triple constraint” and utilizing that to guide the project decisions. Human resource management addressed the key aspects of difference in approaches and illustrated some of the ways to address them.
In varying degrees of emphasis, this project followed PMBOK® processes. Even though the project did not have strict process enforcement, key tools and techniques were leveraged by the team to effectively foresee risks and achieve satisfactory outcome for all stakeholders while fulfilling the demands of the project charter. We believe judicious application of processes with proper consideration to the business domain will ensure project success. By highlighting the PMBOK® processes applied during the project we have provided the audience with a leverageable framework for similar projects.
Project management Institute. (2000) A guide to the project management body of knowledge. Newtown Square, PA:PMI
Copyright © 2003 Syncata and PMI