Exploring Organizational Crowdsourcing

Originally written as a guest post on chaordix.com.
I often sit back (usually over coffee) and think about where crowdsourcing and collaboration is heading. It’s an fascinating exercise, coming up with different scenarios and expanding them out to see if and how it would work. My latest mental exploration has been about the concept of organizational crowdsourcing.
Most crowdsourcing is currently structured around the task, a production-oriented model. The community is given something to do and they do it. I want to design a logo. I want to analyze this data. I want to test this software. I want to provide customer support. But what if this was expanded into a process-oriented model where organizational structures in various forms move into the global community? For example, a structure (on the agency side) may look like this:
1. Project Owner(s) – Define the strategy to meet the project’s goals.
2. Project Manager(s) – Break down the strategy into specific steps and milestones. Assign particular tasks to various teams. Document the project’s status.
3. Team Leaders – Divide and delegate the team’s responsibilities to individual member types. Review requirements and submissions.
4. Team Members – Work on delegated task(s).
At each level, the work produced moves up and down the organizational chart for requirements, reviews, clarifications, etc. There also may or may not be an equivalent role on the client’s side, so the community would also step in to fill those gaps.
Now, I’m not proposing that members report to each other based on their overall job role like an employee to a manager, but base it on the specific role and project task. I don’t think anyone wants to transfer distracting political business environments onto the crowd, but what if we implement a process that enables a true strategy and delivery to be achieved through crowdsourcing?
I’m also not proposing that we broaden the scope of the tasks we give to the crowd. It’s been shown that crowdsourcing is more successful when the community is given smaller, more defined assignments instead of generalized broad goals. So thinking in terms of the organization, the tasks would just be defined for each particular role.
So how could this be implemented? I think a few things need to happen:
1. Members
Member types would no longer be defined by only skill set, but also by responsibility, experience, reliability and job role. This is also followed by more scrutiny and validation of these participants and less based on an open registration format.
2. Teams
Sub-groups of the community are created along with the infrastructure to handle the team dynamics. This is not an easy task. In-person teams tend to develop their own dynamics and virtual teams add another level of complexity. Include the third layer of the crowd and you have an interesting challenge.
3. Projects
The structuring of projects should be looked at with fresh eyes. Not in the fact that traditional project planning is ineffective. Just the opposite. Projects should be arranged into types or templates so their integrity is not at risk by putting them out to the crowd. Yes, every project is different, but how the community engages each project should be similar.
4. Clients
Clients would need to shift their mindset into understanding that not only the production tasks are done through the community, but strategy and planning as well. This may be more difficult to initially accept since some or all the ownership and direction of a project is resting with the crowd. Obviously the ultimate responsibility is still on the crowdsourcing firm and the client, but each project would have a certain level of crowd vs company engagement.
5. Communication
Communication between the community members at all levels as well as between the members and the company should be the utmost priority. An online environment would need to be created and nurtured that encourages this communication and openness. As with traditional structures, it’s an essential component to getting a project done successfully and maintaining a happy, productive work environment.
6. Technology
Web applications currently being used for competition, collaboration and communication would need to be upgraded to handle the more complex interactions between the individual members in all roles as well as inner-team and inter-team dynamics.
7. User Experience
The design and user interface, like technology, should also be updated to maintain and enhance the overall user experience of the competition, collaboration and communication. However, while the technology may get more complex, the user experience should become even simpler and more transparent. The users shouldn’t be aware of the increasing number of moving parts behind the scenes.
Of course, there are benefits and drawbacks to this idea as there are with all ideas. And it’s certainly a big leap from most organizational models, but I think it could be beneficial in some cases. What do you think? Should we expand the idea or go back to the drawing board? Call it a day or get more coffee?
Comment and let’s discuss.
Photo by: llawliet



25. Mar, 2010 
Author Info