APR: Scope and Vision

To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.

But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now – but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.

These two project management artifacts seem logical to combine into a single article

Vision Document

Create a site that allows people in our niche to help each other find great articles, regardless of who wrote them. People will identify and evaluate (rate/review/score) articles on their merits. People will also categorize (taxonomy/folksonomy) the articles to make it easier for others to find documents that they are looking for at that time. When a person is searching in our space for an article, it is either as a beginner or an expert (on that subtopic). This site should help people filter to look for articles appropriate for the type of search they are doing at that time.

Using the language described in Gene Smith’s Social Software Building Blocks (http://nform.ca/publications/social-software-building-block), we want to focus on sharing and reputation, while incorporating elements of identity, conversations, and relationships. We do not want to focus features on groups or presence. The diagram for our site would therefore look like the following:

Scope

In this project, we talk a lot about “our space” and “our niche.” Our niche is intended to be articles about:

product management

business analysis

requirements definition and management

business rule definition and management

business process modeling

agile processes

interaction design

In terms of functionality, our scope is limited to improving everyone’s ability to find great content in our niche. That might mean making it easy for authors to tell people about articles, but more intentional is the ability for people to highlight great articles for each other. The scope is not intended to provide a mechanism for people to content. People should be able to indicate some assessment of the content – not just an unadorned link to the content. That may mean ratings, reviews, comments, thumbs up/down, etc.

In terms of deployment, this project will be a “self contained website” that is intended to be deployed into a subfolder at Tyner Blain ( http://tynerblain.com/folder/ ). We may elect to deploy it somewhere else (like a subdomain, or a separate TLD).

Hi,
may I suggest to add “help the website’s users in organising their own ‘knowledge repository'” to the vision.
I don’t find a better word for this. I don’t think of something non-public. An individual user should not just contribute for the sake of others (like suggesting a great article, which means he has alread read it), but should also be able to use it personally. I have no idea how to do it, but that’s a good thing when talking about visions :-)
I am aware that the community does something for the individual, and that the individual is part of the community. Some parallel could be del.icio.us, were the user benefits from his own favorites, as well as from other people’s favorites.

Another thought to include or explicitly exclude from scope: “Collaborate with other users for achieving an individual goal”, with goal meaning something like an industry project. Maybe this is already excluded by the idea that users do things on the site for all other users, and with the help of all other users.

On “knowledge repostitory management” – it is a tough one. Del.icio.us, as you point out, is a pretty great tool for doing that right now. I don’t think we would have a lot of success if we asked people to duplicate what they already do there. That leaves two choices – either try and supplant delicious as the “organizational tool”, or find a way to leverage/augment/mashup with delicious so that people can use delicious as their primary tool, and achieve some benefit here.

Personally, I would want to keep using delicious, because I also organize other stuff as part of my “Sehlhorst Body of Knowledge” [SBoK :)]. And much of that doesn’t apply to our space. It might be CSS styling or Ruby on Rails programming techniques, or road-biking articles, or great recipes.

And with that need happily sated, I wouldn’t want to split it out so that I have separate repositories for my SBoK. What I do want to do is to be able to leverage the SBoK work I do at delicious (when appropriate) to help everyone else on this site.

So I would categorize the approach as “leverage existing BoK tools to make it easy to share relevant content with the community.” I think that falls under the current “broad vision” statement, and would ask you to make sure I don’t forget about this as part of the use cases we define. Then we can prioritize the approach.

Another way someone might do this is to create a personal wiki, and link to the articles that they like and find through the site. We may be able to find a way to make that easier too – but I think of it as a “second order problem” right now. I do want to use the feedback from everyone here to prioritize this approach properly – if it is more important then we will definitely tackle it.

“collaborate to achieve a goal” – tough one.
First, I intended to stress “goal”.
I thought of APR as an endeavor to help people in our niche “in general”, i.e. NOT something like ProjectSpace or TeamSpace where people share a space that supports project work. Maybe “non-project” is the right track. Of course people share knowledge for and collaborate in achieving their goals – which includes projects, but they do not connect or collaborate using APR to do a (commercial) project.
IOW, APR should (also) be used like tyner blain is used now, as a set of knowledge units for our niche, not for a specific purpose with one or more goals to achieve by date x. (in my head that is a characteristic of a commercial project: achieve goal x in time y).
To make a long story short I suggest to EXCLUDE approaches like ProjectSpace or TeamSpace from the APR scope.

Product Management Today

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!