problem analysis

The time spent thinking about a problem can help prevent assumptions and myths from driving action. Assuming that only Republicans are imperialist may drive excessive backing of hawks in the Democratic Party, for example.

Sometimes people doing analysis become detached from deadlines and the needs for clarity and eventual action. Their reports and suggestions may be so complex and abstract that few people take the time to understand them. It is also possible to spend so much energy on analysis that deadlines, budgets, and morale become endangered.

solution analysis

This is where the wildest brainstorming is likely. Many suggestions will often come up, with only a portion being valuable or practical. A little time, and possible experimentation, may be needed to finalize a direction.

design

In the case of a grass roots campaign there will need to be outlines of main points to communicate, team building, resources to buy or lease, skills to develop, and training.

Planning detached from the real world difficulties a project will face is sometimes termed "armchair design." This can cause effort to be wasted downstream. Poor planning may make the actual workers resent the organizers, so some planning should usually be attempted. Effective planning keeps morale high.

Some people like and expect high quality, thorough planning while others like to start the implementation phase as soon as possible. Sometimes it may be best to limit planning in favor of starting the "real work" early. This can give a team quick feedback.

Whatever level of design goes into a project, disagreement should be anticipated. (Even if people agree on a level of design initially, there is a tendency to blame planners for mistakes later.)

requirements

Requirements can be a contract between people. Someone who commits to do something knows that the work is defined. A good definition means that there is objective criteria for judging project contributions. Without written requirements anybody can be blamed for problems, and there is no limit to what a person can be told they are responsible for doing.

Some projects use minimal requirements while others specify a high granularity of detail.

implementation

In some contexts implementation may mean putting into practice a new methodology, so vocabulary will not be precise from one environment to the next. In software projects the term implementation usually refers to the programming/coding itself.

When there are goal other other upstream changes the effects at the implementation level may be painful. If learning drives the changes than there can be team appreciation. If the changes seem arbitrary, excessively disruptive, or risky with respect to deadlines, morale may suffer greatly.

testing

Testing should not be dropped under deadline pressure unless time is truly exhausted. The quality and long-term health of a project often depend upon strong-willed people enforcing minimum standards. If upper management sidelines quality checking on a complex project there is a high chance of problems.

Of course the people performing checks should not be arrogant or prone to back-stabbing. This can hurt morale greatly. Quality targets should be set for a project so that perfectionists do not hold up a release without reason.

Experts and excessively energetic people often need to be managed so that they do not interfere with work when it is being completed. Some people tend to request or demand major changes once everyone else is satisfied (and exhausted). Simple checks of work products should not grow into design reviews. Everyone should have a commitment to both quality and deadlines.

prototype

If there are major misunderstandings then a functioning prototype can often reveal them.

There can be friction as to whether or not a prototype should be shown publicly or not. The project managers and an external audience needs to be told clearly (and repeatedly) that a prototype is not the final product.

processes

People don't like the idea of a process initially but after having work lost because of project chaos they are often happy to adopt some rules.

Many steps in an activity require experimentation and problem solving. Often a process is only a best guess at a valid method of performing some activity. Processes should not be considered magic.

release management

Quality checking is a key portion of this work. There should be criteria for release based upon quality. Also, formal approvals from people in an organization should be required for a release.

Distributing a product can require considerable work. A major book may be released in multiple languages, for example. Keeping the content in sync requires a lot of care. Large, mature organizations usually have teams devoted just to release management.

training

In real life training is often informal, using reference material and current work. This is can be enough in some environments, especially when there is good documentation.

Training won't make everyone an expert on a subject of course. Experience and study are needed to develop.

documentation

Critical documents often require formal reviews and version control. Software tools can help with the latter, but don't eliminate the need for discussion and approval when documents are critical.

Often documentation is generated in bursts of energy with no follow-up. Do documents have potential readers? Will the documents be valuable over the long-term? Where do documents overlap? How much time should go into maintenance? If not planned, documents can be wastes of time. Out-dated documents can cause mistakes and friction. (Sometimes a loose cannon will follow something more than common sense.)

constraint

An activism example is that a certain businesses could be excluded from a project because the businesses have unethical practices or do not have unions. This could be driven both by idealism as well as the need to maintain good publicity.

Constraints should be identified early. Because they often impede work they should be justifiable and subject to discussion, like any other part of a project.

post mortem