By Meetu Singh
Testing, for years, has been a fixed bid model or a FTE-based where a team of resources are finalized on a fixed cost and are available to work for 8-hours a day. However, effective resource utilization has been a proverbial challenge or a non-controllable factor for customers. The challenge has given rise to a new “pay-per-use” model in IT Software testing services where the onus passes on to the service provider to ensure that all resources are productive and deliver units to customer, thus ensuring that the customer stops worrying about resource utilization. Continuous improvement at process level & productivity performance along with agreed SLAs makes this model even more lucrative for customers.
In a transaction-based model, the cost-to-customer is based on the number of transactions executed. The model enables the customer to release management bandwidth and buy capacity as and when needed without incurring regular costs. The service provider is able to spread the investment cost by utilizing the delivery platform across multiple clients that need the same kind of service. This results in decreased per transaction costs and better economies of scale.
- Total cost of ownership by delivering more work for same cost
- Flexible team ramp up
- Business continuity with reduced ramp up-time
- Lean core team supported by strategic bench
- Quantitative management by effective KPIs
Transaction Based Model for Testing Services – A Point of View
Each test case design & execution test script is considered as a base unit. The test case is designed only once and can be executed multiple times during multiple test cycles – regression testing or smoke testing. Each execution of a test case would be considered as a separate test case execution unit. It is necessary to define the activities that are a part of the testing life cycle and whether they would come as a part of a test case design or execution unit. Below is a recommendation that can be customized as per the need. Any change to the definition would also have a clear impact on the unit price as well.
Traditional V/s. Transaction-Based Model
- Outsourcing Vendor TO Valued Service Provider – In the transaction-based model, there is a shift from being an outsourcing vendor to a valued service provider. The focus is not on providing resources but on service which customer has demanded.The business value of the service provider is measured by the amount of volume served rather than headcount provided which helps in demonstrating the capability & competency of the organization.
- Dedicated Team TO Lean Core Team – In the traditional model, the customer has to pay for all resources allocated and the entire team becomes critical to run the business. In transaction-based model, the resource structure is defined at three levels i.e. lean core team, flex team & extended team. Here, only the lean core team needs to be maintained as a fixed cost while the flex & extended teams can be built as per the forecasted or planned transactions. The lean core team should comprise of program manager, test managers, business / test analysts, test leads and a few testers which enables the team to do minimal committed transactions and have major focus is on the non-transaction activities. The flex & extended teams should be designed focusing only on the transactions. This helps in reducing cost for customers during a lean period.
- Pay as per Contract TO Pay as per Output – Pay as per contract is what defines the traditional model either in terms of fix cost or FTE based. The customer needs to pay the contracted amount irrespective of peak duration or a lean period in terms of business. In the transaction- based model, the amount to be paid is based on the number of transactions processed by service provider, which gives more financial control in the customer’s hands.
- No Risk Sharing TO Risk Sharing – Risk sharing is the key to success in the transaction-based model. Both the customer & service provider need to maintain transparency with respect to the visibility of work anticipated and any critical dependency at the customer or supplier side, since a delay in service would impact customer business and ideal time of team would lead cost implications to supplier. In lean times, the resources can be released from current assignment and can be utilized in other engagements. On the other side during the peak time, resources are scaled up with flex & extended team support at no extra cost to the customer.
- Reactive Knowledge Management TO Proactive Knowledge Management –In transaction based model it is the service provider’s responsibility to ensure that a strong knowledge management system is in place so that resource movement across teams are easily manageable without impacting the quality of delivery. Knowledge base at a lean core team level needs to be maintained & sustained to ensure there is no impact on customer business. The fact that service does not get disrupted during lean or peak times gives confidence to the customer.
Transaction-based pricing model for testing is a powerful mechanism that companies can seek in certain situations. Customers can derive significant benefits when there is demand variability in the project. The model helps in aligning the incentives between the service provider and the customer which leads to value maximizing for both parties through better utilization of resources and economies of scale.
About the Author
Meetu Singh heads the Business Excellence group -IT at InterGlobe Technologies(IGT). With a masters degree in IT , Meetu has 16+ years of experience in software development & enabling organization certifications like CMM, CMMi, TMMi, ISO 9001, ISO 27001, PCMM, ISAE 3402, PCI-DSS. She has worked with product development companies in the past for developing, implementing & improving processes. Meetu has been associated with IGT for more than 11 years and is instrumental in driving process & operational excellence initiatives. Being a Certified Scrum Master Professional, she also mentors and coach the team implementing Agile-Scum framework in line with client Agile Factory Model. Meetu can be reached at firstname.lastname@example.org