Three Project Models

Last night we had a large crowd for The Final Frontier at theAssociation of Information Technology Professionals. One of my teachers had been reading ahead and brought a thought paper about reforming our economy.

Last time around, we were building super computer environments for modeling complex technical processes, and the results were astonishing. Since that time he has been working at a national level to improve our technical capabilities in state-of-the-art engineering.

He reminded me of a lesson he taught me years ago, that a government group is different from a corporation, in that a government group has a mission. Accomplish the mission, stand down. A corporation is supposed to turn a profit and continue.

When a government body is failing at their mission and starts trying to morph to “make a profit” we figure they are truly lost.

Anyway, his proposal called for rallying an infrastructure first, then proceeding to create results. He has been working with a lot of government recently, so I could see where he got the idea. Personally, I am weak at building effective infrastructure (who isn’t?), but since I’ve come to accept he’s smarter than me, I woke up this morning changing my thinking.

So, one way to start a project is to build an infrastructure, get budgeting, recruit troops and march off smartly. Nice work when you can get it. Reminds me of Jefferson and Madison creating the Navy.

The second model comes from my construction experience, and dovetails nicely into software development, Architecture, Design, Execution, and Evaluation. I wrote about it in 2009, after creating a major improvement in Evaluation.

However, I have seen that methodology fail spectacularly, and until last night I hadn’t figured out why.

The planned workcycle is most valuable when you are doing variations on a theme, the homebuilder building his 20th home, the software developer creating his 50th database. The workcycle is about improving the efficiency of projects that are already understood. They come apart when you insert unknown materials, technologies, and people.

There are still a lot of these kinds of projects out there, and there is also a third valid model, and last night I realized when to use it.

Back when the internet was optional, I was selling a lot of COBOL, largely by attaching it to the internet. My company wanted me to go across country for an internal boondoggle to think lofty thoughts, and when management got tired, they left the building, and the worker bees began experimenting with some adult beverages.

At some point I idly asked what was the shortest COBOL routine and my (several) technical advisers settled on three lines, which even I (a mere salesguy) could do..if I was worthy.

A laptop was booted. Green screen. Brackets. Three line majick incantation. Then “go.”

The computer thought for a bit and replied, “Hello World.”

I was worthy!

And that’s the third project model.

A simple prototype proving the capabilities required. Call it The Bar Band Model, the Artillery Ranging Model, or the Towel Cape Off The Garage Roof Model, a quick prototype is an excellent way to prove or disprove an hypothesis, and also has the increased value of allowing users to better specify what they want based on what they learn seeing the prototype. Sounds like an Open Source Model.

You can go here for more Tips 4 The Big Chair!