[SpaceProgram] Communication / Collaboration tool

Paul Szymkowiak paulszym at gmail.com
Tue Sep 18 06:16:08 CEST 2012


Hi Brent,

On 18 September 2012 13:01, Brent Shambaugh <brent.shambaugh at gmail.com>wrote:

> I've been thinking about  and researching stuff like this for some
> time.


Me too :) -  it's my day job, and a regular part of my consulting practice.


I have many more related things, which I can share if
> appropriate. Is there a place to develop things more? Are there people
> to partner with? Is this the appropriate place?
>

Feel free to strike up a conversation with me, maybe off list. As a member
of the caretaker team, I can make sure the other team members are across
what we discuss, cc them in as needed. As it takes shape, we can feed it
back to the broader open list, and invite wider participation as
appropriate.

Cheers,

Paul


>
> On Sun, Sep 16, 2012 at 4:52 PM, Paul Szymkowiak <paulszym at gmail.com>
> wrote:
> > Let's take what lessons we can from product life cycle management, and
> apply
> > what seems appropriate as we explore a maker solution management
> approach.
> >
> > Having a way to assist our management of activities and their associated
> > milestone events and deadlines will be helpful. Lot's of simple software
> > will help us do that: Google apps: Calendar plus one or two plugin's will
> > work pretty well.
> >
> >
> > On 17 September 2012 05:37, cole santos <cksantos85 at gmail.com> wrote:
> >>
> >> I wasn't thinking fancy software, I was thinking it was more of an
> >> organizational principal and common grant theme.
> >>
> >>
> >> On Mon, Sep 17, 2012 at 2:34 AM, Jerry Isdale <jerry at mauimakers.com>
> >> wrote:
> >>>
> >>> The area where I can see us needing a PM package is in the management
> of
> >>> SpaceGAMBIT iteself
> >>> We will have multiple projects with various deadlines and gating events
> >>> (grant submission, selection, negotiation, award, reporting etc) that
> will
> >>> need to be tracked, as well as the fundraising, and annual symposium.
> >>>
> >>> Again though, these task do not require the elaborate engineering
> PLM/PM
> >>> tools.
> >>> We do have Prolific.com as one option.  It is a commercial tool but for
> >>> use on this project I could probably negotiate a deal.  The principle
> behind
> >>> it is a good friend and supporter of Maui Makers. (Reichart von
> Wolfsheild).
> >>>
> >>> Jerry Isdale
> >>> http://MauiMakers.com
> >>> http://www.mauimakers.com/blog/thursday-public-meeting/
> >>>
> >>> On Sep 16, 2012, at 2:23 AM, Jerry Isdale wrote:
> >>>
> >>>  If we were doing the full Build A Starship project, then yes
> definitely
> >>> we would need a PLM/PM package.  Most of the HSP/SpaceGAMBIT projects
> are
> >>> going to be far too small to utilize a large PLM (product life cycle
> >>> management) or Program Management package. This sort of software, with
> its
> >>> requirements management and resources, etc can be quite useful on big
> >>> projects, but often requires dedicated staff to maintain it.  There
> are much
> >>> lower effort ways to manage a small project... especially with a very
> small
> >>> team (1-3 people).
> >>>
> >>>
> >>> Jerry Isdale
> >>> http://MauiMakers.com
> >>> http://www.mauimakers.com/blog/thursday-public-meeting/
> >>>
> >>> On Sep 15, 2012, at 6:34 PM, Paul Szymkowiak wrote:
> >>>
> >>> I have mixed feelings about the relevance of PLM as defined in the
> >>> referenced wikipedia page to a hacker/ maker based approach to some
> notion
> >>> of product, but also generally as it relates to the kinds of discovery
> and
> >>> problem solving this SpaceGAMBIT effort is wanting to encourage.
> >>>
> >>> As we step towards more and more complex solutions, I think some of the
> >>> PLM tools will be helpful in managing inventories of parts for
> projects or
> >>> solutions. This will be especially useful where the tool can support
> complex
> >>> solutions with many thousands of parts, and where distributed,
> parallel and
> >>> collaborative solution development will occur, such as multiple teams
> >>> working in parallel on subsystems as part of a larger product. If a
> product
> >>> doesn't readily support that, it's probably of less use to us.
> >>>
> >>> Of course, our SpaceGAMBIT projects - and probably ultimately products
> >>> and services - will have life cycles, but I think good life-cycle
> models are
> >>> largely a reflection of the underlying philosophy and culture or the
> people
> >>> involved.
> >>>
> >>> In my view, PLM as described in the referenced Wikipedia article,
> appears
> >>> as a cleanly phased, sequential approach, where a product passes
> through a
> >>> series of stage gates from concept through to use and finally
> disposal. Of
> >>> course, these phases do describe things that happen during the life
> cycle of
> >>> a typical product-development effort, however they aren't necessarily
> >>> relevant as phases. Although the Wikipedia page mentions that LCE is
> >>> iterative, the PLM defined here doesn't reflect that well. It does
> briefly
> >>> refer to "backing up" into earlier phase, but as an experienced method
> >>> author, I find it kind of sloppy when a method is idealised to a point
> where
> >>> it doesn't suitably reflect and support reality, appears to address
> real
> >>> world concerns by passing reality off as an exception, and then claims
> to be
> >>> practically useful to enact PLM.
> >>>
> >>> From a method architecture perspective, I think there is little value
> in
> >>> having an overarching product lifecycle model that simply reflects the
> >>> detailed activity that obviously needs to occur: for me, it's
> equivalent to
> >>> having a "hammer nail" activity within a "hammer nail" phase. Phases
> for me
> >>> need to speak to useful and important strategic goals. But more to the
> >>> point, I think this type of PLM philosophy doesn't reflect the reality
> of
> >>> PLM in exploratory, evolutionary prototyping - the very approach that
> makes
> >>> hacker and maker spaces what they are.
> >>>
> >>> My closing critique is that the definition here appears to be based
> >>> predominantly on information drawn from the field of automotive
> engineering,
> >>> a context  where the basic product is arguably very well understood. I
> tread
> >>> with caution when applying methods and practices suitable in one
> context to
> >>> different context. How much does the building of cars using
> standardised
> >>> assembly line production have relevance to hacker/ maker creation of
> new
> >>> products in the context of space exploration?
> >>>
> >>>
> >>>
> >>> Paul
> >>>
> >>> Paul Szymkowiak
> >>>
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hackerspaces.org/pipermail/spaceprogram/attachments/20120918/725d10bc/attachment.html>


More information about the SpaceProgram mailing list