Planning - goals and missions

On the surface it may look like a modern pirate vessel or a fishing boat just crashes out to the sea and grabs whatever happens to be in sight. I am sure some of them may operate that way, but not for long - as any voyager knows, there must be a goal and a plan of sorts. This is not that different from other projects, but the possible outcomes are so clearly different in scale that it is useful to consider event he smaller teams.

Imagine you are a small-time bandit somewhere on the coasts without effective regimes, be it corsairs in North Africa before crusades, Christians a little later, or possibly a team in Somalia.To go to sea, you must have a boat, and a crew willing to follow you - and a crew wants to have an idea of what is to gain, and what are the risks. Notably, everyone wants to come back to dry land, so you need to have a solid boat, and your team better know how seamanship. A successful venture requires seasoned hands, and only so many greenhorns can be accommodated.

The gain - the mission, the goal of your project - can be expressed in various terms. If you happen to know a specific target - good for you. If not, you better have some insight about the average traffic on the sea, or have a convincing story about where the fish are. That story, the target of the trip, becomes the mission, the goal of your project.

Target setting is dead serious. Most small time pirates set the targets to reasonable risk - reasonable reward level. This they can gauge even at the last moment - if they thought they were attacking a commercial vessel, but instead find a Navy frigate, the plan is quickly altered, and the resources (time, fuel, food etc) are a "lost investment".

IT projects have seldom the same luxury and clarity of their goals and capabilities. Small teams and experienced professionals are the preference, and greenhorns should not form the majority of the project team, so in theory it should be possible for a project to easily realize that instead of a minor change they are embarking on a significant system upgrade.
If the project behaved like pirates, or profit-share fishermen, all parties, down to the guy filling in the bait, shared an interest in the end result. Due to that, everyone excepts the Captain to gauge the situation intelligently, and if the Cap'n does not do that, she will hear about it.

For an IT project team and the manager the setup is often different. Members, and possibly the project manager, are running a portfolio of projects, so risk is spread over projects. The only really committed persons are the business owners, and this creates a discrepancy at the goal setting time.

Committed project teams is not a new invention, and and happily it is known to work pretty well in very demanding circumstances. Commitment starts at setting the goals and getting your crew to accept that - and to take the goal as their own.


Next - but not today - What about really challenging goals? Naval and general history has ample examples, so we can look into more organized private navies, whaling and exploration. In those the potential gains perceived by the crews have been astronomical and beyond, and the captains and crews have been equally open to risk. That story will follow once I get back here.

!!!