Forgot password?
|
|
|
|
We were unable to sign you in.
Please verify your user name and password and try again. If you do not have a TEC account, register now.


If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"Access Commerce is an international provider of Multichannel Selling and Configurator Software that simplify the sale of complex and configurable products and services."
Source: Access Commerce

Resources Related to Top Ten Risks to a Configuration Project and How to Avoid Them:

Top Ten Risks to a Configuration Project and How to Avoid Them

Project Team is also known as : Configurable Product, Product Models, Product Modeling, Modeling Effort, Risk Number, Product Configuration, Risk Number, Build-to-order Product, New Processes, Product Modeling Effort,
Configurable Product Models, Product Families Models, Project Management Software Configurable Product, Project Management Configurable Product, Project Management Process Configurable Product, Project Management Model Configurable Product, Enterprise Project Software Configurable Product, Project Management Processes Configurable Product, Project Management Online Configurable Product, Project Management Courses Configurable Product, Project Management Tools Free Configurable Product, Web Based Project Management Configurable Product, Free Project Software Configurable Product, Project Management Books Configurable Product, Project Management Course Configurable Product.

Contents


  • Preface
  • Introduction
  • Starting on the Right Track
  • Developing Effective Configurable Product Models
  • Staying on the Right Track
  • Conclusion
  • The Author
  • Notes and References
  • About Access Commerce ..

Preface

Companies producing and selling complex and configured products can achieve a major competitive edge by successfully implementing product configurator software as the core element of a configurability strategy - "to provide more product variations using less resources." (1)

Some companies, unfortunately, have painfully experienced the risks of implementing new software and processes, though eventually gaining benefits. Other companies may be overly cautious. They can be hesitant to undertake "another new initiative," even when it is essential to compete in today's demanding environment.

The promised benefits from implementing product configuration software are many and may seem too good to be true. However, companies that have successfully implemented a configuration project confirm its many rewards. Surveys by industry research firms further validate these claims. (2)

Purpose of this Executive Guide


The purpose of this Executive Guide is to help companies gain the intended benefits from implementing a configurability strategy, by: Identifying the top ten risks to a successful product configuration implementation project, and Describing numerous, proven actions to avoid or to mitigate them. Although this guide presents the indispensable actions to avoid these risks in a general sequence, a different sequence and/or emphasis may be appropriate for any individual company situation.

Introduction

Implementing new configuration software and processes is similar in several respects to implementing other information technology (IT) based projects, such as enterprise resource planning (ERP) or product lifecycle management (PLM) systems. A few of these similarities include the strategic nature of the project; its broad scope - encompassing the extended enterprise of customers and suppliers; the extensive cultural implications; and the necessity for formal change management methods.

Nevertheless, in developing a feasible plan to implement configuration software and processes, there are some significant differences to consider. For instance, ERP / PLM product definition capabilities are limited in their flexibility to create highly configurable product representations for use by customers to create unique products. This is because those systems focus on engineering and manufacturing versions of product structures. Typically, their current product structuring methods are grossly inadequate to meet sales and marketing requirements for unique and accurate configurations - developed in a timely and cost effective manner.

By creatively using configurator software, project teams now will have the capabilities and flexibility to define product options and variations in any way deemed necessary - for an effective customer-facing Lead-to-Order (LTO) process. (3) The implication is clear: To become more customer oriented by offering highly configurable products, a company will need to dramatically shift its perspective on how its products are defined and presented to the marketplace.

As with most IT-based system projects, to gain the considerable rewards may invite numerous risks. Thus, it takes prudent management to recognize these risks and to develop viable actions to avoid or to mitigate them - by learning from and taking advantage of the successful experience of others

The Spectrum of To Order Products

Pick-to-Order (PTO) - products usually shipped from stock inventory, for example, catalog items with optional accessories shipped with the catalog item.

Assemble-to-Order (ATO) - products with standard sets of predefined features and options, from which unique product configurations are developed by the customer selecting specific features and options, for example, computers ordered over the Internet.

Configure-to-Order (CTO) - products based on consultative dialogue with the customer, through Web interface, to address specific requirements. The products have been predesigned in computer-aided-design (CAD) models or parameterized documents, but not predefined with specific part numbers, for example, products with dimensional and spatial requirements, such as hydraulic actuators, and windows and doors.

Engineer-to-Order (ETO) the most complex products that during configuring must interface with product development activities and tools, such as CAD software, design rules and other expert IT systems that can support development of configuration, pricing, and complete documentation over a typically iterative proposal cycle; for example, electrical distribution systems.


Starting on the Right Track


Risk Number 1: Not Managing the Implementation as a Strategic Project

If the company does not address this risk directly in the first stages, the result could be complete project failure - after spending the implementation budget fruitlessly. Wide industry experience has clearly demonstrated that the most common cause of this risk is because the organization does not fully understand the strategic nature and value of the proposed configuration project.

Strategic, in this sense, means a project at the highest level of planning and execution, fully endorsed and supported by top management to catalyze major improvements in the company's competitive posture.

Action: Develop a solid business case with a Return on Investment (ROI) analysis to gain management's initial commitment; sustain it by quickly showing results and keeping management informed of ongoing progress and challenges.

A complete ROI analysis has proven essential to gain management commitment. It should identify tangible objectives and benefits, one-time implementation costs and all ongoing costs of IT support.

First, as planning assumptions for developing the benefits side of the ROI equation, the company's strategic vision may need to be defined or clarified; for instance, will the company:

  • Target new market sectors?
  • Initiate new sales channels and processes?

Some project teams might contend that intangible benefits alone offer sufficient justification to undertake a configuration project. For management, with an ROI focus, intangible benefits lack the power to sustain commitment over an extended period. For the users, however, the soft benefits can be a powerful motivator; for example, engineers may be very frustrated with the time consuming problems of developing one-time bills of material (BOMs) that dilute valuable engineering time for innovative product development. (2)

Once the project team gains management commitment, the attitude might be "thank heavens, we have management's support, now let's get on with the real job."

Nurturing and retaining management commitment is a real job and will be a continuing challenge. It must be a top priority of the project team to accomplish this by using formal project management techniques. These include: consistent status reporting, means to identify and resolve outstanding project issues, and a comprehensive communications approach. Project management software can only provide a partial solution.

In addition, the project team must seriously consider the value of an early success, such as a "rapid prototype," to sustain enthusiasm for achieving the project's intended benefits. In a similar vein, another viable approach is the tactic of "self funding" later stages of an implementation through the benefits gained from its initial successes.

Risk Number 2: Not Having the "Right" People on the Project

Without the "right" people on the project team, two major risks will almost certainly appear:

  • The configurable product model will not meet the requirements of all organizational functions, including customers and suppliers
  • The eventual users may not fully accept the newly developed configurable product models and the supporting processes

The critical question is, therefore, who are the "right" people?

Action: Recognize the required makeup of the project team: multi-disciplined with in-depth product knowledgeable people - and led by the business and not by IT personnel.

"Right" is . . . those product experts that are integral to the current day-to-day operations and who supposedly "cannot be spared." These people have the expertise and perspective to design product models that meet the needs of the enterprise. Clearly, providing personnel who "cannot be spared" depends on the strength of management's commitment to the configuration project.

Furthermore, project leadership should be in the hands of those responsible for the future, on-going operation of the system - the sales, marketing and/or engineering personnel.

To bring together and forge an effective project team, the qualifications and capabilities of the "right" prospective team members must be evaluated:

  • Will they be willing participants?
  • Will they be able to stay motivated in the face of occasional setbacks during the progress of the project?
  • Will they resist being distracted by their "real" jobs?
  • Can they function effectively at two different thought levels: conceptual and the detail of product modeling?
  • Can they make decisions to facilitate conflict resolution?

Action: Define the "right" tasks for the "right" people to accomplish the project's objectives.

The project team's prime responsibilities are to develop a feasible project budget and schedule, paying special attention to the product modeling effort; and to design, test and implement configurable product models and related processes that meet the company's strategic vision. Moreover, acting as proactive change agents and maintaining open, two-way communications with the rest of the organization are particularly important with respect to the cultural risks, described next.

Risk Number 3: Not Fully Understanding the Cultural Issues

Experienced companies frequently refer to cultural risks as one of the foremost reasons for project failures. Technical reasons have rarely been the cause.

The risks here are often subtle; like an iceberg. The obvious, formal policies and processes exist above the waterline. Beneath it may be the informal - attitudes, values, norms and fears - that endanger the project. For example, a company may have relied on a certain department and/or individual to know the subtleties of generating a customer's unique product configuration. Thus, these users may perceive a change in roles and responsibilities - using the new configurability processes - as a loss of status and power.

Action: Clearly identify the cultural issues that might endanger the project.

A fundamental truism here is that management commitment, by itself, does not solve cultural resistance to accepting new processes. Accordingly, the project team cannot be passive, hoping that time will cure the resistance risks, or that momentum will sweep along any dissenters. It will take a proactive approach by the project team to gain user acceptance of new processes and responsibilities.

In fact, the project team must relentlessly work to eliminate any potential organizational potholes and landmines that can undermine expected project benefits. Additional actions:

  • Maintain constant contact with all affected users through both formal communication means and informal methods
  • Conduct orientation and educational sessions, perhaps some conducted by outsiders who can bring fresh perspective to the effort
  • Hire a change management consultant versed and experienced in cultural issues and how to resolve them
  • Accept constructive conflict as a healthy situation and destructive conflict as unacceptable

Developing Effective Configurable Product Models


Risk Number 4: Not Completing a Valid Product Model and Process Design

An attitude of "let's get on with the solution, we all know the problems" can lead to undesirable risks in the early phases of the project. It is a natural posture: some project teams may be too eager to start playing with the new software before they initiate a purposeful design process. This is a dangerous attitude that could lead to false starts and costly project course corrections.

If the project team does not have a clear focus on project objectives, other risks can surface during the remaining phases of the project:

  • Incomplete model and process design
  • Rework of processes required later in the project
  • Heavy reliance on people's memory and tribal knowledge
  • Personnel turnover
  • Politics gain the upper hand resulting in individual or functional needs becoming more important than the overall enterprise needs

Action: Identify the strengths and weaknesses of the Current State methods and processes related to the configurability strategy; then develop the desired Future State.

Current State review
Selectivity is essential - too much documented detail is not necessary. The Current State of product variability, such as available options and combinations, however, does deserve a high degree of attention and detail. Understanding the current demographics will help to accurately estimate and to facilitate the product modeling effort, for instance, the number of features, the logic controlling the relationships, and the interoperability of options. Structured design methodologies that use visual aids are useful here. Moreover, the project team should recognize informal sources of product information, for example, Post-it notes and tribal knowledge.

Additionally, the company must avoid the myth of "We have to make our current systems work first." Time is too valuable to waste trying to improve poor systems on a piecemeal basis. Companies can avoid this risk by developing and following the strategic direction provided by a Future State design.

Future State design
The goal of this action is to create a comprehensive design for product models and processes. To accomplish this:

  • Identify the metrics of configurability success, for instance, the accuracy of configured quotes and orders
  • Define the affected processes at a general objectives and policies level only; procedural detail can come later
  • Clarify planning assumptions that influence or constrain the design to avoid the painful hindsight, "Oh, but I thought . . ."
  • Make use of a comprehensive design methodology to avoid missteps Draw on best practice checklists as prompters
  • Recognize factors that should be resolved before a Configurator can be fully used, for example, an effective product change management process
  • Share the evolving design continuously with management and users and solicit feedback before final approval

This last noted action is one of the best-known tactics to determine if the design is complete - not stopping short at the 80% completion state.

The overall design of the Future State processes and the user experience with them must be intuitive and perceived as a natural part of their interaction, not an added burden to be endured. In addition, there are critical considerations in developing valid product families and models, described in the next section.

Risk Number 5: Not Attaining the "Right" Perspective when Designing Product Families and Models

One of the key tasks awaiting the project team is to develop a fresh perspective on the definition of product families and models by taking advantage of the capabilities in the configurator software. Gaining perspective means to abstract or visualize new groupings of product families and models to achieve more effective configuring of complex, unique products. Often, though, Current State engineering and manufacturing product structures do not lend themselves to accurate and timely configuring of products in a revitalized LTO process.

Failing to address the concepts of the "right" perspective may result in unusable configurable product models and these undesirable consequences - at two levels:

  1. Operational unduly complex, time consuming and costly on-going model revision and maintenance, and
  2. Strategic eroding the customer's confidence, and even losing business, if the customers view the new product configuration and LTO process as unwieldy Unfortunately, there is no "magic bullet" to absolutely avoid the risks - do not waste time searching for it. At best, the company must strive to mitigate them during the tasks, described next.

Action: Plan and carry out a comprehensive design process and conduct periodic reviews with users and top management - so that the results conform to the company's strategic vision.

The goal is to achieve the "right" perspective in new product family definition - by balancing conflicting factors, including the usability of configurable product models versus flexibility and the cost of family and model maintenance. This goal also means that the following organizational functions must be wholehearted participants in the decision process: marketing and sales - to ensure usability of the configurable product models by customers in a revised LTO process; engineering - to signify what can be produced; and manufacturing - to indicate what is optimal to produce.

Typically, a project team will carry out a whole series of interrelated tasks to reach the goal of the "right" perspective. In a general sequence:

  1. Understand the strategic vision regarding target markets and customer characteristics. Developing answers to some questions may catalyze a fresh definition of product families. Among them:
    • What sector of the "To-Order" spectrum will the company tackle?
    • To what degree are customers sophisticated and knowledgeable about what they need in a customized product?
    • What will be most effective for customers using the configurator software: feature/option selection? - a needs analysis approach? - or combinations of both? - in a guided selling mode?
    • What are the customer's delivery expectations?
  2. Define and decide on the important factors in product family and model development, considering the customer level of product knowledge/expertise, product complexity and anticipated levels of maintenance; then set priorities and balance the trade-off decisions.
  3. Visualize and evaluate the possible new or revised product family groupings. The two extremes in product family definitions too few high-level product families or too many product families will both result in unnecessary maintenance time and cost.
  4. Do not let product configuration exceptions rule. This can distort the design effort and be time consuming.
  5. Recognize that there will be an inflection point (where the value is still increasing, but at a reduced rate); for example, increasing flexibility in future model maintenance is a desirable capability. On the other hand, too much flexibility will complicate maintenance.
  6. Review the evolving perspectives and recommended choices of proposed new product families with users and top management to gain approval before expending additional design effort and incurring costs.
  7. Create new product families; prototype one or two to test for customer usability and maintenance considerations.

The project team must accept the reality that attaining the "right" level of perspective for new product families and configuration processes is not a once through process; expect some iteration of some or all of the above actions. Certainly, anticipate some rousing debates during this phase.

Risk Number 6: Misestimating the Modeling Workload

Product modeling will be a major part of the project budget and schedule. When developing the project plan, there are two undesirable possibilities to be avoided: underestimating or overestimating the modeling effort. Either can trigger common risks - detrimental to project success:

  • Diluting management commitment due to loss of confidence in the project team
  • Deteriorating team member's commitment to the modeling effort
  • Transferring team members - who "cannot be spared" - off the project
  • Losing project momentum

Underestimating the product modeling effort and subsequently requesting additional budget and time from the executive steering committee will directly lead to the aforementioned risks. Be aware of potential root causes, such as not understanding the process, or the presence of highly motivated, but overly optimistic, team members.

Overestimating the product modeling effort also has additional downside. Management and users may react negatively to initial schedules that are perceived to take too much time before showing results. Here, root causes may include a lack of understanding, or poorly motivated, overly pessimistic team members who might be inclined to "pad" estimates for protection.

Action: Understand and evaluate the product complexity factors and the effort required to develop product models - on time and within budget limits.

Because only the project team - no others - will be accountable for the accuracy of the product modeling estimates, it is imperative they have the requisite understanding of product modeling before they commit to a schedule. There is no magic Excel spreadsheet to develop the estimates. Thus, it will be a highly judgmental exercise demanding a high degree of attention to both product complexity and team member capabilities.

Product Factors
In the Current State review phase, the project team will have identified a number of product variability factors. These are statistical and qualitative descriptors defining the complexity of the products - that are needed to develop an accurate modeling estimate.

A company's products may span the range of Assemble-to-Order (ATO), Configure-to- Order (CTO) and Engineering- to-Order (ETO). As a rule, the more complex the product, e.g., CTO and ETO, the greater the product modeling effort. Therefore, the following factors need to be carefully evaluated:

  • Where do the products fall in the range of ATO, CTO and ETO?
  • Number of product families?
  • Number of characteristics per product family as engines in automobile models?
  • Number of possible choices for each characteristic as engine horsepower selections?
  • Number of parts needed to make a unique product configuration?
  • What configuration relationships currently exist that will need to be accounted for in the new product models: complex pricing strategies, sub- level configurable BOMs, integration with CAD software, and rules for dimensional and parametric calculations?

People Factors
At this time, a key question is . . . do the project team members have the requisite understanding of the product modeling effort to develop accurate estimates?

Greater understanding of the future modeling effort should result from collaborating with the software vendor - with their experience - to leverage the project team's knowledge of the product. One distinct possibility is to co-develop a prototype product model with the software vendor. This approach also provides active software-specific training. However, the project team must retain the eventual, ongoing modeling responsibilities that should not be defaulted to the software vendor.

Now is also a good time to maintain active dialogue with experienced configurator implementers - in complex product companies with similar characteristics - to gain a better understanding of the scope and intensity of the product modeling effort

Furthermore, it may be necessary to initiate appropriate actions to improve the project team's effectiveness, by reconfirming the project objectives and rationale; regenerating motivation with fresh management direction; and reaffirming roles and responsibilities, such as the power to make decisions to resolve conflicts.

Risk Number 7: Not Selecting the Appropriate Product Family to Start Product Modeling

Most companies will have a choice of which product family to select for the initial product modeling effort. There are often two extremes to evaluate, simple or complex - each with attendant risks. Starting with a complex family that promises greater benefits may be tempting, because of the desire to gain the greatest immediate benefits with improved product configurability. Nevertheless, starting with a too complex product line may prove self-defeating. The project team may not have the experience level required for a successful outcome. An unfavorable, demoralizing result could cause a loss of confidence.

There is an advantage to consider in starting with a simple product line: it shows results quickly. Conversely, the project team may not gain the requisite experience to later tackle the more difficult product lines.

Consequently, neither extreme - too complex or too simple - is an appropriate tactic.

Action: Select the appropriate product family to model.

Designating the appropriate product family to start the modeling effort is properly a top management decision. Accordingly, the project team must identify the selection criteria before choosing and submitting a recommendation to the steering committee. Not all decision criteria will be compatible, thus, forcing an intelligent choice after considering:

  • The substantial business impact, such as potential to increase market share, that will help to gain and sustain organizational momentum
  • The degree of product complexity and the learning experience to be gained for the remaining modeling efforts
  • The readiness of the users

A prudent approach is to choose the first product family to model that gains significant business impact, yet is not too complex. Moreover, all users outside the project team should be able to fully understand the evolving configuration model.

In addition, continuing success would maintain the confidence of the management steering committee, as well as the eventual users.

Risk Number 8: Inadequate Testing of the Configurable Product Model

One of the worst possible risks is to have customers find errors in the product models as the models "go live." One cause of this risk could be lack of valid input from knowledgeable personnel during earlier phases of the project, resulting in an inadequate configurable product model. Superficial model testing may not identify faulty configurable logic.

Action: Preempt the risk with a comprehensive testing plan comprised of these elements:

  • Develop comprehensive validation methods, based on structured input, to test all possible combinations of configuration logic and error messages
  • Start testing early and do it often don't wait until the model is complete
  • Establish acceptance (buyoff) criteria, for instance, the ability to handle all structured input created to test the model logic, to produce error messages, and to develop an accurate configuration
  • Bring in prospective users from outside the project team to assist in early and continuous testing, such as those from sales, channel partners and selected customers
  • Recheck the adequacy of product modeling training

Avoiding the risks of inadequate testing exemplifies the integral relationship with previously identified actions, particularly assigning the "right" people to the project team.

Staying on the Right Track


Risk Number 9: Not Adequately Defining New Processes for Maintaining and Publishing of Models

In complex product companies facing blistering competition, constant change is expected, usually at lightning speed, driven by customer demands. Without adequate processes for updating product models in a timely and efficient manner, a number of risks can surface:

  • At an operational level - increasing maintenance costs and extended time to implement new models leads to the highest level of risk, that is . . .
  • At the strategic level - losing market opportunities, revenue and even customers. . . perhaps the most painful of all risks

An underlying cause of this risk might be that the project team mistakenly views the next actions as those to tackle just before "going live" with the new product models. Worse yet is that the project team did not exercise the discipline to take the following actions in earlier planning phases.

Action: Identify, define and test all processes associated with the timely revision of the product models well before "going live."

In configuration management terms, the goal is to ensure the revision integrity of the product models. A recognized best practice is to conduct a continuous and comprehensive conference room pilot using the evolving product models to generate these mandatory outcomes:

  • Identify all rules for change management of the product models
  • Validate all interfaces to related systems, such as ERP and PLM
  • Define/clarify all policies and responsibilities for the ongoing operation of the new processes
  • Accomplish any final education and training requirements before the next activity

Risk Number 10: Not Planning for User Acceptance of the New Product Configuration Processes


Waiting until late in the implementation cycle to plan user acceptance will only exacerbate the risks, already cited above. Scrambling at the last minute in reaction to user sensitive problems may trigger even more resistance: fear of excessive work pressure and loss of control at the time of "going live." The possible rewards of the new processes may no longer appear adequate or satisfying.

Action :Work proactively to develop a user acceptance plan.

The approach to avoid this risk starts at the time of gaining management commitment. While stated in this risk category, the project team must accomplish most of the following actions throughout earlier phases of the project:

  • Establish an active communications methodology beginning as soon as management has authorized the project
  • Create a sense of "ownership" of the configurable product models and the related new processes
  • Provide a feedback mechanism to the project team for additional improvements
  • Incorporate a mix of motivational methods, both positive (carrot), and as necessary, negative (stick)

Essentially, the project team needs to execute a marketing strategy for creating enthusiastic user acceptance, not foot dragging resistance.

Conclusion

For complex product companies immersed in the "To-Order" market, a configuration project is not an option - it is an absolute necessity to survive and thrive.

Forward thinking companies do not tolerate excuses for inaction, as . . . "Oh, but we are not ready." This is because in today's environment of blistering competition, doing nothing is one of the greatest risks of all.

Take purposeful, preemptive actions to avoid the potential risks to a configuration project - by catalyzing the next steps: review . . rate . . and tailor the actions outlined in this guide. Then, aggressively pursue them by closing any gaps between the company's current reality and the actions needed to be successful. This will help to ensure the maximum rewards from a configuration project - leading to major competitive advantages.

The Author

Richard W. Bourke is a principal consultant with extensive experience in systems planning and implementation. His clients have ranged from Fortune 100 companies to small manufacturing firms. For other publications, visit www.bourkeconsulting.com.

Contributing Author

Andrew Tubbs is the Vice President, Professional Services for Access Commerce in North America. He has more than 13 years experience implementing product configuration software solutions and has led more than 100 successful projects, including deployment of the first web-based configurator for the world's largest automotive OEM.

Notes and References


  1. Access Commerce, "Configurability: A Competitive Advantage," 2005.
    www.access-commerce.com.
  2. AMR Research, "Configuration is the Heart of Customer Fulfillment for Complex Product Manufacturers," 2003.
  3. Access Commerce, "Optimizing the Lead-to-Order Process," 2004.
  4. The Lean community differentiates the two conditions of processes as Current
    State (sometimes known as "As-Is") and Future State ("To-Be").
  5. Access Commerce, Cameleon Model Designer methodology, 2000-2006

About Access Commerce


Access Commerce is a leading provider of Multichannel Commerce Solutions.

Access Commerce helps manufacturing, distribution, retail and service companies sell products and services through any sales channels. The Cameleon Commerce Suite simplifies key steps in the Lead-to-Order to- After-Sales process by optimizing core business functions: e-commerce, electronic catalog and guided selling, product and service configuration, advanced pricing, quote and proposal generation, order management and BOM/routing generation. Employees, channel partners and customers use Cameleon to eliminate errors and non-value added activities, decrease cycle times and improve customer satisfaction, resulting in increased revenue and a reduction in sales and operational costs. Access Commerce customers include AREVA, Eaton, Invacare, Leroy Merlin, Manitou, Mitsubishi Caterpillar Forklift Europe (MCFE), Perkins Engines, Saint-Gobain, Schneider Electric, ThyssenKrupp, and X-Rite.

Access Commerce is headquartered in Toulouse, France and Chicago, Illinois and has offices located in North America, France and Germany. Cameleon is a trademark of Access Commerce SA and may be registered in certain jurisdictions. All other product and company names mentioned are the property of their respective owners.

For further information, email to info@access-commerce.com or contact us at:

North American Headquarters
5215 Old Orchard Road
Suite 270 - Skokie, IL 60077
Chicago
+1 (847) -583-8450

European Headquarters
Rue Galilée - BP 87270
31672 Labège Cedex
France
+33 5 61 39 78 78
www.access-commerce.com

Searches related to Top Ten Risks to a Configuration Project and How to Avoid Them:
Project Team | Configurable Product | Product Models | Product Modeling | Modeling Effort | Risk Number | Product Configuration | Risk Number | Build-to-order Product | New Processes | Product Modeling Effort | Configurable Product Models | Product Families Models | Project Management Software Configurable Product | Project Management Configurable Product | Project Management Process Configurable Product | Project Management Model Configurable Product | Enterprise Project Software Configurable Product | Project Management Processes Configurable Product | Project Management Online Configurable Product | Project Management Courses Configurable Product |
Project Management Tools Free Configurable Product | Web Based Project Management Configurable Product | Free Project Software Configurable Product | Project Management Books Configurable Product | Project Management Course Configurable Product | Project Management Templates Configurable Product | Project Management Training Configurable Product | Product Configurator | Made-to-order Product | IT Project Management Configurable Product | Project Management Office Configurable Product | Project Management Template Configurable Product | Project Management Tools Configurable Product | Project Management Plan Configurable Product | Project Manager Configurable Product | Project Management Fundamentals Configurable Product | Project Management Best Practices Configurable Product | Project Management Methodology Configurable Product | Project Management Life Cycle Configurable Product | Project Management Methodologies Configurable Product | Software Development Configurable Product | Software Development Life Cycle Configurable Product | Software Development Management Configurable Product | Business Software Development Configurable Product | Software Development Best Practices Configurable Product | Software Developer Configurable Product | Software Development Methodologies Configurable Product | Software Development Lifecycle Configurable Product | Software Developers Configurable Product | Configuration Process Configurable Product | Configuration Tools Configurable Product | Configuration Tool Configurable Product | Configuration System Configurable Product | Configuration Configurable Product | Configuration Software Configurable Product | Configuration Best Practices Configurable Product | Software Life Cycle Configurable Product | Product Life Cycle Management Configurable Product | Project Life Cycle Configurable Product | Product Life Cycle Configurable Product | System Development Life Cycle Configurable Product | Product Development Configurable Product | New Product Development Configurable Product | Product Development Software Configurable Product | Product Development Process Configurable Product | New Product Development Strategy Configurable Product | New Product Development Process Configurable Product | New Product Development Software Configurable Product | Risk Management Configurable Product | Enterprise Risk Management Configurable Product | Risk Management Software Configurable Product | Strategic Risk Management Configurable Product | Risk Management Consultants Configurable Product | Risk Management Project Configurable Product | Business Process Software Configurable Product | Business Process Modeling Software Configurable Product | Business Process Model Configurable Product | Business Process Management Software Configurable Product | Business Process Configurable Product | Business Process Management Configurable Product | Process Management Software Configurable Product | Management of Change Configurable Product | Software Change Management Configurable Product | Software Quality Management Configurable Product | Document Management Configurable Product | Product Data Management Configurable Product | Requirements Management Configurable Product | Product Management Configurable Product | Change Management Configurable Product | Data Management Configurable Product | Product Manager Configurable Product | Organizational Change Management Configurable Product | Supply Chain Management Configurable Product | Product Lifecycle Management Configurable Product | Product Management Tool Configurable Product | Business Software Configurable Product | Software Configurable Product | Risk Assessment Software Configurable Product | BPM Software Configurable Product | Product Configuration Software Configurable Product | Software Metrics Configurable Product | Risk Analysis Software Configurable Product | Configurator Software Configurable Product | Product Configurator Software Configurable Product | PLM Software Configurable Product | Software Testing Companies Configurable Product | Project Planning Software Configurable Product | Software Company Configurable Product | Configuration Software Configurable Product | Testing Software Configurable Product | Quality Software Configurable Product | Engineering Software Configurable Product | Quality Assurance Software Configurable Product | Development Methodology Software Configurable Product | Development Process Software Configurable Product | Quotation Software Configurable Product | Software Outsource Configurable Product | Intranet Software Configurable Product | Quoting Software Configurable Product | Project Risk Configurable Product | Project Plan Template Configurable Product | Project Tracking Configurable Product | Project Cost Estimating Configurable Product | Project Control Configurable Product | Project Implementation Configurable Product | Project Charter Template Configurable Product | Project Planning Configurable Product | Project Scope Configurable Product | Project Implementation Plan Configurable Product | Product Configuration Configurable Product | Product Configurator Configurable Product | Product Testing Configurable Product | Product Design Configurable Product | Product Mix Configurable Product | Product Planning Configurable Product | Product Rationalization Configurable Product | Product Strategy Configurable Product | Product Innovation Configurable Product | Product Definition Configurable Product | Product Design and Development Configurable Product | Product Lifecycle Configurable Product | Product Marketing Strategies Configurable Product | Product Configurators Configurable Product | Process Improvement Configurable Product | Risk Analysis Configurable Product | ERP Implementation Configurable Product | Prototype Development Configurable Product | Quality Plan Configurable Product | PLM PDM Configurable Product | Web Site Design Configurable Product | Bill of Material Configurable Product | Configurator Configurable Product | Organization Development Configurable Product | Bill of Materials Configurable Product | Sales Logics Configurable Product | Control Plans Configurable Product | Configurator Online Configurable Product | Project Management Software CTO Process | Project Management CTO Process | Project Management Process CTO Process | Project Management Model CTO Process | Enterprise Project Management Software CTO Process | Project Management Processes CTO Process | Project Management Online CTO Process | Project Management Courses CTO Process | Project Management Tools Free CTO Process | Web Based Project Management CTO Process | Free Project Management Software CTO Process | Project Management Books CTO Process | Project Management Course CTO Process | Project Management Templates CTO Process | Project Management Training CTO Process | IT Project Management CTO Process | Project Management Office CTO Process | Project Management Template CTO Process | Project Management Tools CTO Process | Project Management Plan CTO Process | Project Manager CTO Process | Project Management Fundamentals CTO Process | Project Management Best Practices CTO Process | Project Management Methodology CTO Process | Project Management Life Cycle CTO Process | Project Management Methodologies CTO Process | Software Development CTO Process | Software Development Life Cycle CTO Process | Software Development Management CTO Process | Business Software Development CTO Process | Software Development Best Practices CTO Process | Software Developer CTO Process | Software Development Methodologies CTO Process | Software Development Lifecycle CTO Process | Software Developers CTO Process | Configuration Management Process CTO Process | Configuration Management Tools CTO Process | Configuration Management Tool CTO Process | Configuration Management System CTO Process | Configuration Management CTO Process | Configuration Management Software CTO Process | Configuration Management Best Practices CTO Process | Software Life Cycle CTO Process | Product Life Cycle Management CTO Process | Project Life Cycle CTO Process | Product Life Cycle CTO Process | System Development Life Cycle CTO Process | Product Development CTO Process | New Product Development CTO Process | Product Development Software CTO Process | Project Team Responsibilities | Product Development Process CTO Process | New Product Development Strategy CTO Process | New Product Development Process CTO Process | New Product Development Software CTO Process | Risk Management CTO Process | Enterprise Risk Management CTO Process | Risk Management Software CTO Process | Strategic Risk Management CTO Process | Risk Management Consultants CTO Process | Risk Management Project CTO Process | Business Process Software CTO Process | Project Team Planning | Business Process Modeling Software CTO Process | Business Process Model CTO Process | Business Process Management Software CTO Process | Business Process CTO Process | Business Process Management CTO Process | Process Management Software CTO Process | Management of Change CTO Process | Project Team Planning | Software Change Management CTO Process | Software Quality Management CTO Process | Document Management CTO Process | Product Data Management CTO Process | Requirements Management CTO Process | Product Management CTO Process | Change Management CTO Process | Project Team Lead | Data Management CTO Process | Product Manager CTO Process | Organizational Change Management CTO Process | Supply Chain Management CTO Process | Product Lifecycle Management CTO Process | Product Management Tool CTO Process | Business Software CTO Process | Software CTO Process | Risk Assessment Software CTO Process | Project Teamwork | BPM Software CTO Process | Product Configuration Software CTO Process | Software Metrics CTO Process | Risk Analysis Software CTO Process | Configurator Software CTO Process | Product Configurator Software CTO Process | PLM Software CTO Process | Software Testing Companies CTO Process | Project Planning Software CTO Process | Project Management Team | Software Company CTO Process | Configuration Software CTO Process | Testing Software CTO Process | Quality Software CTO Process | Engineering Software CTO Process | Quality Assurance Software CTO Process | Development Methodology Software CTO Process | Development Process Software CTO Process | Quotation Software CTO Process | Software Outsource CTO Process | Intranet Software CTO Process | Quoting Software CTO Process | Project Risk CTO Process | Project Plan Template CTO Process | Project Tracking CTO Process | Project Team Structure | Project Cost Estimating CTO Process | Project Control CTO Process | Project Implementation CTO Process | Project Charter Template CTO Process | Project Planning CTO Process | Project Scope CTO Process | Project Implementation Plan CTO Process | Product Configuration CTO Process | Product Configurator CTO Process | Project Team Leader | Product Testing CTO Process | Product Design CTO Process | Product Mix CTO Process | Product Planning CTO Process | Product Rationalization CTO Process | Product Strategy CTO Process | Product Innovation CTO Process | Product Definition CTO Process | Project Team Members | Product Design and Development CTO Process | Product Lifecycle CTO Process | Product Marketing Strategies CTO Process | Product Configurators CTO Process | Process Improvement CTO Process | Risk Analysis CTO Process | ERP Implementation CTO Process | Prototype Development CTO Process | Quality Plan CTO Process | Software Project Team | PLM PDM CTO Process | Web Site Design CTO Process | Bill of Material CTO Process | Configurator CTO Process | Organization Development CTO Process | Bill of Materials CTO Process | Sales Logics CTO Process | Control Plans CTO Process | Configurator Online CTO Process |
Use this index to search for white papers related to commonly used search terms A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others 
Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others
A: 1 2 3 4 5 6 7 8 9
B: 1 2 3 4 5 6 7 8
C: 1 2 3 4 5 6 7 8 9 10 11 12
D: 1 2 3 4 5 6
E: 1 2 3 4 5 6 7 8 9
F: 1 2 3
G: 1 2
H: 1 2 3
I: 1 2 3 4 5 6 7 8 9
J: 1
K: 1
L: 1 2 3
M: 1 2 3 4 5 6 7 8
N: 1 2 3
O: 1 2 3
P: 1 2 3 4 5 6 7 8 9 10
Q: 1
R: 1 2 3 4 5
S: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
T: 1 2 3 4
U: 1 2
V: 1 2
W: 1 2 3 4
X: 1
Y: 1
Z: 1
Others: 1 2


©2013 Technology Evaluation Centers Inc. All rights reserved. Search powered by Google