Big Goals in Bite Size Bits

I was in a long discussion yesterday with some peers about this subject. In general, few organizations that I work with, most of which are under a core of 25 or so staff people, produce data apckages with processes that require more than a few total steps while including a couple of iterated steps.

Document (Artifact) Creation Process:

1. Initial Proposal Draft
2. Proposal Review (Version Control) (Some Group Permissions/Roles/Control here)
3. Proposal Update (IIterate from "2" - Review) (Change Review Group)
4. Proposal Decision (Often New Group Permissions/Roles/Control here)

Then:

1. Initial Implementation Draft
2. Implementation Review (Version Control) (Some Group Permissions/Roles/Control here)
3. Implementation Update (Iterate from "2" - Review) (Change Review Group)
4. Final Implementation (Often New Group Permissions/Roles/Control here)

A lot can be added to this, but generally speaking, what I have found in my work is that without clear guidelines from the first set, and sustainable resourcing for the second, things don't get done.

Also, from my experience, the actual 'density' or capability+resilience of a group/organization/individual/(entity) is the total strength of these processes as the backbone of the entity in concert with the use of technology for scale effect.

As an excercise, I will offer to you what I offer to a host of my clients: if we focus on doing something really really well, and the processes that underlie successful, replicable execution of an operation, then replicate the process so as to execute on an expanded operation, another that we really, really well, we will succeed and stay focused without becoming spread too thin. In fact, most of the successful folks I work with have started to look at the entity functions as 'campaigns' for this reason. Campaign meaning the true definition of a 'project,' from the "Project Management Body of Knowledge" book, " A Project is a temporary endeavour undertaken to create a unique product or service." A "campaign" definition adds in, I believe, the social aspect, saying in effect, that the project contains some amount of exposure and interaction with or expectation from the public/market/"outside"/non-"i" entity. The unique product or service then becomes a component of 'operations' which are distinct from projects because they are ongoing and part of the transcendant mission and prupose of the organization.So, an entity has a buildout something like the following.

Entity Buildout Process:

1. Definition of general mission and vision with outline of Targeted Operations and Projects in process to achieve them.
2. Outline of initial (1st) unique service or operation to be achieved (and operationalized)
3. Project plan to accomplish unique operation's repeateable performance (operationalization)
4. Execution of Project

Then:

1. New definition of Mission and Vision to include new operations and new Project Directions
2. Iterate from "2" above

These may seem simple, but agreement on the simple structures leads to the ability to make more complex ones.

I would not recommend needless complication of these, but instead move forward with simply "filling out the form" and and on into project fulfillment which leads to expanded operations. Right now, accomplishing massive amounts of work on a website will not 'solve' anything, but having some clear expectations on which usable pieces will need to be built into the first project so that everyone can feel like saying
"Hey, we have executed our project project, and now we have an operation we are committed to fulfilling on regularly (daily, weekly), this is happening, let's invite others in and maintain focus on our next project which will expand our operations."
Isn't what what we are looking for, anyways?  Why not focus on what we want to happen, then?