Complex Problems

Ayyasamy, Senthilkumar (UMKC-Student) saq66 at umkc.edu
Thu Jan 9 03:24:20 CET 2003


> 4.  Near-term vs. Long-term
> 
> We have an established track record of being good at developing
> near-term solutions to near-term problems. Our success at solving
> large-scale/complex problems has been by creating a sequence of
> discrete, near-term solutions. It is the aggregation of such a
> sequence that creates the larger and longer-term effect. When we have
> tried to tackle large problems all at once and in their entirety, we
> have tended to take a long time -- and often thereby lose the market
> window, as well as the attention of the workers -- to create large,
> complicated solutions, and to have a very, very spotty adoption
> record.

 I fail to understand your point. Lets take an ipng/ipv6, the most touted 
 long term problem. RFC 1550 is the initial solicitation draft for ipng. 
 If going by your method, how will you divide the ipng work  into numerous 
 sub-problems?  In theory, divide and conquer methods are easy. But, it will 
 be very difficult to split a complex problem at the *initial  stage*. How 
 will you split without *defining*  the  problem? If you mean splitting 
 of long-term problem *after the initial problem  defining process*, thats 
 what all WGs are doing ( atleast from what i have seen last one year.)

 Time period is not an important factor. If the WG charter is vague, it is 
 difficult to finish even a near-term problem, as we cannot reach 
 consensus. So, defining a crisp problem statement is important 
 whether it is near/long term.
  


More information about the Problem-statement mailing list