Each technology is on its own product lifecycle, which may or may not match with your organization’s business and development lifecycles. In particular, there are certain cycle mismatch patterns that commonly occur in organizations looking to adopt new technologies. I’ve labeled four such mismatch patterns: firefly, underdone, conveyer belt, and landfill. Each is worth examining.

Go read the whole thing.  ..bruce..

• Performing IT Project Triage
• Pulling the Plug on IT Project

Next up: how to deal with personnel issues.  ..bruce..

And if you have read them, you should probably re-read them.  ..bruce..

My two latest Baseline columns talk about ways to retain IT staff. The first column talks about making an effort to align your staff’s individual professional goals with your organization’s goals. The second column talks about how to improve your IT staff while encouraging them to stay with your firm.

As always, feedback is welcome here or there.  ..bruce..

In the meantime, I have two new Baseline columns out that deal with risk management in IT project. I give both a bad example and a good example, each drawn from my professional experience. Comments, as always, are welcome here or at Baseline.  ..bruce..

The first column, “Second Class Software Quality for Major IT Projects”, talks about the curious fact that organizations are willing to spend millions, tens of millions, even hundred of millions of dollars on major IT project and yet still nickle-and-dime their software quality assurance (SQA) effort. It doesn’t help that SQA personnel are pretty much on the bottom of the tech status totem pole, either.

The second column, “Do Not Defer The Difficult in IT Projects”, describes the all-too-human tendency in IT development to put off dealing with the toughest problems until last — at which point, you may not be able to solve them all. It also explains why so many IT projects get 80-90% “done” and then suddenly slip for weeks or months without making much progress.

Enjoy, vote, and comment!  ..bruce..

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 are welcome.  ..bruce w…

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

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

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