RE: [ubl-csc] Re: CSC call on 26 November

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

> 
> I agree that the CSC is not the correct place for technical 
> coordination.  It's hard to achieve technical coordination 
> consistently, 
> and I agree that having liaisons between SCs would help in this area. 
>  In the NDR case, however, there was a liaison.  Oftentimes, 
> though, the liaison had nothing to report because nothing had come out of the NDR 
> team meetings - either the meetings were under attended, or what was 
> taken back from lcsc to ndrsc for review didn't get addressed, so the 
> issues kept getting pushed back.  

Rather interesting as NDR was constantly making decisions on rules.  Clearly there was a disconnect if those rules were not being conveyed. As for issues coming back from LCSC, I really don't recall many - other than containers.  

So, going back to the purpose of 
> having CSC as a coordinating body, this is exactly what was needed at 
> the time the liaison effort was not working for NDR.  We needed a 
> higher-level body to hear and help resolve the coordination 
> issue, which 
> was mainly a schedule/timing/response issue, allowing LCSC 
> and NDRSC to 
> resolve their technical issues through the mechanism they 
> already had in 
> place (or providing suggestions on other temporary mechanisms).

Ah, I see what you are talking about now.  Not a body to resolve the technical issues, rather a body to identify that the coordination of the technical issues was not being properly addressed.
 
> Regarding the QA Teams, although they did highlight technical issues, 
> those were sent back to the individual SCs for resolution.  Also, I 
> thought the QA teams were set mostly to handle final review 
> and release 
> delivery - wasn't the LCSC QA team originally a Packaging team? - but 
> didn't function during the early part of the development period. 
>  Another difficulty of the QA teams is that they suffered exactly the 
> same problem as the parent SCs.  There was an NDR QA Team and 
> an LCSC QA 
> Team.  The same issues related above applied to these two 
> teams.  With 
> Lisa's help we attempted to make them into one team towards 
> the end of 
> .70, but the attendance was mainly still LCSC.  If we expand 
> the QA Team 
> role I'm concerned this would create more of an overlap that would 
> create more of a management/coordination headache.  There 
> does seem to 
> be the need for an overall technical assessment team, though, which 
> would be an obvious responsibility of a QA (single) team.  
> Perhaps the 
> mechanism for this can be an item for the CSC to consider in 
> its new role?

I really believe there is a need for the QA team, and agree that CSC is the proper place to discuss the relative merits of it.  I was inferring from previous posts that folks were proposing the CSC resolve differences.  From your current post I think my inference was incorrect.

> 
> Going back to the NDR/LCSC coordination, what has happened is water 
> under the bridge.  What I'm grappling with now is 1.b) below, which, 
> along with better communication from ALL SCs, not just NDR, I believe 
> will prevent similar disconnects.  

I am still concerned that there is a disconnect between what is coming out of NDR and what is being realized in LC.


The reason I support creating a CSC that has a coordination function is that for a little while, 
> at least, I think we'll need both (clarification of responsibilities and 
> coordination of tactical issues related to carrying our those 
> responsibilities).  This is very much for me not 
> NDR-specific.  There is some overlap that needs to be acknowldeged and coordinated, and other 
> general coordination/communication that needs to occur, between ISC, 
> CLSC, LSC, and TTSC (and, of course, LCSC and NDRSC) if we 
> are to have a 
> meaningful, complete, usable release by February (only 3 months!).

I think what we need to do is have a better definition of what exactly would be entailed by the coordination function.


> Because there is some overlap in charter, there is a large 
> potential for duplication, which equates to wasted effort and confusion, neither of 
> which we can afford.  Much of this is not technical, it's 
> procedural - who does what and by when.  

But it is the technical disconnect that has caused the real issue here.

>Jon's master schedule coming out 
> of London, and Tim's 1.0 Beta schedule, are good examples of coordination tools. 
>  LCSC has been shouldering much of the recent coordination 
> burden, and it's certainly not required by their charter.  We justly need a single 
> overarching forum to resolvie issues - one that has the authority to 
> 'impose solutions' when issues arise that are taking us off 
> track, and the rigor of weekly touchpoints to ensure we are staying on track.

Ah, but there is the rub. I fully support increased coordination of schedules and the like but I would be very hesitant to give CSC the "authority to 'impose solutions'" related to technical issues. For example, in the disconnect between LC and NDR over the beta schema, that would mean that CSC would have to choose between the natural product of NDR (the design rules), or the solution implemented by LCSC (one persons preference for schema design).  Such autocracy is exactly the model that is broken in CEFACT -  Autocratic decisions by the executive based on personal preferences rather than on the technical work of the subordinate groups.

Mark