Most of us do not know what need is driving our emotions. This makes it all too easy for us to react to our emotional state with strategies that don't fulfill our needs. The need remains unfilled, the emotions remain, mysterious, haunting, implacable.
The idea here, though, is to get really good at identifiying needs, personal needs, project needs, community needs. How? At first, by looking for them deep below unpleasant emotions. One method involves studying a typical needs list and finding those that best describe you in the moment. Then you think of a strategy for fulfilling that need. Imagine that eventually all of us get really good at identifying needs and at satisfying them.
As a project team or as a community, describing and fulfilling needs is what the following is about.
Throughout the lifetime of building anything, needs arise and are fulfilled. A need is something missing. It has a description and a condition of satisfaction. By amassing all the needs of a project, anyone can quickly come to understand its thrust and status.
A need has two owners: the spokesperson and the fulfillment team. Anyone or any team can select a need, promising to fulfill it. A need can be worked on in a variety of ways. It can be assessed for (and committed according to) time and broken down into sub-needs, resources, and milestones. Progress, designs, decisions, and other activities can be reported within a need. Each of these will be date stamped, including duration.
The team signs a promise to fulfill the need. The team works out the actions and work details which fulfill the need. Agile tasks are included.
When a need is fulfilled, it becomes part of the current state of play. The need is then displayed as a completed component, with a description of how it is to be used. This allows the project to retain an audit trail from initial needs to final documentation. The tags and dependencies created along the way are retained, and can be expanded to account for ongoing improvements, and newly emerging needs.
Search strings let users locate needs by matching them against description. Tags (aka categories) can be added to needs, as many as are deemed appropriate. These tags are used by the search facility to shrink the number of matches shown and presented for this purpose in a multiple-choice list. Tags are managed separately, made available when creating a need, and can be easily expanded with a need-new-tag function. The importance (payoff, urgency or priority) of each need is another searchable facet. It’s a rough estimate of how much value will accrue from fulfilling the need. Other search parameters can be easily added as we desire. Some tags that come to mind:
Dependencies between needs can be presented as a graph, like a mind map. Owned needs will also show a duration and due date, which will be summed over owned sub-needs.
Another approach to dependencies is an outline view where subordinate needs can be optionally made invisible. Any single need can be viewed in isolation (containing needs can be optionally made invisible). Needs can be reordered or moved about or edited. Completed needs can be optionally made invisible.
The fulfiller of a need promises to satisfy the conditions expressed by the stakeholder, specifying a timeframe. Agile philosophy allows surprises to arise and be dealt with, mitigating surprises and avoiding catastrophes. Stakeholders should to be informed about and involved in dealing with these surprises. This ripples out into and through all dependent needs.
The usual harsh judgement which accompanies surprises is not as useful as analyzing the causes of those surprises. Unclear conditions of satisfaction, inadequate planning or communication, mismatch of owner’s skillset. Careful integration of such analysis back into the process of needs management will help us grow our overall team strength.
Ranking the performance of the fulfiller in terms of quality, timeliness, communication, and perhaps other things can help the owner improve and help future stakeholders of other needs decline or accept an offer. However, we want to avoid blacklisting and to promote second chances. Perhaps when an owner receives a low ranking, they can cite it and add a declaration of intent to improve, indicating awareness and desire.
The person who authors a need is its stakeholder and recipient. Alternatively, the author can submit the need on behalf of someone else, and that other person is the stakeholder. Any negotiations, requests for information, assessment of completion and of the owner’s accountability are to be directed to / performed by the stakeholder.
Let’s say that the effort of meeting the conditions of satisfaction are discovered to be impractical. The stakeholder can choose to cancel the need or restate its conditions of satisfaction.
Doing this kind of back and forth with care and vigor allows us to be agile without sacrificing reliability and accountability. Perhaps the mechanism is a combination of email and chat room, both of which are recorded in the need.
The minimum requirement for a new need is title and stakeholder. I personally prefer to add new needs directly into the dependency graph. Why? For one, this eliminates the high friction of filling out an unfamiliar and potentially lengthy form.
The rest can be filled in or updated at any time in a form or a separate view. The stakeholder is usually the person creating the need, so that is the default and can be changed at any time.
Four tables (and their schemas) come to mind:
Some (obvious?) first needs:
At minimum, six views will give us a lot, perhaps delivered in the following order:
As for item 1 ... Autogenerate needs on the fly during chat. We could incorporate a way to add needs from a chat. (:need: as a keyword to auto create a new need with a title and stakeholder) into a holding area from which they can be cherry picked
As for item 2 ... The minimum requirement for a new need is title and stakeholder. I personally prefer to add new needs directly into the dependency graph. Why? For one, this eliminates the high friction of filling out an unfamiliar and potentially lengthy form. The rest can be filled in or updated at any time in a form or a separate view. The stakeholder is usually the person creating the need, so that is the default and can be changed at any time.
All of us working together to operationalize the Meta Project are gradually meeting people and learning from them, collaborating with them. Some of us, however have ideas that have stalled for lack of something (guidance, funding, knowledge, skill). For such folks, would it make sense to provide a repository of personal needs?
The synopsis board can present has been recently accomplished across all the actively pursued needs?