problem statement: Engineering practice vs. management practi ces

[Elwyn Davies]

Hi.

The intention was:
2.2 covers areas that are apparently down to failure to apply well-known,
essentially mechanical processes of Engineering as it should be practiced,
such as process improvement techniques, reviewing, setting of and keeping to
milestones, formal mangement techniques, etc.

2.7 covers areas which are apparently down to social engineering and human
interactions in the operation of WGs.

2.6 covers the structural and overall process issues.

So, yes, section 2.2 covers all the aspects of engineering process -
significant parts of management practice are engineering management
practice, and you are just as ineffective if you don't do the management
part as if you fail to use some appropriate configuration management tool or
bug database.  We are not saying that that any particular issue is down to
lack of a tool (that is solution space) but rather that we don't use tools
as well as we might and, yes, they exist.

We knew from the outset that not everybody was going to agree with what the
actual root causes are.  The question, at this stage, is do we need to do a
serious reworking of the document? 

Several points in line below...

Regards,
Elwyn 

> -----Original Message-----
> From: Thomas Narten [mailto:narten at us.ibm.com] 
> Sent: 17 September 2003 16:39
> To: problem-statement at alvestrand.no
> Subject: problem statement: Engineering practice vs. 
> management practices 
> 
> 
> > 2.2 The IETF does not Consistently use Effective 
> Engineering Practices
> > 
> >    For an organization with 'engineering' in its title and 
> participants
> >    who are likely to trot out the statement "Trust me, I'm 
> an engineer!"
> >    when confronted with the need to find a solution to a 
> particularly
> >    knotty problem, the IETF has, at least in some cases, extremely
> >    ineffective Engineering Practices.
> 
> 
> > 2.7 Working Group Practices can make Issue Closure Difficult
> > 
> 
> I have a hard time understanding the difference between 2.2 and 2.7
> and parts of 2.6. I _think_ section 2.2 is trying to say something
> about how we don't actually use more rigorous and formal internal
> processes that would help us avoid the problem of documents taking too
> long, etc. But one could argue that a lot of that is related to basic
> project management issues (or from Section 2.7 "Working Group
> Practices can make Issue Closure Difficult"), and its not always clear
> whether a cited issue is the lack of a tool (or lack of its use) or
> just lack of use of basic project management techniques, or just bad
> WG practice, for which there might be several ways to try and improve
> the situation.
> 
> Meta issue: Is the "root cause" issue the lack of use of
> management/engineering techniques, or would using better techniques be
> a _solution_ to existing poor practices (or to _some_ poor practices,
> but not others)? This document seems to not make this distinction very
> well, because it lists one underlying poor practice (e.g., section
> 2.7), but calls out a number of others in section 2.2. where they
> aren't listed as poor practices, but as consequences of not using
> appropriate tools.

Working backwards through this last paragraph:
- I don't know whether you mean that you think that we are implying that all
the items in 2.2 are consequences of the bullet point 'Tools to support the
engineering process...' or are you using tools in the more abstract sense of
well-known ways to structure the way we go about doing engineering,
including managing it.  If you mean the former then I don't agree with your
point.  If the latter, then certainly - that is just what is meant by the
whole section.
- The matter of whether having better engineering practices is a cause or a
solution has been aired before.  I believe that it is correct as it stands:
We clearly don't do some Engineering practices very well - we claim (through
our title and pronouncements) that we do Engineering and do it well.  In
that sense the IETF implicitly believes that Engineering IS the solution -
the problem is that we aren't doing it according to the accepted best
practice.
- The problems in Section 2.7 will not go away just because we do
Engineering better - they are issues of human diveersity and corporate
influence.  Normal corporations deal with these sorts of problems through
hierarchies, paychecks and hire & fire.  The IETF does not have these
sanctions and hence the problems cannot be made to go away in the same way
that they would in a 'non-volunteer' organisation.  They are not poor
practice in the sense of something done deliberately by the organisation or
exacerbated by failure to implement some well-known process.  They are
certainly poor practice by the culprits (but they wouldn't see themselves in
that way).  How to sort them out is likely to need social engineering.

> 
> Regarding Section 2.7:
> 
> >    2.7   Working Group Practices can make Issue Closure Difficult
> 
> IMO, Section 2.7 is a bit too narrowly scoped, and there are more
> examples that should be added here.  Existing WG practices are also a
> root cause issue. In that case, though, the section heading would be
> better made more general, e.g.:
> 
> >    2.7   Working Group Practices Contribute to Delays
> 
> Some additional examples for section 2.7:

2.2 does indeed cover the mechanical parts of the delay  - I would like to
keep this to the social engineering issue of driving concensus and issue
closure.

> 
>  - too many WGs have a adopated a cycle where the bulk of the activity
>    is centered around the face-to-face meetings. E.g., Many IDs are
>    revised only once per cycle, immediately before a meeting, with too
>    little active work going on in the months immediately after a
>    meeting.

I think this is covered by the need to have more granular milestones in 2.2.

> 
>  - despite IETF mantra that the WG is the mailing list, mailing lists
>    are become increasingly ineffective at resolving issues, e.g., too
>    many postings for many to keep up with, too many off-topic posts
>    (i.e, those not directly related to getting wording changed in a WG
>    document), folk being driven away because small number of vocal
>    posters, etc.

The point about concensus by exhaustion could perhaps be somewhat extended
to cover this.
> 
>  - Document authors are often not held accountable enough for
>    revising documents in a timely fashion

The problem is that guilt is the only tool you have.  We already talk about
this in 2.5.

> 
>  - As a WG document is being developed, reviews of WG documents too
>    often involve only interested WG members and don't include reviews
>    from those outside of the WG, or don't include reviews from subject
>    matter experts of topics that are related to the topic in the WG
>    document, but are not necessarily the focus of the WG document.
>    But when the WG says its done, and those outside reviews come in,
>    they are frequently viewed as being "too late" and the cost of
>    making changes is "too high". Frustration then results.

This *should* be covered by the 'Lack of auditing against explicit criteria'
item in 2.2, but it has probably become too abstract to remind us what the
problem actually is.

> 
> If section 2.2 is really aimed at non-management stuff, like tools, I
> think it would be useful make 2.2 state that clearly. Or if it is
> intended to cover both tools and management techniques, make that more
> clear (especially in the opening paragraph). I think it would also be
> good to rename/expand section 2.7 to cover more existing bad
> practices.
> 
> Thomas
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/problem-statement/attachments/20030917/6b2a59e8/attachment.htm