Construction and Software Development

    Working from home today - for the first time in months - and cleaning up the Blog. Came across a Feb 2006 post regarding Construction and Software development. It struck me again how strongly some people can hold an idea and how weak that hold is when considered in a larger context.
    My current assignment (which I'm taking a well deserved break from today) is to guide the recovery of a major ERP project. Guide them out of the ditch they're in, back on the road. A business colleague once told me in his best Louisiana accent

Glen, you can tell when you're in the ditch - cause the weeds are hitt'n the windshield. Get this thing back between the white lines and keep it there.

Actually recognizing that the project is in trouble is sometimes hard and getting it out of trouble is most times much harder. But what I now realize is that software projects - at least the one I work on - have much in common with construction project - at least the ones I've been involved with from an IT perspective. Lots of qualification there, sorry but me experience is narrow when it comes to IT and construction (ERP, realtime controls, Billion $ sized construction and lots of nasty process plants, paper mills, refineries, places in remote parts of Wyoming, lying machines, and a few factories that bend metal or wood into money).
    Here's an example. Outside the high rise where the troubled project team lives, is a completed interstate expansion. This project added 2 or 3 lanes in both directions, a dozen or so bridges for 19 miles, 17 miles of light rail, with stations, parking and walkover bridges and a general cleanup of the storm drain system and other beautification projects along the way. It was a design - build project with a single prime contractor and tons of  subs. It was a "evolutionary" development project, since they could not foresee many of the problems that were encountered along the way, including bad soil, faulty bridge foundations that had to be replaced, major weather impacts and a few other "add ons."
    ERP projects are like that. The Commercial Off The Shelf (COTS) nature of ERP is an illusion. Sure there are a loads of DVD's that are installed and a larger load of tables that are configured sometimes 1000's of tables) and 1000's of screens that are configured. But the "SYSTEM" only comes together when the architecture of the technical product and the architecture of the programmatic products (work packages, schedules, budgets, development teams, etc.) come together as well. The "coming together part" starts with the Program Management Office (which is where I live).
    It's pure unadulterated conjecture that Software and Construction have NOTHING in common and may indicate that the software person has neither worked in construction nor worked in ERP deployment. I keep saying ERP because Hal Macomber said a few posts ago something about the number of projects and their need for simple tools. It dawned on me that a histogram for the number of projects and their size is probably bi-modal in terms of staff size, dollars and impact on the enterprise. Our team is around 400 and is typical of ERP. There are 200 or so "other projects" in the organization with teams of 2 to 6. This bi-modal nature skews the discussion when we talk about projects, software projects and analogies to other project domains.

What Domain are we talking about? Big, Medium, Small

In the Big SW project domain, we have a close kinship with construction and especially lean construction the kind Hal writes about. The small domain is there in large numbers, but that 's not that interesting in the end - mainly because its code development and I haven't done that for a long time. Code development is of course critical to the success of the project!! But compared to the other problems in ERP, it is tractable using the right approach - Agile of course.
    When we encounter uncooperative internal customers (short attention spans mostly), poorly performing vendors (on to the next job), changes budgets and schedules (annoying how a little overrun turns people against you), nasty regulators (SOX people in finance have no sense of humor about over budget behind schedule), fluid subcontractor staffs and other "normal" aspects of large projects - developing the actual code is a wonderful place to concentrate your efforts.
    As we get closer the the "business" problems listed above the closer we get to the construction analogy and the closer we become akin to the construction project managers living in their nicely painted double wide parked on the side of the Interstate.
    Before they finished ahead of schedule and under budget, we should have walked down to the construction trailer and introduced ourselves - "hi we're from the ERP PMO in that high rise there and we have some questions about staying on budget and on schedule, while keeping the customer, regulators and CFO happy."