The syntax that I am introducing is just by way of example, in order to explain the logic. It shouldn’t be difficult to modify this for the Tent architecture that Tav is proposing and I see this aspect of the overall proposal as completely consistent with Tent as it simply provides some guidance on how to talk about a certain domain – projects and collaboration.

The structure that I am proposing is particularly ideal for bringing disparate projects together that are currently working in isolation, or without sufficient awareness of, similar projects.

I recognize that in reality most organizations don’t think clearly about what their super ordinate goals are, and the relationship between their super-ordinate goals and their sub-ordinate goals are and so on. This will obviously be an inhibitor to getting this sort of process of the ground.

That said, it wasn’t really very long ago that the idea of a ‘status update’ was something that no one had heard of. We now regular update statuses, tweet etc. The reason that we do this is that we have come to realize the utility of such practices.

I maintain that, even if there resistance to getting people and organizations to think in terms of their super-ordinate goals, and the actual relationship between what they are doing today and those goals, spending time on this will be time well spent.

Tent is, in its essence, an open discussion space that gives users maximum flexibility in terms of how to talk about things.

My proposal is that we give the community some guidance on how to talk about things; that we take a stand and say that collaboration is a good thing.

What is my justification for this? Well, lets just say that the status quo is not working. People left to their own devices to operate within the parameters of existing institutional structure is what has resulted in leaving us in the condition that we are in the first place.

There is nothing wrong with being leaders! – suggesting that there is a better way.

Tav says:

”I'm a believer in leading by example. And, at least within various
communities I've been part of, have found this to be very effective.

If you both do *and* promote elements/conventions/approaches which are
easy for others to pick up and make reasonable sense, then generally
I've found that others tend to follow with enthusiasm...

And thus with Tent. I'd personally be using the "types" that made
sense to me -- and this would naturally flow and evolve with what
others are doing...”

I see this as merely an extension of this idea.

SUPER_ORDINATE GOALS

What is a super-ordinate goal? The highest, most inclusive, goal of the project?

Note: A project can only have one super-ordinate goal, but the way that it is stated can have many different translations.

Super-Ordinate Goals: "Changing the World for the Better"

Suggested Syntax: OK.SUP: Changing the World for the Better

Potential Translations: 'Making the world a better place', 'Changing the World!', Fixing the World' etc. 

Assessing translation equivalence and proximities is something that we will have to address at a later date. Clearly in trying to identify organizations with super-ordinate goals that are related, we need to do more than just test for key word equivalence. 

I would suggest that, at some time in the future, what we want to do is to use certain semantic mechanisms to establish proximity relations between statements about goals. This is not a problem for today...

SUB-ORDINATE GOALS

What is a sub-ordinate goal? A goal that is a project needs to achieve in order to achieve the super-ordinate goal. In most cases, I would expect, the satisfaction of sub-ordinate goals will be temporally prior to the satisfaction super-ordinate goals.

OK Sub-Ordinate Goals:

Level I: 'Catalyzing Strategic Confluence'

Suggested Syntax: OK.SUB.1: Catalyzing Strategic Confluence

Leval II: 'Developing a Community of Practice to Support Catalyzing Strategic Confluence'

Suggested Syntax :OK.SUB.2.1: [Developing a Community of Practice]_OK.SUB.1

This makes explicit the particular level I subordinate goal to which this level 2 subordinate goal is linked.

Level II: 'Developing a Technology Platform to Support Catalyzing Strategic Confluence'

Suggested Syntax: OK.SUB.2.2: [Developing a Technology Platform]_OK.SUB.1

Level II: 'Developing Collaborative Processes to Support Catalyzing Strategic Confluence'

Suggested Syntax: OK.SUB.2.3: [Developing Collaborative Processes]_OK.SUB.1

Level III: 'Collecting Information on Projects'

Suggested Syntax: OK.SUB.3: [Collective Information on Projects]_{[OK.SUB.2.1]*[OK.SUB.2.3]}

The above suggests that collecting information on projects is linked to both OK.SUB.2.1 and OK.SUB.2.2

The Relationship Between Syntax and Project Documentation

What I am envisioning is that a particular Sub-Ordinate goal will be linked to a particular structure that will show how this goal can actually be accomplished; in our language, it will link to some basic project management variables. To be precise, it will link to a series of tasks, a timeline and an identification of who is responsible.

For example, lets consider OK.SUB.2.2: 'Developing a Technology Platform to Support Catalyzing Strategic Confluence'. This would be associated with the following project structure:

·         Project Leader

·         Project Team

·         Completion Date

·         Project Milestones

·         Project Management Structure:

·         Project Communication Structure:

So we would need a system that would allow someone to input: OK.SUB.2.2, which would generate the above structure with a bunch of information.

Others then would have visibility into what we are trying to accomplish and would have the option of joining the project, linking their project to our project etc.

Note: in this view of things, a sub-ordinate goal just is a project – a sub-project of a larger picture

So why do we want to structure information in this manner? I suppose that there are two reasons:

1. Again, I am envisioning an infrastructure that can bring together lots of projects that are operating across the world in different environments, with different local mandates, little communication to this point with other groups and so on.
2. The project management details being included within the system forces creates a culture of accountability, focus and action. The structure forces us, for example, to identify who the leader of the OK software development project is, what the team will look like, what the milestones are etc.

I believe that both of the above are necessary for effective execution, and effective execution is what is necessary if we want to move from a stage of merely dreaming about things to actually effecting change.

Thoughts?