Here is an anecdotal observation; in the last 3 years, all of the delivery groups that I have supported in my employer have seen a drop in delivery and support maturity.
The drop is (I believe) being enabled by a highly competitive market, where corporations are buying only on price.
First example: on a recent sales pursuit I was involved in, I had to sit and listen to the sales architect intoning the mantra "if that is your price point we will not be competitive" every time we presented a testing team model for inclusion in the deal. The consistent demands that we reduce our base cost led to us solutioning an unbalanced team, with few experienced resources and a lot of new and barely skilled resources. We won the deal, and began to transition work from the client to the offshore team. However, given that this was an offshore team, we also ended up with the predictable attrition issues appearing within a matter of months, with one of the experienced team members leaving and two others moving to better paid jobs. This was apart from the dubious quality of a lot of the work that the team was producing.
Second example: On a more recent delivery program, I soon discovered that several major roles for a delivery team of that size were totally missing. We had no Business Analysts, no Configuration Management team, no Requirements Management process (a colleague and I had to rapidly create one), and no Testing team, until myself and a colleague were parachuted in after the client had spent 2 months beating up the temporary Testing Manager (who must have been in the wrong place at the wrong time when that role was assigned to him). I phoned up a delivery manager on the program who I knew from a previous life, and told him that I could not see the roles in the team anywhere. His response was a long sigh, followed by "I know...", then he told me the sorry story of how the roles had been in the original delivery model, but had been removed prior to the signing of the contract with the client. Clearly the intent was to save money, but all it did was deflect essential work to other resources, who in some cases were not equipped to bridge the gap. For example, the use of technical team leads instead of Business Analysts did not work at all well when dealing with the client. Client Business Analysts would ask questions about the solution to the SME's who would reply with technically-focussed answers. I would then spectate as the two sides realized they were fluent, but in different languages, and a dance ensued as both sides attempted to reach a mutual understanding, sometimes successfully, sometimes unsuccessfully. The delivery program in question morphed into a "death march" program marked by hideous over-work, failures in testing and QA due to missing fundamental processes, and continual delivery delays due to lack of agreement on requirements and schedules with the client. Eventually so many people became burned out that finding people who would just answer the phone became difficult. It was not a happy delivery.
I remarked to several people on that program that it looked and felt just like a 1980's era delivery. In the UK at that time I became wearily familiar with out of control projects where fundamentals were not being addressed, and as a result the projects seemed to become endless sinkholes of continually expanding timelines, costs and burnout. We are back in that era, if my recent experiences are representative of the delivery landscape, at least in the USA.
The more interesting question is whether delivery maturity will rise again as we leave the recession. The current fashion for offshoring just to save money in the short term is likely to remain a powerful driver for IT decision-making in the near future.
I see little prospect for wide improvements until corporations stop offshoring just to save money. That approach reminds me of the infamous client-server boom in the 1990's. Supposedly expensive dinosaur mainframes were going to be replaced by cheaper "snap-fit" small-server solutions. On paper, the cost savings looked impressive. That was, until mainframe costs fell dramatically, and the terrible truth dawned on I.T. departments that the new infrastructures were expensive and complex to build, manage and support, and the "snap fit" ideas didn't really work too well. Snap-fit is still not really here either.
An awful lot of work still takes place on those pesky "dinosaur" mainframes. In the meantime, I see a lot of delivery programs lurching from one crisis to another, caused by lack of proper delivery process modeling at the outset, optimistic timeframes, and a desire to keep costs down to remain competitive. In other words, we are building down to a price, not up to a quality level. With some of the defective staffing models I am seeing, I am not convinced that the teams could build to any quality level anyway - they have no effective Quality Measurement processes in place.