"Actually, it's no one's fault." This was the conclusion I had come to after a week of working on a nightmare project I had been called in on. The CIO had asked me for a briefing on what I had found so far.

"But how could this be such a mess?" the CIO wanted to know. "Granted, the project involves a sizable change of an existing piece of software, but that was written only three years ago. I've got 1,500 customers waiting to use this new version. It's very high profile - and we can't get it out the door. Costs are crazy. I don't even want to think how far above budget we are. We've missed so many ship dates that the developers won't even guess when it might really be ready."

The client was a large one and had a good-sized development shop dedicated to projects inside the company. I had been asked to come in to triage the situation - to determine what was workable, what wasn't, and to lay out a plan that could be followed going forward. As part of that effort, I needed to understand how the client developed software. So putting on my Sherlock Holmes cap, I began to snoop around.

The Best Intentions
What struck me first was the degree to which everyone involved had tried their best. This was not a case of people who didn't care or internal politics that had sabotaged development efforts. To a remarkable degree, the entire cast of characters had done their best to ensure success.

"We sat in meetings to determine what the users wanted the software to do," one of the lead developers told me. "We worked up prototypes; we sat with the users and watched them work. I honestly don't know what we would do differently if we were to tackle it again today. I think that the users just didn't know how to tell us what they really wanted."

I thanked him and went to see the project lead of the initial project. "It was a big success," she told me. "The CEO and CIO both made a big deal of the project - about different teams working together. For a while, we were the poster kids of how to innovate within a corporate environment. The developers were great. They kept going over things with us until we were sure we had them just right. They offered great suggestions and kept us on track. Really, it was a pleasure to work with them - and that's something different from my normal dealings with developers. I don't know what the problem is now."

She was not the project lead on the revision. "Could it be the new project manager maybe isn't experienced enough?" I asked.

"No," she told me. "Whatever it is - that's not it. I've known and worked with her for almost 10 years and she's top notch. She's rolled out at least seven major new projects in that time and every one of them has been a success. In fact, she helped me on a volunteer basis on the initial version of the software that was such a success. She's really good."

Something in what she said tugged at the back of my mind. What was it, exactly? "How long has ABC been in business?" I asked.

"About 12 years," she said. "I started with them when they were about a year and a half old."

I had an idea I wanted to follow up on. "How many new projects would you say you've done in that time?"

"Maybe 10 or 12 - something like that. But the first version of this was the biggest by far."

"And the current project manager has another seven or so? All successful?" I asked.

"Yes, why?"

Gaining Insight
"I'm just trying to get a good view of the situation," I told her, and left. What I saw was a situation in which a company can produce new applications - but can't maintain existing ones.

"Have you found the culprit?" the CIO asked me, running into me in the hall.

"Maybe," I replied mysteriously. "Do you have time to talk on Friday?"

"I never have time," he said, "but I'll make it. My assistant will give you a time."

I spent the rest of the week ruling out other possibilities. The code was of good quality, though documenting the code was often relegated to new developers whose understanding of the entire system (as opposed to an individual code page) was, understandably, superficial. Most of the code comments were fairly obvious: "Loop over result set" - that sort of thing.

I needed to confirm one suspicion and for that I had to wait until Friday morning when the original system's architect came into the office. I took Brian out to lunch. "Say, when you were originally architecting the application, how did you go about it?" I asked him.

"Well, we talked with the clients - the users - of course. We found out what they wanted the system to do and then we designed components around that functionality. We did use cases and then broke the system up into various functional components. I dunno why they're having such problems with it now. I guess we must have missed stuff, but really, I thought we had everything they wanted."

I assured him that it appeared they had done an excellent job of meeting all the user requirements. "Judging by the accolades everyone got - deserved for all your hard work - I think you did great. This problem isn't one of bad apples spoiling the barrel. I suspect it may be just the opposite."

Before we had a chance to talk further, Brian's cellphone rang and he had to cut our lunch short to handle some urgent business. I finished typing up a preliminary report and left to make my 2 p.m. appointment with the CIO.

No One to Blame
"Actually, it's no one's fault," I told the CIO. In response to his question of how they could have such a mess on their hands with no one to blame, I explained what I had observed. "The problem is with the system in place that produces software. And everyone is so close to that system, they don't even see it as a system - as one choice among others. To them, it's just the way to build software."

"And what is that system then?" asked the CIO.

"They're following a process of functional decomposition - of determining the things that need to be done and then designing components - high-quality components, I want to add - to fulfill those functions."

"Sounds right," he agreed.

"But the problem, though, is that the functions that are needed, change. Now, we all know this and we tend to blame our clients for their fickleness: 'If only they would tell us what they want!' But how can they? The clients aren't changing their minds randomly - at least not usually.

"Their changing requirements are based on their responses to changing conditions - market conditions and customers that want more for less, changes in business processes and constraints. Requirements are dynamic; your software design process assumes that things are static."

"So you're saying that functional decomposition is the real culprit?" he asked.

"I'm afraid so. It's not the functional decomposition itself that's bad, but it doesn't match up very well with the hyperdynamic flux that modern business - that you - have to deal with. It's always behind the times - fashioning a solution for a problem that was identified months or years ago."

"That's interesting. I know all my people pretty well and I know you can sometimes be blind, but I've thought all along that I've got pretty good people."

"From what I've seen," I told him, "you've got excellent people. They really want to succeed. But the system won't let them. Or to be more accurate, it will let them succeed initially, but it falls apart when any revisions are needed."

"We just haven't seen this because up until now, we've been mainly developing brand new systems, not maintaining existing ones."

"Right," I agreed.

"But this is going to be an ongoing problem, then," he said. "We've got several large-scale revisions planned and if we don't do better on them, we're all in real trouble."

"I agree."

"So what's the solution? Java? Or do I need to drink the Microsoft Kool-Aid and go with .NET?"

A Solution in Sight?
"Either of those may make sense for you and your environment," I said, "but neither one will solve this problem. The problem isn't which language you use; it's how you architect software."

"But there is a solution?"

"Yes," I said, "but it isn't a silver bullet. It involves a different way of looking at how software is created - one that at once gives users exactly what they need while, in a sense, ignoring what users tell us."

"Ignore our users?"

"Well, that's too strong," I agreed, "but the idea is that users can't ultimately design software. I know some people build methodologies on the idea that users drive the process and developers just implement what they tell us."

"Yeah, I hear that from some of my colleagues. It makes no sense to me. It's like having customers design cars or houses. No thanks."

"Of course, we need user input and feedback but developers have to be more than coding robots."

"Well, what of the idea of developers and users meeting in the middle? Developers move toward domain expertise while users move toward software architecture expertise?"

"That," I said firmly, "seems to me the worst of all possible worlds. Everyone is now, by definition, a novice."

"Well, I admit I'm intrigued. But I want my developers - at least my leads - and my project managers in on a more in-depth discussion. Can you put together something for next week? Do a presentation outlining the problems you see and how you think we can fix things? In the meantime, you don't happen to have any 'magic consultant powder' to fix this project, do you?"

I apologized that I had unfortunately left that particular supply back in Atlanta.

"Ah, we'll struggle through somehow with this particular mess," he said. "I just want to make sure we have a way to stop the pain for future projects. All right, then. Next time, you'll be speaking to all my key people."

I thanked the CIO for his time and left. I felt certain that this firm, with its dedicated developers and such an attuned CIO, had an excellent chance to turn the situation around so that revisions to existing software would be as successful as new projects had been. Now the responsibility was on me to put together a presentation that would help change their minds - even about things they simply assumed to be true and not a matter of opinion.

On the way out, I asked Debbie, the receptionist, for a local yellow page directory. Finding what I wanted, I wrote down the address and left. Forty minutes later, I was at my destination: Frank's House of Models. I got out of the car and when I opened the door, a small bell rang. I could see someone - Frank, I supposed - looking out from behind stacks of models in their shrink-wrapped boxes. "Can I help you?" he asked.

"I hope so," I said. "What would you suggest for a guy who's trying to build a model world?"

Frank smiled at me. "Follow me," he said. "I might have just what you need." (Note: to be continued next month)