As you’re aware, whatever metrics you choose will govern their behavior. Completed deliverables is a good start, but if you’re looking for well-tuned deliverables you could add a tuning-review “gate” through which each deliverable has to pass? Failure to resolve any items raised by the tuning-review committee will mean non-completion of the deliverable. Resolution of items raised by the committee should include the contractor asserting the expected benefit of the item is not worth the cost/effort.
As a housepainting contractor years ago, I bid fixed-price and was paid on deliverables, with 33% paid on signing the contract, 33% paid at a specifed half-way point, and 33% upon completion. Nowadays, I only do a few fixed-price jobs, but they are often structured similarly. Your tuning-review “gateway” for each deliverable would be logical as the “specified half-way point”, perhaps? Just an idea...
There are ways to accomplish the letter of just about any metric but not the intent. So, getting too esoteric will likely lead to a distorted result. If contractor does not trust such a committee not to be fair, then perhaps there isn’t enough trust (or desperation! :-) ) in the relationship to make it work anyway.
Hope this helps...
-Tim
on 1/18/04 11:04 AM, Thomas Jeff at [EMAIL PROTECTED] wrote:
Tim,
Thanks for the reply. We are thinking more along the lines of metrics pertaining
to identifying the required efficiency of the outsourced ETL task, e.g. time, resource
utilization,throughput, etc, in essence some desired baseline resource profile.
We are new to writing up RFPs at this level of granularity with respect to services, so
if this all rather unreasonable, in yours (or anyone's) opinion, I'd like to know. It's
not just a matter of defining that the deliverables are to be completed during X number of
days for $ cost, but we are thinking that we need to identify some metrics that would help
us to specify some acceptable performance criteria, against which we would monitor when
performing some form of acceptance testing. It does us no good if the contracted ETL
task capitalizes the box (like the runaway PL/SQL program mentioned by Ryan) and takes
3 days to complete.
-----Original Message-----
From: Tim Gorman [mailto:[EMAIL PROTECTED]
Sent: Friday, January 16, 2004 10:54 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: SLA/metrics for RFP for programming services
How about specific deliverables within a specific period of time for a total amount not-to-exceed? Can’t think of any other metrics that matter...
on 1/16/04 2:19 PM, Thomas Jeff at [EMAIL PROTECTED] wrote:
If you were to write up a RFP for programming services, what kind, if any, metrics
would you include to provide some measurements by which performance of the contract
can be assessed? The tasks will typically be writing up ETL runs for our DW.
CPU, LIO, wait events, etc?
Thanks!
--------------------------------------------
Jeffery D Thomas
DBA
Thomson Information Services
Thomson, Inc.
Email: [EMAIL PROTECTED]
Indy DBA Master Documentation available at:
http://gkmqp.tce.com/tis_dba <http://gkmqp.tce.com/tis_dba>
--------------------------------------------
