DPTASM 14: How about Billing and Reporting?
How do we handle Billing and Reporting?
In a typical case, Product and Project teams have their own respective dedicated team or team-member exclusively responsible for Test Automation. In case the Product and Project teams have their respective independent billing mechanism and reporting structure, which is more often the case, this is what the organization can do while switching to DPM’s Productized Test Automation Service Model (DPTASM).
Contribution Based Creation: Product and Project Teams may just contribute Hardware, Software and People to form the Test Automation Development and Engineering team. This contribution is made from the existing pool of Hardware, Software and People already available with the Product and Project teams. This is, in a way, how the Product and Project Teams share the costs associated with the Test Automation Development and Engineering Team and the Test Automation Common Infrastructure (TACI).
Logical Association Persists: The logical association of the members of the newly formed Test Automation Development and Engineering team with their respective source Product and Project teams in terms of Reporting Structure and Billing is maintained. That, anyway, are just the administrative and organizational control sides of the story.
Physical Association in Focus: However, the physical association of the team members with the Test Automation Development and Engineering Team and the internal structure or organization of that team are the aspects of greater importance. And, those important aspects are supposed to stay in focus in the context of the DPM’s Productized Test Automation Service Model (DPTASM). This move, from this point of view, from a conventional way to DPTASM, is an absolutely realistic and reasonable proposition.
The Constraint: The shift is achievable only if there is just the right organizational attitude, towards optimization of infrastructure and cost, is available. The lack of this attitude could be one of the primary constraints that the organization will need to address while shifting to DPM’s Productized Test Automation Service Model (DPTASM). Next Page >>
In a typical case, Product and Project teams have their own respective dedicated team or team-member exclusively responsible for Test Automation. In case the Product and Project teams have their respective independent billing mechanism and reporting structure, which is more often the case, this is what the organization can do while switching to DPM’s Productized Test Automation Service Model (DPTASM).
Contribution Based Creation: Product and Project Teams may just contribute Hardware, Software and People to form the Test Automation Development and Engineering team. This contribution is made from the existing pool of Hardware, Software and People already available with the Product and Project teams. This is, in a way, how the Product and Project Teams share the costs associated with the Test Automation Development and Engineering Team and the Test Automation Common Infrastructure (TACI).
Logical Association Persists: The logical association of the members of the newly formed Test Automation Development and Engineering team with their respective source Product and Project teams in terms of Reporting Structure and Billing is maintained. That, anyway, are just the administrative and organizational control sides of the story.
Physical Association in Focus: However, the physical association of the team members with the Test Automation Development and Engineering Team and the internal structure or organization of that team are the aspects of greater importance. And, those important aspects are supposed to stay in focus in the context of the DPM’s Productized Test Automation Service Model (DPTASM). This move, from this point of view, from a conventional way to DPTASM, is an absolutely realistic and reasonable proposition.
The Constraint: The shift is achievable only if there is just the right organizational attitude, towards optimization of infrastructure and cost, is available. The lack of this attitude could be one of the primary constraints that the organization will need to address while shifting to DPM’s Productized Test Automation Service Model (DPTASM). Next Page >>
Comments
Post a Comment