Project “Proof Of Concepts” activities are to prove (proof) something is functionally or technically possible in the software. Knowledge transfer is to ensure that project members are able to “come up to speed” on the “off the shelf” software functionality. There is a huge difference in the two activities with very different expectations and deliverables.
However, it is good to keep in mind that “off the shelf” software doesn’t fit into the old system development lifecycle that involve no prior software existence. Imagine when you implement “off the shelf” software, that you have come on to the project around the 80% software completion time point. You must “catch up” with the software instead of vice versa. Knowledge transfer can be thought of as “catch up, match, and design” activity.
“Catch up” with the software involves getting the project membership to think relative to what has been developed and not reinventing the wheel.
“Match” the software is trying to take the business requirements and matching them to the software functionality (relatively). The software does it differently true. But, the question is, does the software accomplish the same requirement?
“Design” the software involves both development efforts and configuration efforts. Design ensures that the software is optimally configured to meet all the business requirements except for those “gaps” in functionality that must be extended with a development effort. If the old business requirement is no longer required due to changes or practicalities in new software then knowledge transfer worksessions should drive them out for identification and accurate decision making criteria for both business and IT.
Siebel and Oracle PIM data hub are two very different products with very different implementation strategies. It is difficult if not impractical to create an identical project plan for both. Knowledge transfer (KT) of Siebel can be significantly more technical than KT for Oracle PIM data hub. I recommend at least two months of full (practical) functionality and design review with PIM team prior to absolute technical requirements identification and/or engagement of technical resources. Issues arise from “fixed costs” technical projects early in a project’s lifecycle. Resources involved in KT are both technical and business. Deliverables from a great KT exercise can include configuration documentation, CRP scripts, gaps identification and early technical design documents, conversion requirements (including translation and validation of conversion).
Please don’t cookie cutter the two implementations with identical activities.
Happy Holidays to all!
Thank you UKOUG for inviting me to speak at your event