Bruce F. Webster

I have a new Baseline column up on the tendency of large organizations to reject the best solutions for a troubled IT project:

The consultants, usually with the help of the employees in the trenches, would use their time, effort, and expertise to analyze the system under development or in production. They would arrive at a clear, supportable, essential solution – technical, architectural, methodological, organizational, whatever. This would be presented to upper management…whereupon upper (or project) management would say, “No, we can’t do that.”

Sometimes, they would give no specific reason why the solution was not acceptable. Sometimes, they made it clear that it wasn’t the solution they wanted or that they felt was acceptable. If they did explain their rejection, it was usually in budgetary or political terms.

The investigating team would often then go back and look for an alternate (and less optimal) solution. If one was found, often that was rejected as well, and so on, often down to the least desirable solution. Barry [Glasco] said that he and another colleague, Chuck McCorvey, had gone through this so many times with one client that they joked about simply presenting the worst solution first, since it seemed to be typically the only solution the client would accept.

Go read the whole thing; comments are welcome here or there.  ..bruce..

My latest Baseline column talks about the risks that follow a successful IT project:

But sometimes with projects that really shouldn’t succeed—that are attempting too much, too fast, with too many risks—enough things go right, particularly along the critical paths, enough superhuman effort is made by those involved, so that the project does indeed go into production on time and possibly even under budget. Upper management is thrilled; the development team looks great; and all’s right in heaven.

And that’s when the real trouble begins.

Feedback is welcome, there or here.  ..bruce..

My lastest Baseline column is up, in which I argue that setting up one or more maintenance architects within an enterprise can help reduce maintenance costs while at the same time providing a training path for chief software architects. Let me know what you think.  ..bruce..

I’ve been doing on-site work in both Texas and Virginia, as well as having a case start up in Denver. However, I have some ideas for posts here and over at bfwa.com; I’ll try to get those out in the next few days.  ..bruce..

My latest Baseline column is up, discussing how to make a distributed software development project work.  ..bruce..