Key Concepts
Build on a flexible and extensible software platform
Deliver the first sites quickly
Prepare for the unexpected
Monitor the project
We have seen that the creation of a shared platform used for all commerce sites of a large company is a monumental task. There are numerous things that can go wrong during the lifetime of the project. Here is an example.
Example of Project Failure Due to Unforeseen Requirements
One Canadian company, when building its commerce platform, ran into problems half a year into the development cycle. At that time, the lines of business managers from the company’s call center and customer support departments finally started looking at the platform under development, and they found several issues that had never been raised when initial requirements were gathered.
The biggest issue was that they did not like the user interface of the administrative screens that would be used by sales and customer service representatives. In their opinion, these employees would have to spend too much time on each customer and on each order. The lines of business raised their issue with the executive sponsoring the project, and a request was made to redesign some of the screens to better suit the needs of the lines of business.
Naturally, so late in the cycle, a change like this would cause the project to be delayed by 3 to 6 months, which meant that the new commerce platform would not be ready in time for the winter holiday season. In the world of retail, a delay like this is serious—expenses and revenues are booked for each year, and moving the deployment of the new site into the next year would mean reopening the company’s plans.
Unable to pacify the lines of business, the executives simply canceled the project and wrote off all the expenses associated with it.
What we see in this example is that executive patience can be thin in the face of problems that affect profit or loss. At the same time, it seems silly that the company came within a few months of getting the commerce platform that they had wanted for years, only to cancel it because of short-term expediency.
The lesson to be learned is that the project team must anticipate unexpected problems so that they can deal with them, even if they are perceived to be serious. If the problems are not dealt with effectively, their accumulation can cause the cancellation of the entire project. This can happen even if in reality the project team feels that the issues are not so serious that they cannot be remedied with a reasonably small expenditure of time and money. Perceptions matter, and when the company executives have a perception that the project is mired in problems, they will start looking for other ways to achieve their business goals.
Let’s now list a few of the possible mishaps that can happen on the way to a successful deployment of a commerce platform, summarize possible causes of the issues, and suggest ways to prevent or address them.
Reorganizations can shake up the foundation of a company. Such reorganizations can happen for any number of reasons, such as cost cutting, company expansion, acquisitions, or sale or spinning off of divisions. In other cases, new executives might take over, for whom a new common commerce platform is not a high priority, and who question the need for the entire project. With reorganizations, lines of business might be merged, eliminated, or transformed to the point where the business priorities are unrecognizable.
For a shared commerce platform, reorganizations can create several different obstacles. One possibility is that the line of business that was going to be the first user of the new platform might be spun off or merged with another larger division that is not nearly as interested in the new platform. Another situation can be that even if the lines of business are still fundamentally interested in the concept of a shared commerce platform, their immediate focus has shifted from this platform to other matters.
Example of a Company Reorganization Affecting Commerce Platform Development
A U.S.-based equipment manufacturer was well on its way to developing a commerce platform when it merged with a European-based company. The new European parent company management quickly decided that the U.S.-based IT department would be best positioned to take care of the company’s commerce needs. However, even though the IT group survived the merger largely intact, it took years to sort out the responsibilities within the joint company, and then even longer to understand the overall business and its requirements. Therefore, the commerce project ended up on hold for several years, and all the initial work done before the merger was largely discarded, being out of date and with no staff left to support it.
Reorganizations cannot be foreseen or avoided in the life of a corporation. Achieving rapid results and the ability to measure success in the short term are the best insurances of a commerce project in the face of unexpected corporate reorganizations. After the first few sites are deployed and are relying on the new platform, chances are better that the new platform will continue to be used for subsequent sites, no matter what the impact of the reorganization is. This is, of course, only true if the success of the new platform can be demonstrated based on the business and technical performance of the first several sites.
The project plan must ensure that the first deployment of a site on the new platform occurs reasonably soon after development starts. Ideally, the first deployment should take place within 1 year. On the other hand, if the first deployment is planned after 2 years, chances are high that the company might look so different at that time that the new platform’s usefulness might be questioned, even if development is successful.
A company that is developing its commerce platform typically must deal with a multitude of various vendors. To build the platform, the company needs to acquire software that serves as the basis for the development effort and the hardware that the platform operates on. There might also be a need to hire consultants and implementers who can customize the software to the company’s needs, install it, and set up the company’s data. Another external vendor might provide the service to host the commerce platform, and in some cases even to outsource some of the operations.
If the development effort runs into difficulties, the root of the problem might lie with either the software purchased from an external vendor or with the services that are provided. For example, perhaps one of the software packages has too many defects or perhaps does not have sufficient functionality and is inappropriate for the company’s needs
Another possibility is that the problem lies with consultants that implement the platform because they did not properly understand the company’s requirements, or they implemented requirements that are not important, causing endless delays.
Example of a Vendor Problem
A company faced multiple delays in developing their commerce platform, to the point that the delivery date had already been moved twice. The main symptom was that new requirements kept coming in from the lines of business, and for each requirement, the platform’s cost would increase and the scheduled would be delayed.
The company considered the situation carefully and decided that there could be two possible explanations:
- The chosen application software was not appropriate for the project, and the requirements were too difficult to implement.
- The consultants were not doing a good enough job implementing the project. Rather than simply accepting each requirement, they should also provide their own input on whether it is possible to avoid it through adjusting business processes, or perhaps implement it in a cheaper and more creative way.
If (1) was the problem, to correct it the company would have to start searching for a new software vendor. This would also mean that the entire project would likely need to start from the beginning, losing more than a year of development time.
If (2) was the problem, to correct it the company would need to find new consultants and transfer the work to them. The transition to a new development team would likely cause some delay, but most of the work done up to date would be reused, and the overall design would be preserved.
After analyzing the situation, the company decided to fire the consultants but to keep the software vendor. They hired a new consulting firm that had more experience with the particular software package and also had more experience with large commerce sites. With the new consultants, the project was successful, and the new multisite commerce platform was launched, in spite of previous delays.
This example shows how identifying vendor problems is a difficult task and presents a complex dilemma. Clearly when the project is well under way, option (2) is the preferred option. It is certainly easier to hire a new consultant or new staff than to go back to square one looking for a new software vendor.
At the same time, one has to be careful that with the new consultants, the project does have a chance at succeeding. If the software is inappropriate to the company’s needs, hiring new consultants will only make matters worse because the company will end up wasting more time and money on a project doomed to eventually fail.
You need to ensure that the selected software vendor is the right one and does not need to be replaced further down the road. The company must invest all the necessary time and resource in selecting the software vendors because this initial decision is so critical to the project’s success.
Not only the functionality and quality of the software needs to be looked at, but also the relationship that can be established with the vendor. If any issues arise, the software maker needs to be consulted to resolve them in a speedy manner. Part of the process of vendor selection is to make sure that the vendor is capable of, and has a reputation for, providing good service and rapid problem resolution. In some cases, the vendor must even agree to incorporate some new features into their product, which are necessary for the company, and are deemed to be useful for the product’s other customers.
The relationship with the vendor is critical to the success of the project. Project management must monitor this relationship carefully and raise an alarm if it is felt that the relationship is not working. For example, if the vendor is unresponsive to questions or unwilling to provide fixes, project management should raise an alarm. Similarly, management should be concerned if it is felt that the software is unreliable with too many defects, or that working with the software is too expensive and too complicated, with too many unreasonable limitations that impede the ability to implement key requirements.
Such concerns are serious, and in the most extreme cases could be a sufficient reason to interrupt the project and restart it by looking for a new software vendor. However, before taking such a drastic step, the management must carefully examine why the software was selected in the first place; that is, what caused the error in judgment? The purpose is not necessarily to lay blame for failure but to ensure that next time around, the same error is not repeated.
Example of Problematic Vendor Selection Process
One company tried to rebuild its commerce platform no less than three times. On the fourth try, it ran into a familiar set of difficulties and complaints that requirements from lines of business were not implemented. Eventually, it canceled this latest attempt and the company was set back by at least another year in its quest for a new commerce system.
In such a situation, you should be suspicious of the health of the company’s decision making. If the company repeatedly fires its vendors, perhaps is selection process is flawed. Canceling a project is a drastic step and should not be taken lightly. In some cases, even if it is felt that the vendor’s software or services are imperfect, the best decision is to proceed anyway, provided that there is a clear plan to achieve success, even with some delays or cost overruns.
A critical impediment to the success of the project can be related to the people that develop the shared commerce platform. Technical leaders and project managers must monitor and be aware of the capabilities of the personnel involved in developing the commerce platform. In some cases, project delay is not due to defects in software but is simply a result of poorly trained or inappropriate personnel.
Example of a Personnel Competence Issue
One company was developing call center software and found the project hopelessly behind schedule. The project managers were trying to rebuild the plan to include additional time, but they were also wary that it was not clear what had caused the delay in the first place and were not sure how much extra time was needed.
The project was developed in multiple locations, and the team of developers responsible for the user interface was remote from the main core of developers dealing with the larger system.
Eventually the management decided that this remote team had little chance to succeed no matter what delay was added to the schedule. Although the developers all had good resumes as programmers and designers in general, none of them had any experience with the company’s commerce software, and also most of them had never worked on a large scale system.
Therefore, the decision was taken to disband the remote group and to transfer the work to other locations in the company. After studying the situation, the new designers assigned to the work recommended that much of the original design needed to be abandoned, and hence the project would experience a delay of one year.
The management decided to proceed with this proposal, and with the new implementation team, the project successfully completed in accordance with the revised schedule.
Such personnel decisions are extremely difficult to make, and they can be both costly and dangerous. The most difficult part is to notice the issue before it causes unavoidable delays in the project schedule.
One technique to help detect personnel issues early is through good project management. The development plan must include sufficient checkpoints, both for each person participating in the project and for each team. Project managers must then track the plan closely and take note of any slippages that occur, particularly if the same person or the same team consistently fails to deliver their commitments on time.
However, project management alone is not sufficient to notice personnel incompetence. In a highly technical project, individual employees and even team leaders and development managers can become creative in giving what seems like reasonable explanations for their delays. After all, nobody wants to carry blame for failure, and it is natural for people to try to find ways to avoid being the focus of the “blame game.” For example, programmers could suggest that the real reason for delay is incomplete requirements coming from lines of business, or that they need better development software to work with. In the worst cases, a programmer or even a team might claim to have met the deadline, even though what was actually delivered does not work or has not been properly tested.
Therefore, project management needs to evaluate the quality of the deliverables to see whether the claimed progress is real or fabricated. Project management must also judge any suggested reasons for delays and have the ability to come to its own conclusions as to how reasonable the rate of progress is.
Such insight into the development effort by project management is not easy to achieve. Even though project managers do have a high level understanding of what is being done, fundamentally the discipline of project management does not involve deep technical skills. Most often, project managers are not familiar with technical details of design and have no skills to understand the quality of delivered software.
Therefore, management must rely on the strong opinions and advice of the technical leaders that are charged with overseeing the project. The key architects and team leaders are key to uncovering issues with the competence of the development personnel. These people have a responsibility to not only prepare the overall architecture and design, but also to give advice to the implementers, and to review the detailed designs and implementation with each development team.
It is in these technical interactions, namely design discussions, and design and code reviews, where the team leaders can truly appreciate the competence of their developers. Similarly, it is within the design discussions and design reviews where the architects can judge the competence of the teams that are charged with the task of implementing the project.
The evaluation of personnel competence cannot be treated as something that happens by itself, but rather it should be done systematically over the course of the project. Certainly this process must be done discreetly; ideally it should be done in one-on-one sessions. For example, the chief architect of the project should schedule time to interview the key leaders and to get their input, in addition to gathering his own impressions. Similarly, the senior project manager should conduct such one-on-one interviews with the architects and the senior team leaders to gain an appreciation of how well the project is proceeding in their view.
If such assessments as to the competence of the team are done both during the design and implementation phases of the project, the likelihood of incompetence being unnoticed will be significantly reduced. If problems are discovered, they can be corrected in a timely manner, using such well-known techniques as establishing mentorship relationships, additional training, reassignment of work, or even by replacing some of the personnel.
We have already discussed how a company must collect the requirements for the commerce platform and the sites that are to be deployed on it. However, even with the best efforts by the business managers, analysts, and technical designers, it is common that requirements do change unexpectedly. If not anticipated and planned for, these changes can cause serious delays and cost overruns with the project.
There are two classes of reasons why requirements tend to change during the project’s lifetime:
- Unforeseen requirements
- Requirement changes
It is necessary to prepare for each of these types of requirement changes and to take measures at the outset of the project to ensure that any additional work, or rework, is minimized.
Even with the most comprehensive requirements gathering effort, some important requirements might be missed. This could be because the corresponding line of business did not pay enough attention to the project of developing a new commerce platform during the early stages of development. Another possibility is that the company has been reorganized, or perhaps the business situation has changed and a new requirement has emerged due to the new business reality. Finally, this could simply be a mistake by the business analysts who omitted or forgot to detail important requirements.
Avoiding such surprises is not always possible. For example, if the new requirement has to do with supporting a new line of products that are introduced while the project is developed, it is unlikely that it was possible to fully predict the requirements during the early stages of the project, many months earlier.
Similarly, omissions on behalf of the business analysts who are tasked with gathering requirements is something that is hard to discover. It is generally much easier to find mistakes in what has been written down than to find what is missing in the first place. Therefore, such omissions do take place, and the project must be prepared to handle them.
To minimize the impact of unforeseen new requirements, there are several strategies to follow:
- Anticipate new requirements wherever possible.
- Design the new platform in a flexible manner so that new requirements are not hard to accommodate.
- Plan for new requirements by building a buffer into project schedule.
Anticipation of new requirements means that the business analysts must not only look at the business in its current state, but also understand where the business is going in the next 3 to 5 years. They must ask questions such as what kinds of new products is the business looking to introduce? Is there a desire to conduct new kinds of marketing campaigns that are impossible today? Are there plans or at least a desire to expand to new market segments or to new geographies? Are there new business rules that should be anticipated because of changes in the legal environment, such new privacy rules or new payment rules?
The requirements must be classified into current requirements and anticipated possible requirements. The anticipated requirements must be presented to the designers of the project so that they can plan for them.
With a good design, it might be possible to add some minimal infrastructure with little cost so that if the anticipated requirement does materialize, implementing it does not require major surgery to the project but is a well-understood and reasonably contained effort.
A requirement change can occur if originally the business analysts misunderstood the requirement or described it in an incorrect manner. In some cases, changes can happen if the business transforms during the course of the project; for example, if payment processing needs to be done in a new way because of new credit card rules, or because the company started using a new payment processor.
Another situation that is similar to requirement change is technical errors by implementers of the project. The project designers and developers might misunderstand the requirement and implement it in a way that does not fit the business needs. In this case, the implementation must be changed, and the resultant effort is similar to a requirement change.
To minimize the impact of requirement changes, ensure that the new commerce platform is based on flexible and proven software that has been successfully used in many different business situations. Such a track record is evidence that the software is flexible enough to accommodate changing business needs and can fulfill requirements in different ways.
To avoid misunderstandings of requirements, or at least to detect such problems early on, the most important technique is to conduct detailed requirements reviews at several stages in the project lifecycle. The first stage is before development starts, where each line of business must review the requirements relevant to them and to sign off that they are satisfied with what is being built.
Conduct a second review after the platform is designed to make sure that what is being built corresponds to the business needs. One technique is to review the business processes for each role involved in operating the site. This review must necessarily involve many different parties: the technical architects who understand the workings of the technology behind the new commerce sites; the line of business managers who understand their tasks and their business processes; and project managers who manage the development of the commerce platform.
This second review provides a forum where the business managers begin to understand in detail the capabilites and can determine whether anything is lacking in the new platform. Similarly, the technical designers can appreciate the challenges of the business and the finer points of the requirements. The result of the review is a list of changes that are deemed necessary—that is, corrections to the original requirements based on new understanding from both the business and technical communities. This process allows the necessary changes to be discovered early enough in the development cycle so that they can be accommodated with minimal impact on the plan.
We have enumerated a number of common situations that lead to delays or cancellation of the development of a new commerce platform. These reasons can all be serious, and there are specific techniques to deal with each kind of a situation.
Table 13.1 shows the major reasons for unexpected delays, and a few possible ways to prepare for or deal with the issues.
Perhaps both the most obvious and the least obvious advice is to not give up too easily. Even in the face of mounting delays or political obstacles, canceling the project is a last resort. If successful, a common commerce platform can bring enormous benefits to a company, both reducing the costs of multiple sites and increasing the ability to manage the sites. These benefits must always be kept in mind, even if difficulties arise. If problems arise, management must consider the magnitude and seriousness of difficulties against the huge benefits of a shared commerce platform.