The “cart before the horse” is the expression that comes to mind when I try to explain why people fail to save money with off shoring development resources.
I don’t want to anger anyone and say that I don’t believe that “off shoring” development for implementations works. I would really rather say, “get your facts straight before you go after the development resources”.
Most people are engaging development resources for application extensions too early in the implementation process. While I agree that conversion and interfacing should be identified and proven feasible early in the implementation, it is not literally an excuse to engage the “mechanic” before there is an engine. So in other words, “don’t buy the cart, before you buy the horse”.
Your money is not their to teach big off shore consulting firms how to use the Oracle Application module. Your money is there to get your business to use the Oracle Applications in an optimal fashion. Many projects have shown me developers on site and engaged off shore before the actual client side resources have enough knowledge to provide them the necessary requirements.
I have never seen those scenarios as successful as a client and consulting firm getting themselves well prepared to communicate their requirements. Unfortunately, I believe that some of this is intentional by the consulting firms themselves. Since I am not naming the culprits, then I am not liable to any heavy accusations.
You as the client should run your own litmus paper test on whether you are staffed too heavy on the technical side. Are your people confident(comfortably informed) enough to advise you? Do they fear your wrath? Are they turning in deliverables on deadlines because they will get into trouble if they don’t? Are the deliverables truly usable further in the implementation? Do you feel the answers to these questions are not going to be good for your organization?
The cold hard (harsh) facts:
1) You, the client, are responsible for ensuring that you get what you expect out of an implementation. (Not the developers and not the consultants.)
2) You, the client, are responsible for knowing the requirements are absolutely identified in whatever fashion it takes to clearly communicate to the technical staff what is going to be the accepted end result of their work (completely and utterly). Take this statement to heart, please. A functional specification is necessary to clearly communicate to two parties, the people who have to live with the result and the people who have to build it. Since you are the people who have to live with the consequence of miscommunications with developers, don’t you think you need to have qualified internal resources building these specifications along with trusted advisors?
3) You hire contractors to do the work that you need done. You hire consultants to help you ensure you are doing the right job. Know the difference between contractors and consultants. Really… Good consultants will seem expensive on the surface. If you use each resource correctly and understand the job that a consultant should do, then you will find a bargain in a highly paid consultant. Functional consultants cost more than developers. The better the functional consultant, the higher their price is typically.
4) Development skills in Oracle Applications do not require the same amount of experience that the functional consultants must have to be successful leading you to the finish line. Oracle Application functional consultants know how to put any business in the software when it is appropriate. They know business more than they know how to build software. They know how to listen for business differences and nuances. Developers don’t. I don’t want to discuss exceptions. This is not the purpose of this article. I have engaged really good Oracle application developers who didn’t know the module specifically but finished the job faster than the developers who claimed the knowledge. Techno-Functional is a horrible way of expressing a developer who wants to become a functional consultant. There is nothing wrong with the career path as long as the investment in a business degree or business experience is part of their plan. I hope that is not on your dime as well.
5) User acceptance is a real and hard goal to achieve. The more time you truly prepare for the real world the better return on investment you will get. You are responsible for USER ACCEPTANCE. You might contractually have some obligations of performance from the big old staffing company that you hired.
6) Price and size of the contracting/staffing firm does not necessary represent a bargain. You have hired a firm to do your implementation because they essentially gave you the services cheap and they don’t want to lose your business. Or, they want to get firmly planted into your organization (evil laugh pause…FOREVER). Was it a bargain really???
6a) Fixed price contracts are not (I repeat) fixed price contracts. You have engaged on a fixed price contract though you don’t know exactly what you want the contracting firm to do yet. Hmmm Do you think maybe there is some room for change orders? This is like buying a fixed price on building a house with no blue prints.
7) Your people are qualified to make better decisions for you at times at certain levels. Most business degrees in the past 20 years have been forced to take information system courses. I watched a very qualified IT manager forced to stay with a bad executive decision out of fear of losing the entire engagement. The executive was making stupid strategic decisions on the version of the software to implement instead of letting his experts make the decision. That was a 10 million dollar mistake that the old man never took responsibility for and the project hit many failures because of it. But the developers make a lot of money in the meantime doing nothing. Distraction?
8) You bought “off the shelf” software with the idea that you would save a ton (2 Kilos?) of money in development and time to implementation. Yet, you don’t even invest in catching up with the point where the “off the shelf” software has come. In other words, you don’t allow your internal organization to become knowledgeable in the software that is already written before they are forced to purchase development to change the “off the shelf” software. Please don’t confuse training with knowledge transfer when I state this point.
Since MDM solutions are supposed to bring immediate return on investment then why do we start immediately staffing these projects with confusion instead of clarity?
As a very senior functional application consultant, I observe many things on a project. I truly feel for today’s companies that effective “off shoring” for implementation development work requires more “front end” preparation. My points are expressed to ask you to pause for a moment and see this. If you are concerned, then stop and rethink the situation. Don’t make a problem worse with inaction.
I tell clients (without reservation), that it takes at least eight full weeks of intense face to face interaction with myself possibly spread out across twice that amount of time to prepare them to make good design decisions on Oracle PIM implementations. My competition typically tries to appease you with writing lots of logical data designs, E-R diagrams, etc.. Oracle Applications have already been built. You need to find your scope and business requirements before you start the project.
Implementation does requires some early decisions and engagement in certain specific areas of Product MDM:
1) What systems are going to be spoke systems to Product Hub? What data is going to be passed back and forth? Who can create, update, read, delete any of this product data?
2) What conversion of product data will be necessary? Do I need to plan a synchronization of this product data for multiple spoke systems?
So I recommend that you find your conversion and interface requirements early before you start but adjust those requirements as you work through about three months of configuration design.
Configuration design is my ideal first phase of the Product MDM. Configuration design requires no technical talent short of installing the Oracle application instances (hardware, software, etc). Some clients even buy space on remote servers to conduct their first phase while waiting for the internal infrastructure to receive and prepare hardware/software. This is kind of like the “conference room pilot” methodologies. This is getting the client team in a room and working them through the software application as compared to the identified business requirements. Configuration design pulls the business analysts appointed internally together with the functional consultants to initiate the creation of configuration documents (most important project deliverable next to the plan), use case creation for the product hub, scripts for use of product hub, standard operating procedures for product hub, conversion and conversion validation plan, hands on knowledge transfer to client (wow if we could measure this), contribution to the overall project plan, gap identification and functional solution design, and strong understanding of what has to be done in order to be successful.
“Off Shoring” for development of extensions, reports, and interfaces before the configuration design is a waste of money in my personal opinion. But it is also actually costing you more money than doing without.
Developers must try to justify their presence on the project before they are actually needed by requesting communication with project resources. The big contracting firms are very creative in getting this accomplished. Meetings, deliverables, emails are examples of things they will produce that will take away precious early time on the project.
Stop the bleeding and get your hands on the software! Remember? It is off the shelf software which means you can actually see it, touch it, learn it, design it, configure it, and plan to use it very early in an “off the shelf” implementation. Though it might take a while to identify and map your business requirements into the software, it is an activity that must occur before you go live.
The day you start the project, you are at least six aggressive months from go-live. You need to be properly prepared. If you know you won’t be doing the things you learn on the project after the project is over, stop. Think about that. You are doing the job you are supposed to do right now. You need to give your organization the best possible design.
One editorial note: Apologies, this could have been three articles instead of one.
- New Poll for Oracle PIM Data Hub Implementations (mckinleyalexandra.wordpress.com)
- Oracle PIM Data Hub Knowledge Transfer (who’s appropriate?) (mckinleyalexandra.wordpress.com)
- Implementation Strategy Comparison between Siebel and PIM Data Hub (mckinleyalexandra.wordpress.com)