Package Evaluation, Selection & Implementation Definition
The projects associated with the establishment of a package solution all exhibit a similar structure. Although the efficiency of the project execution may vary, or the definition of the various phases and their deliverables may be vague, or addressed somewhere else as a sub-phase, it is fair to assume the following phases:
Package Evaluation
The compilation of a roster of potential software packages exhibiting functionality analogous to the required specifications is typically acquired through a thorough examination of the competitive landscape and, in some instances, through direct Request for Proposal (RFP) interactions. The RFP typically encompasses a cursory overview of the company profile and the requisite functionality. Ideally, a comprehensive business analysis should precede the specification of package requirements.
The actual evaluation focuses on the appropriateness of the package as a solution, rather than the entirety of the offerings associated with the package, such as stability, vendor offerings, product trajectory, etc. Mapping the package's functionality, procedures, and data-definition (semantics) generally suffices at this stage, resulting in a concise list of potential packages. This process, commonly referred to as gap analysis, identifies areas or issues that require attention if the business aims for a comprehensive solution. The shortlisted packages have demonstrated their suitability as application solutions. However, no research or attention has been dedicated to their appropriateness as total business solutions; in other words, the packages on the shortlist appear suitable only in isolation.
Package Selection
From the narrowed-down selection, each candidate package must now undergo evaluation within the broader context of the overall vendor offering. Commonly applied criteria include support assurances, vendor reliability, product trajectory, upgrade procedures, and similar factors. The objective is to identify the package that demonstrates superior performance in these assessments, which is then chosen for negotiation and eventual purchase.
Despite its crucial significance, the determination of the severity of the package gap is often overlooked. For example, a seemingly simple interface gap with a legacy investment could result in substantial development costs if the necessary technology to bridge the gap is not readily available in the market. In accordance with the adage that a chain is only as strong as its weakest link, it is imperative to thoroughly qualify and assess the package gaps.
Package Implementation
This process typically unfolds within a project framework, wherein the project is traditionally delineated by the implementation team, leading to a substantial relinquishment of control by the business. The conventional introduction of project management elements predominantly steers the deployment of package functionality and modules in a manner most convenient for the implementers. The criticality of selected functionalities is seldom given due consideration and is typically deployed based on the architectural inter-dependency of the package.
The project unfolds through various phases, including conceptual designs, detailed designs, prototyping, acceptance testing, and production. In projects of this nature, the responsibility for design often rests with the implementation team, which tends to set aside business specifications after the implementation phase.
Objectives, milestones, and measurement criteria are formulated from a resource management standpoint rather than a business support perspective.
User Training
The system has been successfully implemented, and users are now required to attain proficiency in both the use and maintenance of the package. The vendors are optimally equipped to conduct user training, as they possess comprehensive product knowledge and expertise in addressing training needs. Users are scheduled for training sessions focused exclusively on the package.
It is advisable to incorporate the business-specific requirements of users into the training programme. This approach aligns with the ideal scenario where users not only learn about the package but also understand its relevance to the broader business context. The associated benefits of such integrated training justify the investment made, fostering business awareness, enhancing comprehension of the impact of user actions, and positioning the package as a supportive tool within the business context, thereby mitigating individual risks.
While the provided framework offers a minimal definition, it serves as a solid foundation for outlining an enhanced approach, addressing some of the previously mentioned issues. The framework definition also encompasses aspects related to integration within the system.
Package Project Risks, Pitfalls & Considerations
Continuity
The process encompasses discrete stages involving requirements analysis, package evaluation, selection, implementation, training, and maintenance. Notably, the conventional practice does not consistently involve a preceding evaluation before selection, and implementation design may not invariably precede the actual implementation. Consequently, deliverables from a specific phase do not always serve as inputs for the subsequent phase, potentially leading to duplications in analysis and research across phases.
Ideally, any specification, deliverable, or work document generated in one phase should be universally applicable and usable across all phases. The lack of continuity is a significant factor contributing to the loss of specification, a dearth of reuse, and oversight in implementation design, all of which carry undesirable financial implications.
In summary, for a comprehensive understanding of the distribution packaging process, it is imperative that the depiction created by an analyst is consistently employed by evaluators, selectors, designers, implementers, trainers, and support staff. Achieving this continuity is pivotal and often absent in most approaches.
Maintenance Costs
The issue stems from the complexity of the package, necessitating a heightened emphasis on investment in analysis and design. Consider the following scenario: The success of the sales event within a system is intricately tied to the architectural definition of products, co-products, and product qualities, which, in turn, relies upon the precise definition of quality types. Now, envision a scenario where, upon the completion of the package implementation, the quality officer discovers an error in the perceived definition of quality types. Unsurprisingly, the most dreaded phrase in any package implementation emerges: 'I have been thinking.' Due to the oversight in the analysis phase, revisions must be made to the definition of product qualities, pricing procedures, and potentially even products. This exerts a profound impact on both project costs and team morale.
The underlying reality is that a meticulous analysis is imperative before contemplating the adoption of any package solution. Consequently, there is an initial increase in expenditure, in contrast to ongoing maintenance costs. However, this front-loaded investment ultimately leads to a substantial reduction in the total costs incurred by the project.
Graphically, the scenario can be depicted as:
Compromise in terms of Strategic Differentiation
Arguably, the primary objection to package solutions lies in the challenge of strategic differentiation. In an application architecture characterised by a high degree of integration, ensuring that the selected package accommodates the distinctive factors that set one apart from competitors, who may also adopt the same package, poses a formidable dilemma.
There exists no universally effective solution; however, potential strategies encompass:
1. Extending Scope Beyond Package Limitations: Identify differentiators beyond the package's purview and develop the necessary application support independently.
2. Utilising the Package as a Framework: Implement the package in a manner akin to a warehouse, allowing strategic applications to be deployed as an architectural layer atop the package in relevant areas.
3. Customisation Investment: If the package's architecture permits, consider investing in the customisation of the package to align it with specific strategic objectives.
The crux of the matter lies in the imperative consideration of strategic differentiators during the implementation design phase. Overlooking this crucial aspect may inadvertently compromise the distinct competitive advantage one seeks to maintain, with the package potentially becoming a hindrance rather than an enabler.
Lack of Corporate - Wide Integration
The absence of corporate integration, an absence of an enterprise blueprint, a lack of architectural structure, and the absence of seamless integration mechanisms all stem from a common underlying issue. Whenever there are multiple applications within the application layer, it is imperative to ensure seamless integration by deploying these applications on a shared architectural foundation. Unfortunately, this is rarely the case in the current packaging scenario. Deployment tends to rely on the existing environment definition, encompassing factors such as hardware, platforms, and database architectures.
This practice often leads to either the rejection of packaged solutions or the introduction of an additional layer at the environmental level to guarantee transparency (incidentally, a primary argument in favor of warehousing). Corporate architecture emerges as an essential prerequisite for effective packaged solutions.
This concept is further illustrated by means of graphical depiction:
Premature Package Decisions
Decisions regarding package selection should be deferred until a thorough and comprehensive assessment of suitability has been conducted. It is imperative to recognize that opting for an inappropriate solution not only yields minimal business benefits but also provides a diminished return on investment.
Regrettably, the reality is that the evaluation of packages incurs significant costs. To elucidate the situation further, the following points merit consideration:
1. A lack of meticulous evaluation increases the likelihood of an erroneous package decision.
2. Unnecessary expenditures during the evaluation phase may surpass the requirements of the desired solution.
3. The diverse array of industry types and package offerings complicates the identification of a clear point at which package evaluation achieves its objectives.
To mitigate the risk of overspending on evaluation without prematurely reaching conclusions, it is imperative to accurately define our criteria. The primary goal in establishing criteria is to efficiently disqualify package offerings, ensuring a swift and credible process.
Legacy Exposure
What is legacy? In a real-world definition it is those systems or applications that are reason for comments like,
“Well, it is there - we have to protect our investment”
“Yes, I know there are more viable solutions available, but unfortunately, it is still a business critical
system.”
“If only we can we find an easy way to go live quicker on a more trendy solution, we can get rid of the
white elephant.”
Package Inertia
The challenges at hand revolve around two pivotal factors:
(i) the imperative for a strategic shift in business operations, and
(ii) the capacity to effectuate this change seamlessly within the framework of the selected package. Noteworthy packages of considerable scale, such as SAP, JDEdwards, or Triton, typically undergo an implementation phase lasting 6 to 8 months, excluding data migration from the existing to the target application. The complexity further intensifies when a local retailer embarks on international expansion.
In the context of venturing into international markets, meticulous consideration must be given to aspects such as multi-currency financial transaction support, shipping logistics, and the assimilation of market knowledge bases within the scope of the package change. In scenarios where the timeframe is constrained—such as the necessity to initiate international marketing within a month to secure a critical market share—the ideal scenario involves effecting the package change within the same timeframe.
While it is commendable to assert the flexibility of a package during implementation, the crucial question arises: is the package genuinely adaptable post-implementation? Drawing an analogy, in nations that attain freedom of speech, there often arises a paradoxical situation where freedom diminishes after the expression of speech. Similarly, package customizability confers flexibility during implementation but does not necessarily ensure adaptability post-implementation.
The adaptability of the package seldom emerges as a primary design objective, contributing to a notable inertia factor in effecting changes after implementation.
Unrealistic Project Estimates
Estimations are inherently approximate, and project definitions often have a propensity to subtly obscure the intricacies inherent in the task at hand. A potential remedy lies in cultivating a more profound comprehension of the exercise. Similar arguments, which underscore the pitfalls associated with high maintenance costs, are pertinent in this context as well. Inadequate emphasis is placed on the thorough analysis and design of the business and implementation processes.
Misaligned Package Solutions
Clearly articulated, the execution of the implementation must be harmonized with the strategic positioning of the business. In practice, the definition of business specifications and ensuing package requirements should be articulated at the optimal level within the framework of the company's strategic positioning. This consideration extends beyond the purview of the package implementation team, serving as a commentary on the contextual aspects of package projects.
Failure to ascertain alignment poses the risk of diminishing the long-term benefits of the package solution for the business. Consequently, the immediate advantages derived from contemporary package solutions may erode over time.
Categorically affirmed, the singular remedy to ensure alignment is to conduct the project within the ambit of rigorous business engineering exercises, encompassing strategic positioning, business strategic alignment, and the establishment of corporate-wide architecture.
Lack of Package Understanding & Stakeholder Commitment
The identified challenges pertain to change management and organizational behavior within the context of package projects. Securing buy-in from stakeholders emerges as a pivotal determinant of success for any package project, given that stakeholders not only define package requirements but also serve as end-users of the proposed solution. It is imperative to cultivate a comprehensive awareness of the package's role, benefits, and positioning within the business. Failure to achieve this understanding may result in various undesirable project characteristics, including:
1. Incompleteness and inaccuracies in the package specification.
2. Insufficiently grounded criteria sets, lacking substantial foundations for effective decision-making.
3. Resistance to assist in the implementation phase.
4. Hesitancy to engage in training and participate in the utilization of the solution.
The focal points for addressing these challenges lie in:
1. Proactively positioning the package as a comprehensive solution from the outset.
2. Ensuring executive commitment to the project.
3. Establishing a dedicated Change Management framework.
By emphasizing these aspects, we aim to enhance project outcomes, mitigate risks associated with incomplete understanding or resistance, and foster a more streamlined and successful implementation of the package within the organizational context.