Project Delivered, within Time, Cost and Scope - Customer / Project Team unhappy

I notice that customers are not always so happy although the IT project has been delivered within time, cost and scope. This has happened to me a few times, and it hits me really bad psychologically although I know I should not take it seriously.
Here is my does;
- Map the organization well
- Know your direct subordinates, as well as other stake holders
- Communicate changes
- Keep a detailed project log (although it not your job)
- Keep budget up to date (although it is not your job)
- Check vacations in advance
- Inform upcoming events and changes well in advance
- Talk F2F about financial/billing issues
- Be firm with the scope, recalculate the change effort
- Communicate risks to the proper party (your superior), and not all.
- Be proactive although (not all need to be using the.

I noticed you mentioned on time, cost, and scope. I have been very successful in my career as a project manager, Sr PM, Program Manager to Sr Pgm. I started off in a System engineering and move into the IT and system development environment. But before I became a PM, I had been a specialist in CM (full product life cycle, requirements management included), QA (verification and validation/testing, compliance), and the Development Process/Methodologies, Team Building (right people, right skill sets). Those skill sets were key and important to my success in Program/Project Management. I say that to say that I have always managed with the following being important to the success my programs/projects:The perspective I start with.
- Being on time (consider with the required scope)
- Under or within approved budget (early establishment of change an control process)
- With the required Quality (Meeting requirements and expectations: Approved/mutually agreed to while the client and user being involved in the beginning and throughout the project or program. And insure transfer of knowledge takes place also)
- To the satisfaction of the customer and user (monitored throughout and why the above is important)
Along with the I try to used best/good practices and lessons learned.
I hope the last two items helps you in the future with your state of mind. Good luck!

The wording "Seriously" should have been stated, "personally".

The IT projects have lately become multi level, deliveries, where the companies involved (including the big consultancies) are shuffling the resource and delivery responsibilities further down the resource chain.

The consultants and even the internal workforce are working in an outsourced mode (in a chain of resourcing companies), where the work time is hacked up for serving many projects.

For a project manager it can be difficult to see behind the scenes with implications on the product delivery. This phenomenon does not limit itself to IT development, it is apparent also on the business side, concept definition, design ... all the way to delivery and deployment.

-"The urge to just deliver the PART that belongs to ME", often affects the quality and as a consequence increases the number change requirements. Big consultancies often benefit greatly from this.

In the scenarios where the companies are reducing workforce, a PM also needs to take into account that the professional workers often leave the company, even before personnel reductions are apparent. This also can create an illusion of the project team being highly skillful, although the unofficial support mechanisms have disappeared.

The phenomenon, as I see it has increased the last 4 years, and I feel that this seriously affects the style needed for delivering a project.

In closing, this type of projects have many levels of satisfaction, where for someone a good job delivered might not be so "good". Also, one might say "the customer satisfaction" should be high ! However, WHO is the customer when the program manager / PM can belong to another company than the business owner and the deliveries in the end becomes a political game between the delivery firms.

Then, who should the PM serve ?

This forces the project manager into silo thinking, regardless of quality, as it otherwise can turn out to be financially risky for the PM.