Webster & Associates LLC

As mentioned previously, I spoke last week at the Denver IEEE Reliabilty Society chapter meeting on an SQA-centric view of software development. I plan to develop this into a full-blown articles (or posting), but in the meantime, here is the slide presentation (PPT, 340KB) I used. Feel free to ask questions. ..bruce..

If it’s Friday, it must be another Baseline column. This one talks about the issues surrounding whether to build or buy software:

The other day, an IT colleague of mine mentioned a conflict at a corporation where he’s working. The corporation has a mission-critical application deployed across a large number of workstations. The set of corporate employees who use this application largely use it and nothing else all day long at dedicated workstations. The application they are using is a customized third-party application; however, the firm has been having chronic problems with this app (let’s call it “QRSApp”), and so is looking at different solutions. The firm could continue to make changes to QRSApp to fix their problems. The firm could switch to a different third-party application; several other vendors market applications of this type within this firm’s industry. Or, as a senior IT manager now wants to do, the firm could develop a completely custom and private application to replace QRSApp, so that the firm has complete control over it.

The question: which solution is best?

Comments welcome here or there.  ..bruce..

On September 2nd, I’ll be speaking at a meeting of the Denver IEEE Reliability Society. It will be held at 5:30 pm in the Seagate Building in Longmont (CO), on Nelson Road between 75th Rd and Airport Rd.

Here’s my abstract of the talk:

INSIDE-OUT: Organizations too often treat software reliability as an ‘after the fact’ consideration, performing testing as a last step and then constraining it due to schedule and financial pressures. Webster will present a simple “inside-out” software lifecycle model where all software development activing (not just coding) takes place within a framework covering a broad spectrum of quality-related activities.

I’ll post the presentation slides (PPT, 340KB) here after the talk. ..bruce w..

Yes, it’s my latest Baseline column:

Last week, I talked about some of the reasons why large organizations often reject the best solutions for a troubled IT project: fear, pride, budget, and the ever-present internal politics. This week, as promised, I will talk about what it takes to champion the right solution. I can’t guarantee that you’ll succeed, but you will have a better shot at it.

Go read the rest of the column. And I promise some original postings here this coming week. ..bruce..

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..