Re: [rfc-i] New proposal/New SOW comment period

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sarah and Adrian,

Just to make sure that the last call isn’t lost in the other kerfuffle, I agree with Adrian’s comments, and with your response to Mike.

Best wishes to you (and to us all!) on a successful RFQ/hiring process.

Eliot

> On 31 Aug 2019, at 12:32, Adrian Farrel <adrian@xxxxxxxxxxxx> wrote:
> 
> Hi Sarah,
> 
> [Deliberately continuing the discussion cross-posted despite the Sergeant At Arms’ entreaties]
> 
> Thanks for coordinating the construction of this draft and for putting it out for comment.
> 
> In the ensuing discussions…
> 
>>> 1) Is this a full time position?  If not, then describe the expected
>>> workload.   From the description, it's a level of effort contract
>>> somewhat less than full time.  State that level.
>> 
>> SB// The RSOC in years past has specifically stayed out of the "how
>> long does it take to do the job" and the "this is a 32-hour-a-week"
>> job. I'd defer this to the LLC; if the person they're hiring is a contractor
>> I'm not sure this matters, since they're bidding on the total amount of
>> work (that's been the thought) versus the employee who clearly needs
>> to understand if this is a part time or full time job.
> 
> When people bid fixed-pay fixed-deliverables on a contract, they usually have a pretty detailed description of the work, that way they can work out how much time they think it will take them, and bid accordingly. If such detail is not available, a wise contractor will make an estimate and add a lot of contingency. That puts up the price paid by the customer, potentially unnecessarily. OTOH, an unwise or "keen" contractor may under-bid risking that a poor job will be delivered. Frankly, the more detail supplied, the more accurate the bid and the better the work.
> 
> Alternatively, the customer may give better guidance as to the expected amount of work. The draft says that RFC 6635 section 2.15 is not applicable, and (of course) that is true because this SoW does not cover all of the job described in the RFC. But at the same time, it should be clear to everyone that if 6635 considered that the job was 20 hours per week and nearly full time during IETF week, then the work covered by this SoW is bounded by that as an upper limit.
> 
> Anyway, I don't think the current draft has enough detail of what the job is to enable a meaningful bid. Maybe this is fixed by simply adding something to say that during the process of preparing bids and on request, the RSOC will make available to bidders additional information to help them scope and understand the nature of the tasks.
> 
> 
> Further to the tactical/strategic discussions on the list, I don't think it is helpful to show your thought processes in the SoW. I would suggest:
> - Strike "The RSE’s job functions can be logically split into 2 functional areas: strategic and tactical."
> - Replace "is being created to fill the tactical functions of the RSE role" with "is being created to fill certain functions of the RSE role as listed below"
> - Strike "These “tactical” responsibilities of the RSE are not defined explicitly in RFC6635; the expected nature of the work is explained below."
> Doing this would allow you to make the list of tasks you want done, without getting into discussion of whether they are 73% tactical and 27% strategic.
> 
> 
> I struggle with the following paragraph:
>   Some of the functions described below may not be possible within that timeframe
>  (for example, chairing the search committee when the RPC contract goes out to bid
>  again). It is expected that this position and the person filling it will work with the
>  RSOC to identify new or changing work items as they arise.
> 
> To me this reads as though you want the contractor to be very flexible on deliverables. Firstly you are giving permission for the contractor to not deliver some things: I guess that's OK, no one will object to being paid for not delivering 😊 Second, you might be saying that new/changed deliverables may arise, but you are not making it clear whether you expect them to be delivered under the contract or not. The usual way to handle both of these points is "variations by mutual agreement in writing."
> 
> 
> Why "Scope of work - primary"? Is there a secondary scope of work somewhere?
> 
> 
> I would expect to see a termination clause.
> 
> 
> The line "This relationship is subject to later reorganization" should be business as usual in a contract like this, but the history suggests that it might be better to be a bit clearer. Just as a point of note, the previous paragraph names the RSOC as the body with whom scope changes might be identified, but (presumably) if the reporting changed, that wouldn't be true.
> 
> 
> Finally (you'll be glad to hear), what is the purpose of item 3 on the Affidavit? Is the intention here that you propose that only entities registered in the US for tax purposes may win this contract?
> 
> Good luck!
> Adrian
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux