- Chapter 31: Working with Consultants
- Working with Consultants
- What Are Your Needs?
- Project Manager and Leadership
- Selecting Individual Consultants
- Work Ethic and Attitude
- Large-Scale Project Team Structure
- Preparation for Consultant: Contracts
- Preparation for Consultant: Rates and Fees
- Preparation for Consultant: Fixed-Price Contracts
- Controlling Consulting Project Costs: Change Managementx
- Controlling Consulting Project Costs: Client Involvement
- Controlling Consulting Project Costs: Reviewing the Original Requirements
- Controlling Consulting Project Costs: Weekly Status Reports
- Controlling Consulting Project Costs: Risk and Issues Log
- Controlling Consulting Project Costs: Importance of Database Administrator
- Consulting Work Environment
- Consultant Travel and Costs
- Case Studies of Consultant Behavior
- Case Studies of Client Behavior
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
What Are Your Needs?
Before you bring consultants into your business operations, start by asking yourself some basic questions:
What is the project? Define each project.
What are the goals of the project?
What roles and skill sets do we need in order to staff this project?
What are the deadlines and corresponding risks of missed deadlines?
Do we need to bring in consultants simply to help us determine our needs?
At a minimum, your company should begin the process internally by documenting requirements, as you understand them. Clearly, the products being implemented can have an influence on your requirements. Clearly, opportunities for business reengineering can influence your requirements. However, you must start from somewhere.
Documenting your requirements establishes a tangible point of origin for the project. Even if you bring in consultants to assist with a formal requirements analysis, they will need access to a great deal of your information. In essence, you will need to gather much, if not all, of this information later anyway. Thus, it is advisable to start now.
This process allows your various departments to begin thinking about the details of their future system needs. This process causes them to be involved early in the process and will be a significant momentum boost when the project implementation itself begins. This process helps your various departments to feel an ownership of the upcoming project.
Documenting the current business model and future business model is related to the goal of requirements analysis. By detailing all current business processes, you can determine if your requirements have been fully identified. The future business model is best developed utilizing knowledge of the software features of the ERP product selected. An important goal with the future business model is to utilize as many of the business trends and best practices that have already been designed in the software.
At some point in this process, it is usually advisable to bring in experienced consulting leadership for a formal requirements analysis and gap analysis. Consultants, if they are sufficiently experienced, should be able to bring in special knowledge and experience that complement the operational experiences of the internal staff of most companies. Consultants can help by demonstrating core functionality of the Oracle Applications and understanding the impact the Applications will have on your requirements.
Consultants can bring the experience of a variety of past implementations in the specific application areas desired by your project. The concept of best practices is often overused as sales hype. However, the origins of this concept have substance. An experienced consultant can bring her knowledge of the best (and worst) practices and procedures that she has observed from other companies. Moreover, consultants can bring industry-specific experience. This can be an important aspect in refining your "needs" during the requirements analysis.
Consultants can bring specific product knowledge that benefits the requirements and gap analysis process. Consultants can communicate these experiences to a client to determine whether the product's gap in requirements is a true gap that must be solved. Consultants can present alternative solutions with associated costs so that the client can understand the cost implications of its requirements. Some companies are wise in recognizing that their view of their true requirements can be altered during this process. Just because the existing business operation has worked the same way for 25 or 30 years, does not imply that there are not other equal or better ways to accomplish the same tasks. This argument can be exaggerated because a company should not arbitrarily change for the sake of change. However, the point remains that you should take a fresh look at what you perceived to be your requirements.
This leads into another point. Outside consultants should be able to bring a fresh perspective. They have no baggage based on your past 25 to 30 years of specific business operations, and will not have fear of retribution that some employees might feel about expressing similar needs to change the organization. Consultants have not been caught in the politics of why the past business operations have occurred in the current fashion. They should not be afraid to ask the question, "Why? What makes that past requirement a vital requirement in the future?"
The point to this discussion is to gain a grasp of your needs and requirements before and during the process of engaging consultants. Without doing so, a project implementation will have difficulty in being a success and will certainly cost more later than you now realize.