In addition to upgrades and enhancements to their flagship ERP solutions, for a variety of reasons companies may also turn to specialty software companies for solutions to business problems. The rationale for using specialty software products can vary from filling gaps in their solution portfolio, gaining a competitive edge or responding to an outside factor such as new regulation.
Although these specialty software solutions are smaller in size and scope, they do require a relative measure of project management consideration. Many times I have seen dismissive or optimistic project managers assume that because a solution is smaller in size and scope, one can take a very relaxed approach to the implementation life cycle. In fact, greater care than what is found on ERP implementations needs to be emphasized in certain areas of the project.
Specialty software companies are hotbeds of innovation for emerging technologies, applications and interfaces. They bring to market solutions that can play a key role in creating a competitive edge or other differentiation for their customers. Compared to ERP solution companies, specialty software companies are smaller and typically less mature in certain areas. While this environment can make for innovation and agility, it can also create an expectation gap when comparing other specialty software functions against ERP solution companies. As mentioned before, one of the greatest mistakes a project manager can make would be to have the same level of expectations that one would have with an ERP solution company. In addition, it is just as equally dangerous based on their relative size to rationalize the project management to a minimum; treat the specialty software company as if it is “shrink-wrap” software, a “black box” integration or external database.
Below follows some project management considerations that have worked well when leading specialty solution projects:
Early Engagement Of Leadership — As with ERP solution projects, it is equally important to map all of your stakeholders, including those from software companies. What changes with specialty software company stakeholders is that the organizational level of interaction becomes much higher. While it is unlikely that you will ever meet the CEO of an ERP solution company when leading an upgrade project, it is very likely that you will meet the CEO of a specialty software solution company, especially if you may turn out to be their largest customer. Early on in the project be sure to create a mutual leadership “gear-mesh” whereby your CIO is connected with their CEO, Project Director connected with the head of their Product Development team, etc.
Mutual Success Criteria — As part of building the mutual leadership “gear-mesh,” a key deliverable will be the creation of mutual success criteria. Before purchasing the first software product license, it is very important for both the customer and specialty software company to make visible what they stand to gain with the implementation. In addition, this understanding of mutual success criteria also helps to shape the commercial agreement between the two companies. An example of mutual success criteria appears below:
Acceptance Criteria — From the definition of mutual success criteria, the next key step is to define how the specialty software product is accepted. With ERP solution companies, it is important to define the functional performance, physical performance and support performance criteria crisply. This has the double benefit of not only ensuring the customer gets what they need but also makes very clear what the specialty software company needs to achieve on the path to success. This step is also critically important if you are to be the largest customer of the specialty software company.
Customizations — As with ERP solution companies, specialty software companies build products for markets, not specific customers. It is tempting to pursue a path of deep product customization as the specialty software company may be willing to do anything to service a new customer. In addition, the customer may perceive that the specialty software company will be more agile and able to deliver a product tailored for a specific customer. As with any type of customization, the project manager needs to be realistic as to what level of customization the specialty software company can realistically deliver.
Product/Solution Resources — ERP solution companies have a lot of resource depth built up over the years for their products. In addition, they have structured training programs for their employees as well as customers. However, that may not be the case with the specialty software company as it may be that only a few people know the inner workings of the product and/or have implementation experience. In addition, a project manager may assume that the same level of resource depth occurs as with ERP solution companies. The project manager must recognize these differences and act accordingly by employing such methods such as asking for and interviewing named resources to be committed to the project.
Testing — As mentioned before, all software companies build products for markets. When it comes to testing, even greater care must be exercised from a project management perspective to ensure success. If you turn out to be the largest customer of the specialty software company, it is unlikely that the specialty software company has the testing cases and performance testing environment needed to support your implementation. As a project manager, promote open discussion and examination to determine the level of rigor of testing capacity in place as well as the path to close the gap required for success. Conduct this effort very early in the project to allow enough lead time for the specialty software company to build the necessary capacity for the upcoming testing phases. In addition, make the specialty software company a key stakeholder when it comes to the definition of the system, performance and integration testing phases.
Estimating — ERP solution companies have a long track record of implementations that builds a credible history of assumptions and risks for estimating your project. However, that may not be the case for the specialty software company that might have a limited number of implementations of your size and scope. As a project manages, you should adopt the same top-down and bottom-up estimation for specialty software companies as you would on larger projects with ERP solution companies. In addition, take into consideration that while a specialty software company may be very agile and innovative from a product perspective, that may not be true of delivering releases, customizations or post-implementation support processes. Take the same level of attention as well as reasonable expectations for both base effort estimates as well as lead/lag times with deliverables.
In summary, it’s very tempting to size both the amount of project management effort and skills relative to the size of the specialty software company. This has a number of inherent dangers given some of the delicacies that apply to specialty software company considerations beyond the power of their innovative products. It is wise to apply the same ERP solution expectations, doctrine and methods with specialty software companies to avoid future pain when it comes to testing, implementation and adoption of these solutions.