Shipping-Inspired Project Planning

BACKGROUND 

In a previous blog-post Linguistic Approach to System Description I wrote about how to specify and describe products,  especially software.  The post explored what are the important parts of a good specification - to make sure we include them all in about equal and balanced portions.

THIS post is about how to manage and describe the process of implementing a specification. In other words ... this is about Project Planning.

It is important to have a clear description of WHAT is to be produced, and also separately HOW it will be produced. Sounds like a no-brainer, but in real life when doing project planning we need checklists, and rules of thumb.

In particular this post is about project planning for software- and other creative projects. The shipping-metaphor presented below would not apply to "physical projects" like building a bridge. But it would apply to the project of designing the bridge, which needs to be done before it is built.

The earlier post was for the viewpoint of someone ordering the creation of a software system. The current post addresses the issues of someone producing it. The buyer, and the seller.

DELIVERABLES

I will first describe the four documents I've found valuable to my projects, before explaining what they have in common with shipping industry:


A) Action-Plan.rtf 

Action Plan tells what I (or other team-member) should be working on NOW - or next time they sit on their work-chair. This is not about next week or next month, it is about the great now.

B) Release-Plan.rtf

Release Plan tells what will be in the NEXT release, be it an alpha-, beta- or production release. "Release" means it is given for someone to actually use, be it the developers themselves, test-team, or the public. This document might as well be named "Next Release Plan", since it is all about the next release.

C)  Product-Plan.rtf

Product Plan tells what will be in releases that we intend to  come after next release.

One specific purpose of the Product-Plan is to prevent you from trying to write one huge plan that includes everything. Having a separate document called Product-Plan.rtf makes you ask:  Does this feature belong in the release-plan OR the product-plan?  Does a specific feature really need to be in the next release, or could we "ship" the next release without it?  That would bring the value of the new features in it to users earlier.


Release-Plan and Product-Plan describe WHAT is planned to be in the product, at some point in future. They don't really describe HOW to get there.  The big difference with Action-Plan is that it describes what to DO. Release-  and product-plans describe a GOAL.

Implicit in the definition of the above documents is that if you reach the goal stated in the release-plan, you are going in the "right direction". When you do get there, you can, and should re-visit the plans for your next destinations.

So is that all we need?  No. There is a fourth one:


D) LogBook.rtf

We are getting close to the shipping-metaphor now.  The LogBook.rtf records entries about how and when the project plans were executed, or not. Were they revised, how, when and why?

What was done and and why is important information to keep track of.  Writing it down helps our learning process and prevents others from making the same mistakes we did. Or us repeating our own mistakes.


Why '.rtf'?   I keep my project-documents in this format since it is a relatively standard format, whose editor-app launches fast.  I don't use .txt -documents since I like to emphasize portions of the text by making them bold, italic, or even colored.  .

REFLECTION:  SHIPPING INDUSTRY

Shipping-industry moves goods and cargo (or are they the same thing?) from one harbor to another. But moving stuff from Manila to Murmansk is not the end of the story. A ship must deliver something to Murmansk, but once it gets there it will typically pick up some new cargo to take to the next destination.

So a shipper (or is it 'skipper'?) needs to plan where to go next and what to deliver there. Releasing cargo on a port creates the next portion of VALUE of the trip. Sounds like a "release plan", right?


While you are at the sea you must navigate the ship, maybe seek shelter from the storm, sometimes just keep the engines running and steer towards specific coordinates. That is the action-plan.

There is no value to the ship sailing on high seas until it actually releases its cargo to the next port of call.  What exactly to transport to the next port is the release-plan.

When you take your next cargo to ship it somewhere, you naturally think: Is there something in the city we are sailing to we can profitably carry to the next destination.  You try to optimize not just the value you get from taking the cargo to the next destination, you also think ahead. Where will you go after the next release. That is the product plan.

And of course, the captain needs his log-book.  I call mine LogBook.rtf.


When you make your next port-of call, the situations might have changed. You may get a new order. You may hear a forecast of hurricane, or pirates on your planned route.  Maybe a new opportunity presents itself to ship pogo-sticks to Novosibirsk.  That is the time, to re-think your next cargo and your next destination. That is the time to create your next release-plan.

Shipping industry tells us we don't need to set in stone all the harbors we will visit on a given journey, Or what cargo we'll be exactly carrying and delivering: What will be the product features that will be in the next release.

IS THERE MORE?

Is there more to the analogue?  Well when a ship comes to a harbor it often doesn't release ALL its cargo in that harbor. It will continue its journey to move rest of it to other destinations. Similarly we don't (try to) release all our planned-for features in the next release.

The ship takes some new cargo from the city it arrived in, to take it further. Similarly we take feedback and new requirements from the users of the release delivered, some of which we will deliver in the next release.

But some tomatoes on board may get rotten when we reach the hot climate of Horse Latitudes. Some requirements we planned to be in next release may be found to make no sense after all. We will have to throw them overboard!

Software developers use tools that allow them to produce systems faster, or tools that support coordination among a bigger team. Ships can be faster or slower, and they can take a bigger or smaller cargo on them at a time. Some smugglers even use speed-boats ...

So, software developers would seem to have much in common with the shipping industry. Aye Aye Captain!

Lesson from Shippers to Coders:  If you don't make it to the port-of-call, your trip is worthless. If you do but you can't sell your cargo, at least you can ship back some feedback.

---

http://panuviljamaablog.blogspot.com/2013/07/shipping-inspired-project-planning.html

© 2013 Panu Viljamaa