Alpha Software is focused on enabling developers to create robust, data-driven business applications that run on any PC, Tablet or Smartphone in the fastest, most efficient and cost-effective manner possible.

Share this blog:

Showing posts with label Michael Krigsman. Show all posts
Showing posts with label Michael Krigsman. Show all posts

Friday, February 15, 2008

Michael Krigsman picks up our "risk" white paper

One of the most rewarding blogs on the Web has picked up our recently issued white paper.

Too much IT coverage fawns over new (and untested) gee-whiz products, repurposed case studies (served up by vendors), industry issues that are really non-issues (featuring quotes served up from IT executives who are themselves served up by PR people, advancing some agenda), and so on.

Michael's blog gets to the real warts and sores that plague IT: project failures. So it makes sense he would be interested in a white paper that puts forth an argument for why IT projects fail.

If you've read the paper, you know we were clear in the executive summary about any bias we injected into the content. And we did our best to make certain those biases didn't pollute the counsel the paper offers.

That said, some of the initial comments on Michael's blog take us to task for writing the paper in the first place, because we're (I'm paraphrasing) "doh! ... reinventing the wheel ... people already know this stuff."

I'll be commenting on Michael's blog in a bit. And I'll be saying this: We're not reinventing the wheel. We're documenting why the wheel doesn't turn smoothly in many IT shops. If all IT folks knew why projects fail, fewer projects would bite the dust.

Instead, I've seen figures that claim MOST app dev projects fail in one or more dimensions: cost, time, requirements, maintainability (or the lack thereof), performance, etc. And many never make it to deployment, period.

In many IT shops, the emperor has no clothes. We're calling the emperor on that.

This reminds me of arguments about QA and testing. Every IT pro will claim to understand how QA should be integrated into the app dev cycle. Yet I dare say most app dev projects today still have QA kicking in late in the cycle when, in fact, QA should start on day one.

Just last month I heard, first hand, of a MAJOR project deployed by a MAJOR job hunting site that failed in a MAJOR way. It was NON-FUNCTIONAL on day one. A truckload of cash was invested in this new "state of the art" app. And it didn't work. Worse, I heard the code is a hairball of .Net code.

How does that happen? Because the emperor has no clothes. Because the wheel was not documented. Because too many businesses have IT shops that live in a glass house.

Related Posts Plugin for WordPress, Blogger...