Project Management and Open Design
Ireton5
development process? On one hand, project management plans,
schedules, and milestones fly in the face of the loosely organized
evolutionary process of open design development. On the other hand,
it seems that some level of organization is needed to go from concept
to product.
There have been many successful open source projects in the software
world, and perhaps a few in the hardware world too but I'm less
familiar with those. Diomidis Spinellis argued that the open design
development model can be superior to a tightly controlled central
planning process. I believe it. What I am trying to understand is,
what if any traditional project management tools should be applied to
open design? Many large companies use a set of well defined project
milestones during product development. Unless project management is
dictated by some regulatory body, these companies choose to use it
because it provides some benefit. How would milestones be useful in
open development? It seems natural to me that any project would start
with a definition stage that would clarify and document the goals and
requirements. In an open development process, I would expect that
each phase of the project would include lively discussion guided by
meritocracy. Following project definition would be a phase of design
concepts. There may be multiple design concepts worked in parallel
until eventually one emerges as the best solution. Bits and pieces of
the design may be worked out and tested during the concept phase.
When the concept is clear, project members can pick up little pieces
of the design and work on them as they have time and interest.
Without clarity of the concept, or maybe a system level design,
project members could easily be designing square pegs to fit in round
holes. Eventually a design reaches a point when it is ready to be
prototyped. Once a prototype is proven to meet a set of requirements,
others can feel confident to use and extend the design. I think that
milestones could be useful in organizing and focusing the efforts of
the project members.
Could milestones restrict an evolutionary development process?
Imagine a project that has reached the point where a prototype has
been built and meets the basic requirements. Then someone comes up
with an entirely new and better design concept. Is that person told
to go away because it is too late? Does the project hit the restart
button and abandon the prototype? Or does the design concept spawn a
new project while the original project goes to some kind of
completion. In the corporate world, I would expect time to market
pressures and sunk investments to drive the original project to
completion. In open development, meritocracy and a survival of the
fittest paradigm might mean that the original project has a sudden
death. Whatever happens in open development, it will be through the
free choice of the project members, subject to their morals and
motivations. Any defined milestones need not restrict the project, in
fact they cannot by the nature of open development.
I like chaos, revolutionary ideas, competition, evolution, out-of-the-
box thinking, and meritocracy. These are the ingredients for a
breakthrough. How does a concrete design emerge out of chaos? I
don't know, but I hope to find out. If you have examples of
development processes or tools that work or don't work in an open
development environment, I'd like to hear about them.
Peace,
Mark
Sam Putman
> How should the tools of project management used in open an open design
> development process? On one hand, project management plans,
> schedules, and milestones fly in the face of the loosely organized
> evolutionary process of open design development. On the other hand,
> it seems that some level of organization is needed to go from concept
> to product.
>
Great question! To employ maximum handwaving as an alternative to
several pages of early, poorly-reasoned thinking, I'm picturing a
combination of GTD philosophy and Agile development techniques.
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/GTD
Neither of these relies on hierarchy or management in the usual sense.
> In an open development process, I would expect that
> each phase of the project would include lively discussion guided by
> meritocracy. Following project definition would be a phase of design
> concepts. There may be multiple design concepts worked in parallel
> until eventually one emerges as the best solution. Bits and pieces of
> the design may be worked out and tested during the concept phase.
> When the concept is clear, project members can pick up little pieces
> of the design and work on them as they have time and interest.
> Without clarity of the concept, or maybe a system level design,
> project members could easily be designing square pegs to fit in round
> holes. Eventually a design reaches a point when it is ready to be
> prototyped. Once a prototype is proven to meet a set of requirements,
> others can feel confident to use and extend the design. I think that
> milestones could be useful in organizing and focusing the efforts of
> the project members.
>
Prototype early, prototype often is an excellent maxim. With access to
decent 3-d printing, breadboards and all the rest of the tools we have
now, why spend a bunch of time refining designs before building
something? Easiest way to see if one is on the mark is to build.
In general I wouldn't worry to much about requirements, milestones and
all that, so much as actually developing some good designs. If someone
improves on the design for some given widget, or develops another
widget entirely that does the job better, that's to be expected since
our era is one of rapid technological change. A big advantage in open
manufacturing is that organizations who are making the old technology
are free to adopt the new technology quickly, rather than having to
continue to build on janky designs because they're blocked by patents
or proprietary design from participating in new advances.
Cheers,
-Sam Putman.
Bryan Bishop
> On Thu, Feb 11, 2010 at 10:55 PM, Ireton5 wrote:
>> How should the tools of project management used in open an open design
>> development process? On one hand, project management plans,
>> schedules, and milestones fly in the face of the loosely organized
>> evolutionary process of open design development. On the other hand,
>> it seems that some level of organization is needed to go from concept
>> to product.
>>
>
> Great question! To employ maximum handwaving as an alternative to
> several pages of early, poorly-reasoned thinking, I'm picturing a
> combination of GTD philosophy and Agile development techniques.
Hold your horses, there. Let's get him up to speed on revision control
first. I think this is way more important, and something that the
community hasn't yet picked up on. Heck, only a handful of us know how
to clone a repository. Collaboration comes after the basics.
Sam Putman
This thread, as the subject indicates, is about project management and
open design. Revision control wasn't mentioned.
Perhaps you've confused this thread with something else?
Confused,
-Sam.
Bryan Bishop
> On Fri, Feb 12, 2010 at 1:20 PM, Bryan Bishop <kan...@gmail.com> wrote:
>> On Fri, Feb 12, 2010 at 3:18 PM, Sam Putman wrote:
>>> On Thu, Feb 11, 2010 at 10:55 PM, Ireton5 wrote:
>>>> How should the tools of project management used in open an open design
>>>> development process? On one hand, project management plans,
>>>> schedules, and milestones fly in the face of the loosely organized
>>>> evolutionary process of open design development. On the other hand,
>>>> it seems that some level of organization is needed to go from concept
>>>> to product.
>>>>
>>>
>>> Great question! To employ maximum handwaving as an alternative to
>>> several pages of early, poorly-reasoned thinking, I'm picturing a
>>> combination of GTD philosophy and Agile development techniques.
>>
>> Hold your horses, there. Let's get him up to speed on revision control
>> first. I think this is way more important, and something that the
>> community hasn't yet picked up on. Heck, only a handful of us know how
>> to clone a repository. Collaboration comes after the basics.
>>
>
> open design. Revision control wasn't mentioned.
Revision control wasn't mentioned probably because he doesn't know
about it. That's why we have these threads.. so we can talk about the
technologies that we don't all know about.
> Perhaps you've confused this thread with something else?
No.
John Griessen
I'm up on rev control systems like git, subversion, cvs.
They are a good help in managing projects with much detail
where you are finding out new things and some avenues of progress
need to be abandoned. With a rev control system you can set up
directories that are check outs of the same repository where one dir
has the whole project under it in its leading edge state, and
another dir has the whole project under it in a state branched off
an older version of the project.
Mostly when you think of managing a project as with PERT charts, GTD, etc.
you think of the leading edge version of it only and that's fine for
most things that are business-like. For a more risky and unknown
research project, having windows to past versions and even developing
two versions at once might pay off and that's where version control
comes in handy.
Even for ordinary projects that usually never look backwards,
version control is handy for getting old states
of something that was rewritten. For instance when you hit a wall and have no
past version carefully defined at all you can still quickly go back in time
to any place you did a commit... One thing to do with a VCS is
make committing easy and do it often :-)
Thanks for mentioning GTD. I grabbed debian iceowl-extension and added
it to my icedove installation and am going to start flagging things.
For those not using debian, those names correspond to Thunderbird
mail reader and Lightning calendar apps.
John
Greg
hardware design project. I suspect most projects start out as one
person's brainchild and only take off once they reach a level of
usefulness, or at least an expectation of potential usefulness. Like
most traditional projects, the most important part is in the initial
stages of planning and organization, but for different reasons. In a
traditional project, the planning is important for compressing
timelines to be first to market. In an OS project, it is critical to
reaching the take off point where other people besides the originator
are motivated to get involved.
What I have found is that for the most part, systems engineering
methodologies are more appropriate up front than the more narrowly
focused project management ones in defining requirements, getting from
requirements to a work breakdown structure, and from a WBS to a task
list and a part tree. As far as project management goes, that task
list is all important and should be on the front page of the project's
website. GTD seems a pretty good philosophy for managing the task
list, but I admittedly don't have much practical experience with it.
First and foremost, people have to know WHAT needs to be done. It
helps to know who is working on what, to avoid duplication of effort,
but OTOH, one of the advantages of open source design is the ability
to pursue parallel design solutions, so revision control and the whole
concept of "trunking" designs are a lot more relevant to open source
PM than Gantt charts. While Gantt and PERT charts are next to useless
for a volunteer driven project, the task dependencies should be
somehow shown in the task list, or at least taken into account in the
task priorities. Most of this task management can be done
programatically (rather than being actively managed by a PM), but I
have yet to find an open source software package available that can do
this to my satisfaction. Subsequently, I have been unable to
adequately implement this in my own project (xmaran.org), but I still
am happy to get feedback on the project (or help from anyone
interested in experimenting with an open source hardware project).
Greg V
John Griessen
> I've been giving this some thought while setting up my own open source
> hardware design project.
.
.
one of the advantages of open source design is the ability
> to pursue parallel design solutions, so revision control and the whole
> concept of "trunking" designs are a lot more relevant to open source
> PM than Gantt charts. While Gantt and PERT charts are next to useless
> for a volunteer driven project
Why useless? You can still identify the necessary steps of each parallel path.
If you're planning to "just let creativity lead you" to multiple working
prototypes that meet specs, it might not work out... in your lifetime.
A PERT chart identifying the minimum steps/milestones and having people who are
responsible for them sign up to do them and sign as done when they
complete them keeps people beholden to "their word". So you can get them to
keep a promise. I define a project as something with a delivery date.
I think your are less likely to find parallel developments than one minimally
satisfactory path, else someone has worked on something to be abandoned.
Who wants a 50%/50%, (or worse in a larger partnership), chance their work will
be abandoned? I'm doing open hardware because some of my work never saw light
under for hire management, not because I don't care.
John
Leo Dearden
...Heck, only a handful of us know how
to clone a repository. Collaboration comes after the basics.
I think your are less likely to find parallel developments than one minimallysatisfactory path, else someone has worked on something to be abandoned.
Richard Schulte
> reaching the take off point where other people besides the originator
> are motivated to get involved.
Yes, this is key for any non-market driven, or non-conventionally
market driven project. Open Source Ecology has been most successful
when its various projects reach these points.
> What I have found is that for the most part, systems engineering
> methodologies are more appropriate up front than the more narrowly
> focused project management ones in defining requirements, getting from
> requirements to a work breakdown structure, and from a WBS to a task
> list and a part tree. As far as project management goes, that task
> list is all important and should be on the front page of the project's
> website.
You should check out our build of Redmine, OpenPario.net. It kind of
radiates around its queryable Issue lists. You can set 'Versions' or
'milestones' for developming roadmaps as well. We are working on
turning it into a more engineering-focused project environment, and
are looking to hopefully integrate with a system like SKDB so that
issues can be related to components, function, production, etc. Right
now, you can set issue categories that can refer to components, and
even use a components tracker to filter down to these specific items.
You could even create a custom query that would group issues by
'components', filter them to only components, and sort them by
priority, percent complete, due date, or whichever.
> ...one of the advantages of open source design is the ability
> to pursue parallel design solutions, so revision control and the whole
> concept of "trunking" designs are a lot more relevant to open source
> PM than Gantt charts. While Gantt and PERT charts are next to useless
> for a volunteer driven project, the task dependencies should be
> somehow shown in the task list, or at least taken into account in the
> task priorities.
Our system allows you to build Gantt charts, which are, of course,
useful more for planning and task management rather than tracking the
entire progress of the project. That is where our repositories
feature comes into play, as they track the progress of the design
drawings, schematics, models, function maps and BOMs that make up the
core elements of a project. You can use Git, Mercurial, Bazaar, or any
number of repositories in the OpenPario.net interface, and easily
refer to changes via macros. It displays the trunk, version
histories, and all that good stuff. Hopefully we will be able to work
with Bryan to see how SKDB can be leveraged in this interface via GIT.
Again, we are still in the early stages or adapting to engineering
design and are open to input if you like in our features list.
http://openpario.mime.oregonstate.edu:3000/projects/openpario/issues?query_id=24
Also, be aware that we will be moving to a new, upgraded version of
redmine with many more plugins, educational materials, and a CMS
frontend, and will be launching a business model around it; however
all projects will be migrated to the new build as soon as it is
ready. This means that any feature requests you or other folks
interested in developing strong PM tools and practices is crucial
right now. We are interested in working with folks in the Open
Hardware community who are wanting to drive the project management
capacity of the community forward. We gladly welcome any and all
ideas, collaboration, or whatever form of input you and anyone else
can give.
Feel free to just create a project and explore those of others, and
get a feel for the interface. I am currently making a set of
instructional screencasts for Lonny Grafman's ENGR 215 class at
Humboldt State, so folks will be able to puruse those for the time
being until we migrate to the new build.
We are looking into RESTful interfacing with MediaWiki, which means
that anyone who is using MediaWiki in their projects will be able to
integrate OpenPario with their existing wiki.
Richard Schulte
OpenPario
Re.Rooting Collaborative
John Griessen
>
> I think your are less likely to find parallel developments than one
> minimally
> satisfactory path, else someone has worked on something to be abandoned.
>
>
> The crucial missing step here is the merge. Usually parallel development
> happens for a little while, on distinct features or areas of the
> project, followed by a merge back to the mainline.
OK Fine. That's a good FOSS to open HW analogy. I thought somehow you were
thinking of parallel competing branches of development since you said PERT
charts "next to useless". So, I say a tool we HW developers would really use
is a distributed PERT chart with merge methods that trigger many GTD list items to do.
Meanwhile, just any free open PERT chart would be nice and merge by phone calls
and emails then git merges.
John
John Griessen
>> In an OS project, it is critical to
>> reaching the take off point where other people besides the originator
>> are motivated to get involved.
>
> Yes, this is key for any non-market driven, or non-conventionally
> market driven project. Open Source Ecology has been most successful
> when its various projects reach these points.
.
.
.
> Our system allows you to build Gantt charts, which are, of course,
> useful more for planning and task management rather than tracking the
> entire progress of the project. That is where our repositories
> feature comes into play, as they track the progress of the design
> drawings, schematics, models, function maps and BOMs that make up the
> core elements of a project. You can use Git, Mercurial, Bazaar, or any
> number of repositories in the OpenPario.net interface, and easily
> refer to changes via macros. It displays the trunk, version
> histories, and all that good stuff. Hopefully we will be able to work
> with Bryan to see how SKDB can be leveraged in this interface via GIT.
.
.
.
The SKDB link in part could be a good place to show a mechanically
derived task completion metric. Just show characters orlines entered
in the definition files of SKDB and you have a crude metric with no
users having to write anything.
.
.
.
>
> Again, we are still in the early stages or adapting to engineering
> design and are open to input if you like in our features list.
> http://openpario.mime.oregonstate.edu:3000/projects/openpario/issues?query_id=24
.
.
.
Sounds like a wish come true. I'll look into it and contribute ideas/reviews.
.
.
.
We are interested in working with folks in the Open
> Hardware community who are wanting to drive the project management
> capacity of the community forward.
.
.
.
Tell us more about your new business model please.
John Griessen
Leo Dearden
Leo Dearden wrote:
The crucial missing step here is the merge. Usually parallel development happens for a little while, on distinct features or areas of the project, followed by a merge back to the mainline.
I thought somehow you were
thinking of parallel competing branches of development since you said PERT
charts "next to useless".
So, I say a tool we HW developers would really use
is a distributed PERT chart with merge methods that trigger many GTD list items to do.
Meanwhile, just any free open PERT chart would be nice and merge by phone calls
and emails then git merges.
John Griessen
> is a distributed PERT chart with merge methods that trigger many GTD
> list items to do.
>
>
> I don't think I understand. PERT is like GANT but without durations?
> Just a dependency graph?
just a different visual look, where PERT charts have a box for each task
and visually map parallel paths that have a time dependency where they
share a next step. If Gantt is easier GUI to make, OK, I just like the
way the printout shows immediately which sequences are independent of others.
Those are always the ones with opportunity for simplifying/speed-ups.
What are the merge methods? There's no auto tool for it. You have to
resolve due date planned vs. actuals between everyone doing things
and re-spin the chart and make everyone look at it, (and value and understand
cooperative speed)..
I think that once we have a good
> merge tool for each of our major design formats we'll be massively
> better off. Having done a bit of both HW and SW, the lack of merge for
> CAD is bugging the hell out of me.
HeeksCAD, FreeCAD are our only ones I've seen with any chance of loading
open exact models of the smallest amount of part defining data that
comes from design principles. STL surface curve files for a thing designed
as machined solids makes no headway -- it doesn't let you check fit of
separately designed parts.
Check fit is the "merge of separate designs" for
mechanical parts, analogous to "git merge separately designed code functions
where they do not clash", and point out the clashes for human attention.
John
Greg
highlighting the critical path but do not graphically show durations.
Gantt charts are plotted on a time axis, and thus explicitly measure
progress against a timeline. I distinctly mentioned the very important
need for communicating dependencies. My implication of uselessness
has to do with durations, not dependencies, so a PERT chart might be
more useful than a Gantt, in this sense. However, the idea of the
critical path is more complex than simple task durations. One must
account for resource constraints as well, and when the the resources
are volunteers, those constraints are largely way outside the
project's control, and you can't simply throw money at the problem to
assign additional resources like you do in a traditional commercial
project.
That said, I can certainly see John's point, and can envision some
open source scenarios where a timeline IS important. One such such
example is the Team FREDNET project to develop a lunar rover (which is
driven by the GLXP deadlines). Likewise, financial accounting metrics
(like EVM) may be more relevant for some projects than others.
In many cases, however, time lines are purely arbitrary. It is just
not clear to me that it is necessary or even advisable to plan these
in advance and hold volunteers' feet to the fire when it is arbitrary
to start with. Additionally, I come from a critical chain experience,
and have often found explicit time lines to be more harmful than
helpful. When you specify a time line and task durations, it is
amazing how often durations expand to fill the allotted time, even
though every task estimate includes a healthy buffer. It is often much
more effective to just ask people to complete their task as soon as
possible. Time lines in my experience are more for appeasing upper
management than they are a tool for anyone actually doing work on the
project.
I do agree that there should be some incentive/metric for volunteers'
efforts, which should include quality of work as well as timely
results. Inherent to the concept of parallel design is competition as
a motivator. Quite often the design that is mainlined is the one that
is produced first (all else being equal, of course).
On Feb 15, 2:44 pm, Leo Dearden <leo.dear...@googlemail.com> wrote:
John Griessen
> PERT charts are primarily for viewing the dependencies and
> highlighting the critical path but do not graphically show durations.
> Gantt charts are plotted on a time axis, and thus explicitly measure
> progress against a timeline. I distinctly mentioned the very important
> need for communicating dependencies. My implication of uselessness
> has to do with durations, not dependencies, so a PERT chart might be
> more useful than a Gantt, in this sense. However, the idea of the
> critical path is more complex than simple task durations.
OK.
> In many cases, however, time lines are purely arbitrary.
That would be bad.
When you specify a time line and task durations, it is
> amazing how often durations expand to fill the allotted time, even
> though every task estimate includes a healthy buffer.
Oh yes, that's why chart of steps to get to a result with lavish estimates
can tell you the time to get there is too many years. Then you know
you don't need to start, you need to simplify more first.
John