IT’s Poor Customer Satisfaction: Don’t Blame Developers

A new report, IT Trends and Outlooks: Why IT Should Forget About Development,” should be a wake up call for IT developers and operations staff. As IT has become more “consumerized” over the last several years, “business users across all industries now expect their IT departments to deliver IT innovation and services at breakneck speed.”

Unfortunately, they’re not getting it -- not by a long shot.

As the Serena Software study acknowledges, “Customers are not getting what they want”, despite IT’s use of iterative development approaches such as agile that are “supposed to tie the customer and developers more closely together.” Furthermore, the report concludes, “IT is not delivering great software.”

The survey asked 957 participants about how their IT organization is dealing with the complex tech landscape (including newer mobile and cloud technologies), including their success with four application life cycle management processes:

• Demand management (service requests, project proposals, status updates)
• Requirements management (defining and managing requirements, stakeholder collaboration)
• Application development (coding, QA collaboration, peer reviews)
• Release management (deploying into production, post-production fixes)

The third process in this list isn’t the cause of IT’s poor performance, according to respondents. “Despite all the dramatic changes in application development over the last 10 years, most respondents think that they are doing an excellent job with their core development processes.” That strikes me as mildly delusional.

Survey respondents claim that speed and collaboration, two primary agile principles, “are driving better application development.” They believe QA and development are working as a team, not at loggerheads.

Where do they put the blame, then? “Defining and managing customer requirements need significant help” according to respondents. The biggest problem is one of collaboration with internal and external stakeholders.

Give me a break.

Tools and approaches galore have been available to improve requirements gathering back when I a COBOL programmer in the 70s and 80s. That’s what made prototyping tools popular -- they were quick, easy conversation starters, avoided the “I’ll know it when I see it” problem, and although not perfect, they cleared up misunderstandings early in development.

With network and cloud-based applications galore designed for collaboration and project management, I can’t believe people are still pinning the blame on requirements gathering. Is that IT’s fault (for not speaking the language or knowing the business), or are users still confused about what they want? Whatever the reason, this problem has been known for decades; there’s no reasonable way it can be used as an excuse.

Even the report is skeptical: “What’s surprising about these [quality] scores is that there are so many technologies that should theoretically help with requirements collaboration, including online meetings, real-time chat, wikis, and shares repositories.” Serena suggests this may be due in part to so many new form factors -- and not everyone is using the same tool.

The other culprit: operations. Given the mantra of frequently (daily or weekly) releases, the pressure is on to get new features and functionality installed quickly. The problem: a lot of time is spent fixing issues after deployment. Whether that’s because QA hasn’t done a good job or implementation procedures or testing are lacking isn’t clear from the report. “The extremely low score for deploying on time without issues clearly shows that the ‘standard’ release process is not working well.”

Serena points out that the results for the survey as a shole didn’t vary by industry. “What is especially troublesome is the fact that deploying releases on time without many issues is rated as consistently poor across all industries,” though the score was lowest for financial services firms.

Most reports I read aren’t as forthright as Serena’s study; I applaud them for their candor. Fortunately, the report also includes several suggestions about what IT needs to do.

You need to read this report -- it will be time well spent. It’s available here. Although there’s o cost, you’ll have to answer 19 questions (to compare your organization with survey respondents) and then provide brief information on a short registration form. Unfortunately, neither is optional, though you can skip through the questions without providing answers if you wish.

-- James E. Powell
Editorial Director, ESJ

Posted on 05/11/2012