Project Flow

From Sam on Project Management:

Marcin, I think you should start with what is most important for you, and anyone actually doing work right now with you.

We can start out with what we know, which I think is the 7 fields that you have in Design Template.

The best way to get to a working system is to create a focused discussion that is limited to just the people who are currently doing work. This could include Vinay and Appropedia folks, too, if you think it couyld be fruitful.

You want to discuss the 7 items:

1. Design 2. Fabrication 3. OSE Specification pieces like scalability, modularity, interconnectivity 4. Ecological integration 5. Economics 6. Collaboration process 7. Open engineering tools.

One at a time with these folks. Then summarize the discussion.

Different projects will contain different actual data and info in the template.

I say stick with this scope for now:

1. Design 2. Fabrication 3. OSE Specification pieces like scalability, modularity, interconnectivity 4. Ecological integration 5. Economics 6. Collaboration process 7. Open engineering tools...

And, realize that you can fill in the template in any order (I think! (?) ) for the most part.

You can use "scrum" style sessions to speed up discussion. Conference calls, IRC chat sessions, or face to face meetings on a bi-weekly basis with project teams.

Each part of 1. Design 2. Fabrication 3. OSE Specification pieces like scalability, modularity, interconnectivity 4. Ecological integration 5. Economics 6. Collaboration process 7. Open engineering tools...

...can have a bunch of "stories" which constitute tasks/goals

So, design can have "create sketches, research design, create 3D models" or whatever the process and artifacts of design are.

Let's work our way through this in an "agile" way. Your template can become a "package", a release. I can make the tools to package this stuff in distributed ways. But, you need an agile project management approach to flesh what is in the "packages".

So, that means getting the team of people responsible for a project together, and having a 2-3 hour meeting and discussing what is going to be in iteration 1 of the project package, what is going to be in iteration 2, etc

This is a more realistic way to approach what you are trying to do than the "waterfall" method, where you try to map out everything ahead of time into one big master plan, then try to execute it.

The agile process works kind of like what you see here: http://socialsynergyweb.org/projectflow/ in that diagram

But, in your case, I think for each project you want to:

  1. Identify the scope and goal of the project
  2. Identify who all will be involved, and who the current development is really for (this is the equivalent of "roles" in software development)
  3. Write descriptions of what needs to be done, and discuss those among the team that will be doing it.
  4. Make an estimate of about how much time, and resources it will take to do each description
  5. prioritize what order you will do the descriptions in
  6. Create iterations based on finishing groups of descriptions
  7. Do the work, and anything new that is added in goes through steps 1-6 above

Step 3 above can easily be http://openfarmtech.org/index.php?title=Development_Work_Template

Actually the above is very similar to http://openfarmtech.org/index.php?title=Development_Work_Template

Each project needs a project manager. Someone who can facilitate the process, hold meetings, keep things on track, be the go-to person for people who want to join the project.

By each project, I mean each identifiable component of the GVCS. I think you have a very clear process with http://openfarmtech.org/index.php?title=Development_Work_Template but it will take hands on guidance to get people to do it