De facto leaders have emerged, who though well intentioned, may not always operate transparently or respect the work of volunteer teams. The Work Flow chart below uses the instance of a User Experience (UX) team creating a product, including a process for change management and testing, which is currently lacking. Please comment about how this incomplete chart can be improved and how we can establish “best practices” for project management in a horizontal movement. We are also working on a description of process design patterns and anti-patterns to abstract this issue into documentation that can help to address what is currently being seen as an issue that is affecting many working groups.
Internet
A Working Group of the NYC General Assembly #OccupyWallStreet
This is way too much a flow-chart. Flow-Charts are DEAD. (A moment of silence please…). Improve this by adding an time axis straight out of the page at your nose. I’m saying issues are coming directly at you without respect to a neat flow diagram.
Agreements are always messy, dirty, disorganized, unscheduled, and unexpected. The change needed here is to include that list in the chart. Anything can change at any time. For example, start the deployment at the beginning. Revise that as it happens.
Results are not consensus. Results are a shared understanding to what is needed and what can be accomplished.
I agree. This flow chart is hierarchical. You are too focused on leadership being at the top. Many of the problems in our society stem from top-down organization.
There is another type of organizational strategy: Open Space Technology. It was designed in part by Harrison Owen. You can read about OTS here: http://www.openspaceworld.org/
“Open Space Technology is a simple way to run productive meetings, for five to 2000+ people, and a powerful way to lead any kind of organization, in everyday practice and extraordinary change.”
I have experienced it’s power in a group of 200 people. Over a one week period we accomplished more than any other professional development experience I’ve attended. Not only did I learn, I led.
I hope this is helpful.
looks great to me but it’s only the second half.
first half:
Need arises within a group for a technical solution.
Tech Ops articulate need.
Tech Ops identify and evaluate possible solutions.
Tech Ops present possibilities the group with the need.
Group direct Tech Ops to move forward with deployment.
Project manager is recruited….>
Question – isn’t most technical project management “non-transparent?” When does this get moved to a sign-up sheet for discreet tasks and a timeline? What’s wrong with the current site? Isn’t it being moved to drupal? thanks!
The current site and any future development would benefit greatly from a better process. An example of a process that would benefit from a fix is the manner in which the choice was made for the blue color for the donate button. The blue color was chosen by an individual, not the user experience team. The analytics shows that Donations (Event Tracking traffic outbound to wepay) was down 70% comparing the week of Nov. 6th to the Week of Oct. 23rd. Correlation does not imply causality, so those events may not be causally related and it could have been coincidence. A/B or multivariate testing can tease out causal relationships in a scientific manner. NOTE: The process is totally independent of whether Drupal or any other platform or development environment is being used.
“Activist Movements are based on ACTION and CLEARLY DEFINED GOALS.
Without one or the other, you merely have a mob”.
(—.former OWS activist 10/25/11)
jay
Was this proposal the result of consensus amongst the UX Group? Or just a subset of individuals in that group?
If you read the minutes from the meeting, I think you will agree that there was consensus among the group. If you doubt the minutes, you should direct message or talk in person to UX team members identified in the minutes or reachable through this list: http://internet.nycga.net/teams/user-experience/
I like that we are moving on this. I have a hard time wrapping my head around this stuff, as the idea iterates can we develop some real life examples and also frame it in the current structure of how we work (no set meeting places, etc.)
Also, I think there is a big need for documenting everything! wiki.occupy.net is a good start, though the structure is really up in the air. It’s a time sink to have to keep getting people up to speed.
I appreciate the unfolding process questions technical operators have and their attempts to address the process. Group technical problems seem the same as any group problem – there is a lot of exploration that leads to understanding of what needs to be tried and then steps are taken to explore further.
We are always prepared to improve based on clarifying emerging needs. While any group or sub groups may have consensus about what direction to take, it still remains with the General Assembly and Spokes Council to facilitate larger decisions that effect the whole and benefit the whole of the Occupy Wall Street movement.
Please note that the primary purpose of this flow chart was to provide a basis for a conversation about process. Some have offered criticism of the flow chart being too hierarchical or that the flow chart implies the existence of resources we do not have. The purpose of examining process is to improve upon what can be done with limited resources. Besides creating a basis for conversation, the flow chart is an attempt to provide guidelines (not rigid rules). Common sense should always be applied in decision making.
PRODUCT MANAGER PRIORITIZES ISSUES FOR CURRENT SPRINT
(first box at the top of the chart)
Please think of the “Product Manager” as attempting to organize information and make it more accessible to both developers and users of the system. In our current situation you cannot and should not be “ordering” unpaid volunteer developers to do certain things.
The current “Sprint” is a term from Agile project management. At the beginning of a Sprint, the team should reach consensus about priorities and reduce requirements churn by not letting other requests change the focus during the Sprint. The “Pivotal Tracker” tool being used helps to separate “Current” from “Backlog.” See: https://www.pivotaltracker.com/projects/399421 In addition to this, a team should have a meeting to discuss what belongs inside “Current” otherwise anybody with access can be adding to the “Current” list resulting in scope creep or requirements churn. The role of the Product (or Project) manager should be to help keep the team focused on a small set of problems that are possible to address in a short period of time (Sprint). This is a philosophy of getting more done by doing less (at any one time). By producing a “static” document with a date for the current Sprint, a Product Manager could help to make it more obvious as to whether scope creep or requirements churn is taking place.
Finally, this is not intended as a complaint against anybody who is currently working or trying to help. Many are already doing their best to implement the processes described here. My goal is to help communicate these ideas for discussion among the people doing the work so they we can all coordinate more smoothly with each other. I sincerely apologize to anyone who has felt their work criticized by any previous posts I have made. I do believe that if we are to succeed as a movement, that we must be able to discuss process. If feelings are hurt by this, then we must make attempts to reach out on a personal level to insure solidarity. To that end, I think we should consider some regular “social get together” events, where we can meet as people.