I have a handful of posts in the queue to share with the team, but every now and then something drops into my lap perfectly timed and goes right to the top of the list.
Dan Ward has a blog called, “The Rogue Project Leader” that I’ve been following for several months. I’ve shared one of his ideas in this blog, but there are several others have influenced the way I think about our work on CG-LIMS. His blog is “unofficial,” but it’s good stuff. He’s also regularly published in DAU’s publications, and has published a couple short books that explains what he means by FIST, or Fast, Inexpensive, Simple, and Tiny. You can download “The Fist Handbook” and “The Simplicity Cycle.” I’m not asking you to pay to have them delivered on paper, but they’re both well worth the download. At first blush, you might think there’s nothing FISTy in the world of major system acquisitions, but we should all be willing to challenge each other to look for ways to put the ideas — ideas that have worked for many of us in the past — to use.
With that introduction out of the way, what brought Dan’s work to the top of the list tonight? Today he posted a piece called “The Zen of Python,” by Tim Peters.
I’m in the same boat as him… I’m not a Python programmer, so some of it doesn’t make sense, and some of it I’m probably misunderstanding. But there were two things that resonated with me and are timely as we finish the ORD by solidifying our KPPs and implementation plan:
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Our implementation plan, distilled to black and white, has got to make sense. If it’s hard to explain, it’s a bad idea.
There were also a couple lines that bear repeating for all of us who are used to dealing with software systems that seem to deal with everything as though it were an exception:
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
I’ve heard Jim say that special cases aren’t that special. As we implement COTS tools designed to be configured to enforce industry standards, I think we’ll find that there are fewer “special cases” in our future than we think we have now.
Now for the folks on the CG-LIMS team… stop reading and start helping make the implementation easy to explain!
Classification: UNCLASSIFIED
The Commandant had little trouble explaining it in an interview with Faircount Publishing in “Coast Guard Outlook 2010” when he said:
“My goal is to apply the same business practices to our aviation, ship/ smallboat, and sensors, and also use the
same information systems across the Coast Guard whereas the other services may be using the same business practices but still have their traditional service communities. The real thrust is to unify the business
processes inside the Coast Guard.”
http://www.uscg.mil/modernization/docs/Coast%20Guard%20Outlook%202010%20A%20Habit%20of%20Change,%20Coast%20Guard%20Modernization.pdf
Classification: UNCLASSIFIED
Thanks for sharing that link. Love the clarity of goal. Now we need to take it down to the level needed for the ORD. With that goal and our understanding of what’s doable in five segments / 10 years, I’m confident we can boil it down to words that are easy to explain and understandable by all.
I feel great about the progress the team made Wednesday to nail down the 5 KPPs.
Classification: UNCLASSIFIED
In a flash of clarity today, Jim boiled the question to be answered in the ORD as “What I want by when.” Yep, that focuses us on answering the right question.
We want to make sure the ORD provides the simplest possible answer to “What I want by when.”