Guinea Pigs [was] Re: EPP [snip]

[plug-devel@lists.PLUG.phoenix.az.us]

Just a note on ERP integration:
We will need to track resources that may already be available in other data
arenas, such as people, equipment, locations, etc.  We should design to track
this information in a way that fits the greatest common denominator of our
potential users.  Actual integration can then be modularly added on through DB
query's, LDAP connectivity, etc..  (JAVA handles these very easily, but I
understand most languages could replicate the same thing with a page of
backend a page of business logic and a page or two of GUI, so again language
is not a concern at this time)


On Sat, 12 Mar 2005, Trent Shipley wrote:

> On Saturday 2005-03-12 14:04, Joseph Sinclair wrote:
> > Trent Shipley wrote:
> > > <<SNIP>>
> > >
> > >Well then let's do THAT big enough thing directly.  In that case let's
> > > drop IFA as some sort of stage or sub-project or whatever and go strait
> > > for what we expect to be the system's core competence, "the larger event
> > > planning community" (whatever that means).
> >
> > That's exactly what I've been advocating.  The only thing I was doing
> > with installfests is taking their user stories and moving them up in the
> > iteration plans so they can start using/showcasing the system while it's
> > still in development.
> 
> oh.
> 
> <snip/>
> 
> > >>The point of using lightweight development is to compensate for the fact
> > >>that we
> > >>  a) don't know a lot of things about what the user community needs are
> > >
> > >Agreed.
> > >
> > >>  b) don't have the resources to perform grounded research in this area
> > >
> > >I'm not sold on this.  Bryan, Shubes, and I have all offered to do
> > > research. The problem isn't finding researchers, it seems to be finding
> > > potential consumers willing to be researched.
> >
> > by research I was thinking the "professional market research" type, not
> > the "find some potential customers and ask them what they want" type.
> >
> > >Do we have a critical mass of participating consumers or not?
> >
> > No.
> >
> > >I am still pretty much leaning toward hunting down three or four more
> > >consumers and pumping them for grounded domain knowledge.
> >
> > Go ahead.  I'm certainly not going to stand in the way of that if anyone
> > wants to volunteer to do so.  I just don't have the background to go to
> > it myself.
> 
> OK.  Let's check out some possibilities.  Hans's stuff doesn't count because 
> he would LIKE to do some things but has not done them yet.
> 
> * We have Dennis K. and the Install Fest folks.
> * Joseph said he knew an event planner _per se_ .
> * Bryan has worked with people at ASU's Herberger College for the performing 
> arts.
> * I have volunteered for the city of Glendale, and might be able to find 
> someone there who basically works as an event planner.
> * I could go through the phone book calling funeral homes and wedding 
> planners.
> * I might be able to go down a couple of connections and find a concert 
> promoter.
> * I could call the major arenas and civic centers in the greater Phoenix area.
> * In some municipalities, Parks, Rec, and/or Libraries do events -- like 
> concerts in the park.
> 
> Does anyone want to add to the list?
> 
> Do you think that the ASU Software Factory will help us find prospective 
> domain informants or subjects?
> 
> Joseph, each item is essentially a sub-domain.  Since you are the one in 
> charge of "the vision thing", it would be helpful if you prioritized the list 
> so that interviewers could collect qualitative data from informants in the 
> sub-domains of greatest immediate interest.  I also like to get a rational 
> for my marching orders, but that is just me.
> 
> Now I should admit that it will be a learning process for me.  I have the 
> training to ask an Indian in Belize about farming maize and cannabis.  
> Researching event planning should be amenable to rapid appraisal techniques.  
> Also, I'm familiar with programming and IT.  But you should know that I am 
> not qualified _per se_ since I've never done both at the same time as 
> "business analysis" or "systems analysis"
> 
> Bryan or "Shubes" may be better at this.  (Though there should be enough work 
> to go around).
> 
> <snip/>
> 
> > ERP is [just] an inventory/accounting activity that doesn't mesh well with
> > events planning
> 
> My understanding of ERPM is more inclusive.  It is really database integration 
> across the enterprise.
> 
> <snip/>
> > Integrating with ERP would just impose constraints without
> > providing any benefit in this case.  None of the common functionality in
> > ERP/ERM will support any normal function in the event planning space,
> > unless the company is in the business of providing events, in which case
> > a relatively simple link into any existing ERP system would be
> > appropriate and sufficient.
> 
> In my experience, there is NO SUCH THING as a "simple" link into an existing 
> ERPM.  Peoplesoft, at least, doesn't do a good job of hiding its data layer.  
> There is no neat API.  Usually you have to hack directly into the database 
> layer that is enormous and unspeakably complex.
> 
> > >>>** Stratigic vision will be realized over time through many interations.
> > >>>** Iteration = customer
> > >>
> > >>Iteration == a small block of useful functionality
> > >>Customer == a large community that will (I REALLY REALLY REALLY hope)
> > >>grow and evolve over time
> > >
> > >I have a problem with this definition of customer.  It strikes me as
> > >poltically naive.
> >
> > Yes, it is naive.  I always prefer a naive definition for customer.
> > Handling political realities is done as necessary in practice, never in
> > definition.
> 
> Which brings us back to how I am going to persuade prospective informants to 
> give me access and interviews?
> 
> How am I going to present myself?
> How am I to present the project?
> How am I to pay for lunch (for example)?
>       (I understand that contributions to AZOTO are still not tax deductible.)
> Confidentiality?
> Can interviewees expect to get software out of this?
> 
> > >What does AZOTO (Hans?) want anyway?
> >
> > A minimum of support for planning the following event types:
> >   a) Monthly installfests
> 
> got 'em.
> 
> >   b) Semi-annual mega-installfests
> 
> E-Z to see how we could get 'em.
> 
> >   c) An open-technology conference
> >   d) An open-technology symposium
> 
> What is the difference between #c and #d
> 
> >   e) An open-technology meet-and-greet
> 
> What is #e?
> 
> >   f) An open-technology exposition
> 
> How is #b different from #f
> 
> > >If InstallFest is a subset of AZOTO (and not , why not do the reverse,
> > > design and build AZOTO then prove the solution's generality by applying
> > > it to InstallFest?  If it is important that the first project in EPP's
> > > strategic arc be "big enough" then lets not shilly-shally with
> > > InstallFest.  Lets go for it.
> >
> > The plan (in my view) is to build the first release for AZOTO needs.
> > The user stories will be organized to build the functionality to
> > implement the AZOTO requirements in approximately the order listed above.
> >
> 
> Are these AZOTO "needs" or AZOTO "dreams".
> 
> Since PLUG does monthly InstallFests we have experienced domain experts.  They 
> have ideas, we can research live InstallFests and come up with our own ideas.  
> Then we can talk to actual people with domain experience to collaberatively 
> build and deliver product.
> 
> Beyond that we have a cart-then-horse problem.  It is generally better to have 
> a Mega-Installfest THEN produce automation for Mega-Installfests than to do 
> the reverse, namely produce automation based on speculation about 
> Mega-Installfests then have a Mega-Installfest.  (It might, however, be 
> minimally acceptable to produce automation in parallel with the production of 
> an initial Mega-Installfest.)
> 
> In short, we cannot build event planning software for AZOTO/PLUG needs because  
> AZOTO/PLUG have little need for event planning software and even less 
> relevant domain expertise.
> 
> We pretty much NEED to find alternative un-customers who actually plan events 
> and try to produce software that they like.  Then AZOTO/PLUG can try using 
> the same software when materializing their vaporous event productions.  After 
> they have experience with planning an event and the blandly named Event 
> Planner Project then AZOTO/PLUG can provide useful input for EPP.
> 
> <snip/>
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>