How's this for a change of pace? A work related post that is more observation than bitching.
We have been in the process of implementing Oracle's CRM on Demand since September 2009. I have implementation experience but this was a much more intense experience. So, even though we are only in pilot with tons of work and sleep-deprived days ahead of us, I thought I'd make a point to take some notes -- a 'Lessons Learned' kind of assessment.
Lesson #1: Get the right people involved. . . .EARLY!
Any time a technical product is being discussed, negotiated, or researched, the IT department and at least a few subject matter experts should be involved. Case in point, a database company trying to sell you one of it's business applications will almost always say 'Our product can handle whatever your business process may be as well as introduce you to best practice business processes that you may find useful.' Without IT input, questions such as does your application meet my business process specifications with little to no customization? Or will I have a ton of customization with your product simply being the interface for my customizations? Further, subject matter experts need to be available to verify that what your company reps are telling the vendor, in terms of how you do business, is correct. Often, executives have a high level understanding of what occurs beneath them but you don't want to base a million dollar application purchase on a high level understanding.
Lesson #2: Understand the limitations of your decisions
The product chosen was a hosted solution. In layman's terms this means we are buying software that we are not installing on machines within our company. Rather, the software will be hosted at, in this case, Oracle's site. Oracle will be in charge of hardware and software maintenance and upkeep which logically presents a cost savings in terms of administration of the software. Undoubtedly, this was told to the executive team. Also, undoubtedly, the ramifications of not having an actual product in your possession were not, I assume, weighed as heavily. As a developer, what I desire most is access. Access to development environments, databases, and whatever else I need to do my job. With a hosted solution, I am partially handcuffed. I no longer have free reign to 'go in the backdoor' and fix something through the database. I no longer have the power I once did. Not only is that a culture change for the development team, it's also a change for the user base who by now has gotten used to knowing that their IT team could formerly do tons of things in the application and around the application (reporting for example) with less red tape and quicker turnaround.
Lesson #3: Quality, Speed, Expense-- Pick Two
This is not so much a lesson learned as much as it is a personal project management guideline. I forget where I heard it but it has stuck with me through the years and I find it just as relevant now as I did years ago.
With every project, you have three main considerations: Quality, Speed, and Expense. You only get two of these three. Two you get to request at the forsaking of the third. If you want a project completed quickly and with good quality, expect to pay a handsome fee along the line to get that done. If you want a project completed cheaply and quickly, quality will suffer. And if you want a cheap project with quality work, it can be done but it will take time.
There are other lessons that I have taken from this project that I hope to xpine on here but it is saturday night.....
No comments:
Post a Comment