~ By Ramkumar Krishnamurthy
Business requirements are solved either by building a new system or by buying a readily available product or by a combination of both. The 'Build vs Buy' decision is made by the stakeholders after weighing various parameters. A 'Build' decision results in tailor made projects (also known as bespoke projects or custom development projects) whereas a 'Buy' decision results in product or package implementation projects. The technical, functional and managerial challenges vary between these two categories and therefore the practices during project execution vary as well.
I managed both package implementation and bespoke projects and observed the following nuances and differences that affect project management between a product or package implementation project and a bespoke or custom development project.
|No.||Product/Package Implementation Projects||Bespoke Projects|
|1||The Project adopts or is influenced by the Implementation methodology of the Provider.||Methodology that is agreed between the Provider and the Customer is practiced.|
|2||Implementation Project Manager should be aware of the strategic and tactical initiatives in the Product at a high level as it can impact the Project.|
Implementation Project Manager should plan how to accommodate interim product releases or enhancements in the project lifecycle.
Implementation Project Manager should plan for managing the Configuration Repository Items that are a result of Product Customisation specific to a particular Customer.
|Project Manager need to focus only on the Project.|
|3||Changes can be initiated due to product bug fixes or product enhancements.||Changes are mostly due to change in requirements from user's perspective.|
|4||The version of the Product that is to be implemented along with the list of features needs to be confirmed with the Sales and Engineering team.|
Any product changes or Customisation that is specific for the particular implementation should be clearly demarcated from the product features.
Requirements are classified as those that are already existing in the product and those that need to be customised or incorporated for Customer specific needs.
|The entire set of requirements is built for a specific Customer and no classification is required.|
|5||Product walkthroughs helps the Customer to understand how the requirements are addressed by the product.||Prototyping or demonstrating the system developed is often the practice, depending on the size of the Project, as the Customer will be keen to see the system and check the progress.|
|6||Estimation for implementation is usually done by estimating for each activity and the result is captured as 'Effort in Person Days'. Estimation methods like function points are rarely used.||Project Manager can estimate based on his or her familiarity with a particular method of estimation (Function points, Use case etc.)|
|7||Customers usually prefer packaged products or solutions to reduce their time to market and therefore the expectation of timelines for implementation is usually aggressive.||As the solution is built from scratch, Customers usually understand the challenges and the timelines are not as aggressive as compared to packaged solution implementation.|
|8||Project revenues are classified as License fees, Customisation fees, Professional fees & Annual Maintenance Contract (AMC). Contracts are usually a mixture of fixed contract and time and material services.||Project revenues need not be classified into various categories. Contracts are usually fixed in nature though under some circumstances it can be time and material as well.|
|9||License fees are generally realised upfront. Customisation fees or Professional fees are tied to milestones.||Fees are tied to milestones.|
|10||The standards of the Provider organisation are used for deliverables. For example, templates for documents will be along the lines of the Provider organisation.||Customer may request the Provider organisation to adopt their standards for all deliverables.|
|11||Expectation of Customers differ from one another with respect to Product quality and the implementation and Product engineering team should work together to ensure that the Product meets the quality standards as agreed with the specific Customer.||Solution is built to meet the requirements of a specific Customer and the quality standards and expectations of the Customer should be met.|
|12||Customer's involvement will be minimal as Customer expects the project team to incorporate all the requirements in the product and also because of lack of knowledge of the product.||Customer will try and be involved as much as possible because of the concern of how the solution is evolving.|
|13||Team usually comprises of experts in Product or domain. Generally a matrix team structure is adopted. Project Manager needs to work with limited authority.||A projectized team structure is adopted. Project Manager usually has good control and authority.|
|14||Influential Power of the Project Manager is of great benefit. Hierarchical or Positional Power & Expert power cannot be of much use because of the presence of experts in the team.||Expert power & hierarchical power will be of great help.|
|15||Individual's and team's productivity is greatly dependent on Product Knowledge.||Individual's and team's productivity is dependent on Technical and Domain expertise.|
|16||Product or package releases and upgrades can impact the implementation project milestones.||Release is fully controlled by the project team.|
|17||Intellectual Property rights of the product is owned by the Provider. IP rights for the Customised portion of the product may be owned by the Customer or the Provider depending upon the contract.||Intellectual Property rights is owned by the Customer.|
|18||The product and the relevant deliverables may need to be deposited with an Escrow agent to protect the Customer against bankruptcy or any unforeseen circumstances to the Provider.||Customer has access to all the artifacts of the project and an escrow arrangement is not required.|
I am Ramkumar Krishnamurthy a certified PMP since January 2007. I work for i-flex solutions, recently renamed as Oracle Financial Services Software Limited. The thoughts and opinions expressed in this article are mine and do not reflect that of Oracle Financial Services Software Limited. I manage medium to large projects in BFSI space and enjoy exploring and implementing new ideas at work. I can be contacted at email@example.com