Three Project Models

Last night we had a large crowd for The Final Frontier at the Association 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!

Redo

Users work differently from makers, for good reason. If you make a mistake buying a book on Amazon, you can usually go back an action, or a screen, call it a redo. Makes sense to just keep hammering keys until you get what you want.

Makers often don’t have redo, so there’s an emphasis on using a planning and structure to reduce rework. I cut that board three times and it’s still too short! Well then, Measure twice, cut once.

Working in an IDE (Integrated Development Environment – programmer’s code-making software) discovering an error can require taking out days of development.

The old observation that one programmer can do the work of a thousand programmers is valid because many programmers spend the next morning tearing up whey did the previous day. One step forward, two steps back.

Sales Lab’s Planned Workcycle addresses the need for Architecture and Design before Executing, and came from construction contracting. If you order a crane, it better be busy the whole time it is on-site, and after it leaves, you best not need that crane again.

The Workcycle also has an original structure for how to do Evaluation which makes Evaluation work a whole lot better. I’ve found it increases efficiency in many types of complex projects.

How does the availability of Redo change the value of Planning, the process of Executing?