The de-evolution of corporate UI design

Found this great picture from stuffthathappens.com that pretty much sums up the de-evolution of UI design from the corporate perspective:



This is both sad and true with regard to UI design in the corporate world, but much of that in my opinion, is because a company does not need to "sell" the UI to its users, like an Apple or a Google would, but that's still no excuse for some of the horrible UI designs I've encountered at work!

Implications of a bad requirements-gathering process

A recent article in CIO magazine points out the chronic inability of companies to define requirements:

A new survey by IAG Consulting finds that among two-thirds of companies polled, it is "improbable" that an IT project will be considered an overall success, due to inadequately or improperly gathered business requirements.

Fifty percent of these companies' projects could be termed "runaways," marked by at least two of these three factors: Taking more than 180 percent of estimated time to be completed, going over 160 percent of the established budget, and delivering less than 70 percent of the desired capabilities.

The other 32 percent of the companies surveyed enjoy a "probable" chance of success for IT project, according to the study, which surveyed more than 100 midsized and Fortune 1000 companies in North America.

I agree with the article which mentions how most employees view requirements as a "document" instead of a process. Furthermore, the majority of the time most are forced to document for the sake of documenting leading to badly written requirements, which in some cases would have been better had they simply written a check list of items to implement.

The whole rational for getting requirements, are so that the stakeholders and end users can make sure they get what's required so that the IT solution being built fulfills their required needs. Much of the disconnect at least as I've experienced it, is that requirements are done in a vacuum by business users without input from knowledgeable IT staff members who could place some reality checks on the time frame for which those requested requirements can be delivered.

And visa versa, if the requirements are done by only IT staff they may build something technically sophisticated, but of no use to the business end user. The article quotes some statistics to back this notion up:

The damage was worst when non-IT business analysts were in charge of the requirements. Those projects came in at nearly double their budgets and took more than 245 percent of their allotted time, according to IAG.

When IT workers managed the requirements analysis, the results were only slightly better, with budget overruns at 163 percent and time at 172 percent.

The best results came when business and IT worked together on defining requirements. There, budgets ran an average of 143 percent and time, 159 percent.

Even when there is a close alignment with IT and business, projects still ran over budget and took longer than estimated, and I think much of this stems from companies not having adequate training and dedicated staff, as the article states, "companies should form a 'center of excellence' for business-requirements gathering managed by both IT and business employees". I agree.