Goal

  • Document the organizational project management process milestones of a product designed in the community, so that it can be re-used for other products, and so we can learn from it.

Process

Note: Unimportant details may be removed in the end; until then every milestone matters.

  • 2011-09: Drupal Blog [deleted] installation profile is initiated as simple idea and response to the equivalent example in the Choose your Drupal mockup.

    Required to kick-start the vision.

  • 2011-10: Lots of talk and discussions (days in total) happen offline, at DrupalCamps, in skype/conference calls, issues, on blog posts, and in IRC, arguing back and forth about the usefulness of a "blog", and whether there isn't a more generic but also more unique/concrete use-case we can attack.

    Required to communicate and get feedback on the underlying idea (kinda off-topic for Portfolio) from the community, but also to drive thoughts, opinions, and participation in Portfolio itself.

  • 2011-11: #1340426: Project shortname (and objective...) settles on a first, very rough, combined scope and target audience resulting out of the discussions, i.e., initial design parameters, in order to figure out a project handle, title, and shortname.

    Required to set up the actual installation profile project on d.o (technical constraints), but also to have a clear topic for conversations, and of course, to spread the word.

  • 2011-12: Portfolio is "formally" announced to the Drupal community at glance in a blog post explaining the ideas and reasoning behind it.

    Required to draw more attention on the initiative and looping in "outsiders" who'd neither know nor actively contribute otherwise.

  • 2011-12: The drupal_blog sandbox project is deleted.
  • 2011-12: One of Drupal core's Usability team leads, Roy Scholten (yoroy), joins the project, has a shared vision and interest, and starts to provide professional guidance on initial and fundamental product design processes and topics.

    Lessons learned: An experienced and prolific designer who's able to work "in the open" is absolutely essential for getting the product design process right.

  • 2011-12: Everyone collects and writes up many individual use-cases, which are very different, but still in line with the main scope and design parameters.

    Required to validate the initial scope and design parameters, to slowly start to find a common denominator in terms of functionality, and most importantly, to describe actual user expectations in simple, non-technical, human speech.

  • 2012-01: Use-cases have been written down, but nothing happens. Project is stuck on primary maintainer being busy with other things.
  • 2012-02: Project is stuck on primary maintainer being busy with other things.
  • 2012-03: Portfolio sprint: Analyze use-cases to distill actual functionality.

    Required to unblock the project. Analyzing the use-cases didn't work out online/remotely. Too much conception, brainstorming, and product design work involved.

    Sprint goals:

    1. Design and definition of matrix criteria (together).
    2. Analysis and conversion of use-cases into the matrix (possibly in teams/working groups).
    3. If time permits, evaluation of results and definition of the common denominator of all use-cases.

    Sprint agenda:

    1. 1h: Short introduction to Portfolio; the cause, goals, surrounding conditions, procedure, past and upcoming work.

      Mainly #1260214: Choose your Drupal and #1340426: Project shortname (and objective...).

    2. 2h: Discussing sprint attendees confusion on high-level scope, Drupal core and drupal.org constraints, what we actually want to build and what not.

      Results summarized in #1488250: Portfolio manifesto // design parameters.

    3. 1h: Discussing best way to perform the analysis and document the result. Digital mindmap vs. spreadsheet matrix. Spreadsheet matrix wins after looking at an early prototype and reading an example use-case.
    4. 5h: Distilling a first use-case with all sprint attendees to extract and formulate actual functionality contained therein. Based on the original use-case write-up. Explicitly also noting functionality that we do NOT see for the use-case. Brainstorming and discussing functionality beyond the use-case write-up, which was either implicitly expected by the author, or explicitly raised as a modern/add-on idea while discussing the use-case. Trying hard to ignore technical implementation details. Slowly filling up the spreadsheet matrix with functionality rows/vectors. In general, the use-case is discussed as if it was a regular RFP filed against a Drupal shop and as if consultants were evaluating how to build a fancy site for it. Different procedures for approaching that task are getting obvious (which is interesting and good), and they hinder progress because everyone thinks from a different perspective (which is bad). But getting to a nice list of functionalities in the end.
    5. 2h: Quickly testing the functionality list in the spreadsheet matrix against a second use-case. Works. A couple of different results, of course. Also revealing some functionality we overlooked before.

    Results in #1399188: Analyze common functionality and content requirements of use-cases

  • 2012-04: Seeking for a project manager to help push the project forward.

    Little/no results thus far. Project managers don't want to get involved with actual volunteer work in the Drupal community?

  • 2012-05: Analysis of common functionality and content requirements of use-cases finally completed.

    Lessons learned: It's very hard to gain interest in early product design work and discussions. The process would most probably have worked better if there was a dedicated person who had posted frequent (but not leading or opinionated) follow-ups on all issues, in order to signify that opinions are welcome and to drive discussions and contributions.

    The Portfolio sprint in March showed already that people have a hard time to understand what Portfolio is and how to have and do the required discussions in the first place (i.e., mainly organizational and communication issues). Thus, the lack of "traction" likely was the root cause for making slow progress.

  • ... today is today. You contribute today!

[Summary will be updated along the way.]

Additional resources