Goals, missons and crusades - what is that in IT parlance?

The previous analogy of a small time fishing vessel or open boat pirate crew is about the same as a "Change request" in IT project scale. A "Definition of Done" is required, there needs to be a reason for doing the job, and the people doing it need adequate tools and resources, but beyond that the work is done in professional and seamanship like way without further guidance or structure. A change and an small sea trip are pretty analogous, and from the project manager point of view that is not of exceptional interest.

Unless, if the change is being done as an operation to help your larger project to proceed. In nautical setting this would mean that a small boat is sent out to survey an unclear passage, and the ship's launch is expected to come back - just like the change your requested in the Data Center is supposed to finish.

If the boat does not return, the Captain of the ship either sends another boat (perhaps the first team is in trouble and need help), or abandons them. The latter is not that popular as it tends to send a fairly negative message about being expendable to the rest of the crew.
If the change does not finish, the IT project manager can ask again, can escalate, wait for longer, or try to identify a workaround. Most of the time the workaround is fine, unless the change and the issue is viewed as dear as a crewmate. This can happen when an essential piece of technology needs to be set up and it is not, and the cause can be as trivial as wrongly ordered optical transciever.

From IT project point of view it is more interestingto look at longer voyages. It is sometimes frustrating to try to define the outcome of  larger sw development or even an infrastructure deployment project. But let's compare with a 19th century whaling voyage.

So you have a little exerience in the business and you own a ship, a regular New Bedford made whaler. You know a great captain and a reasonably good first mate who want to spend the next 18-36 months somewhere in the far corners of the earth. How do you get the ship out to sea and what can you expect in return.
Whaling sounds straightforward - sail out, kill whales, create other environmental mayhem, return to port, find a pub, get obnoxiously drunk. Yep - let's start at the beginning. Sail out - with who? Where do you get the crew? If they are worth their salt, they'll want to know if the trip will pay or not. That depends on your plan, on your ship, on your captain and on the luck of the day. Your crew to be hired (except the occasional shanghaid case) needs to hear what you have in mind.

So off you go to the tavern and tell your story - Captain Ahab, who will always find the Great Fish, is looking for Good Seamen and brave Whalers to join him on a trip to the South Sea (that's the refreshing bit of water just around Antarctica, btw). He'll be preparing my stout ship the Matchstick for a three-year voyage to hunt for spermiceti whale.

And there you are - you have a plan and a Goal and the goal is NOT to fill the boat, it is to hunt whales. You, Cpn Ahab and the entire crew want to come back alive and rich, but that you can't plan.

Compare with the IT project. We think we will reach cost reduction, flexibility, increased operational and business effectivity but in reality we set up our projects to go ahead and do useful stuff and hope for the results. Sure, it is good to list the expectations, but the mire tightly you set the goals the fwer degrees of freedom there is for the captain and the crew to make smart decisions.

Now we have the  ship and crew, and provisions. Right after the lines are cast the voyage is very different from an IT project since now they are on their own, self-sufficient and there is no way you can help them - or get status reports, discuss strategy, impact of new data etc. You can run the IT project much more closely, be agile, change your plans and goals -- and yet the IT projects try to articulate the end result.

The whaler has now left and there are but a few goals. Return to port. Keep your crew alive. Find right whales, kill and proces them and fill your ship. Oh, and about the first goal - yep, return, but do not return empty handed if you ever want to command a ship again.

All this you must think about before you start looking for the crew. To where (any ocean!), for how long,what if they don't come back (your only ship? Better sail along, mate!) -i.e you have goals, expectations and raw plans and that sets the direction of the whole thing, from resourcing, schedules, risks, rewards, management structures and so on. Do a low risk short tripo North Atlantic and you'll have the ship back in a few months and a neat little profit. Want something bigger? Send them to Bering Sea, and if the come back, you'll have a windfall.

Set up an IT project with relatively modest goals and in a known environment, and you'll get people that enjoy that and produce. If you want the jackpot, the project needs to be ready to sail over the edge of the world, and your crew will match that degree of ambition, desparation, raw energy, and drive.

Be careful what you wish for - it has a great impact on what happens next.

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.

!!!

What the heck - pirates and projects?

Set sail with Captain Morgan? Take a trip to The Pirates of the Caribbean with Jack Sparrow? Great, but what does all this to do with project planning and management?!?

It does, more in some ways than others. I manage IT projects, and have had my share of project management buzzwords thrown around  - towards me and by me;-).
I am also a free-time naval history and sailing enthusiastic, and over time some similarities seem striking. So I wanted to put the vague thoughts into writing and that is why this is here.

So what are the similarities? Differences are easy to point to - Pirates were murderous thieves that behaved, judging on today's standards, worse than many of the worst war criminals (the term "war criminal" really applies to post WWII). They risked everything, including their lives, for a stake of great treasure, and worked hard and very focused to reach their goals. The best of them became wealthy or possibly stinking rich, but the failure rate was high.
Hang on - besides the environment and killing people - pirates, whalers, commissioned privateers, explorers all needed to have a plan, get it funded, find the resources, ships, sailors and commitment to execute their plans, and they took calculated risks, often on very incomplete information. Sounds like project planning to me, and more follows if you pay closer attention to what happens under way.

I'll be looking at "DevOps" and compare that with a ships crew, the sailors, officers and idlers, I'll be musing on Agility with on-watch, off-watch, with the easy days on the Trades and the all out effort to reach a safe port in a storm. Commitment and focus on shared goals is amply illustrated in various single vessel trips, be they pirates, whalers, fishermen, explorers or traders on the seas.
Waterfall project model compares nicely with some characteristics of Naval traditions, while inspired and well trained crews and ships demonstrate the immense value of nurturing the specialist tradespeople you have on your roster.

Some of the failures on seven seas are very instructive, and can add to the tool chest of a Project Manager. The nice thing about the sea is that like war it boils sound (and unsound) practices to their essence, and single ship voyages compare fairly well with medium sized IT projects.

So Godspeed, and stay on the horizon, and I'll be hoisting the Blue Peter for you to join this journey of comparing Pirates with Project management!

  &