Our customer expects to have the application and nothing more. I mean, he doesn't care if we have a process, if we are CMMI compliant, if there is documentation, if there are minutes of the meetings, how things are done, etc. He cares only for having the application as soon as possible in his environment, and he is only paying for that. Everything else is overhead. Then, not only I am having a hard time convincing the development team to use process, but management keeps telling me that all the additional stuff (aka CMMI evidence) is something that the customer doesn't care at all... Oh boy. I'm having some difficult times down here. Guess I have to think more about these problems. BTW, I live in Buenos Aires, Argentina.
Believe it or not, we have the same problems here in the US! It's all too common a problem. In a way, your customer (and management) has set up the perfect scenario for you to make your argument. It's starts like this: Your customer should not care about the documentation - it's right that he only cares for the code. That is the "end product" he's paying for.
But he should consider what life would be like with:
- fewer defects
- software that more likely meets their needs
- a smaller support/maintenance organization
- projects being on time more often
- projects being on budget more often
- the ability to manage multiple releases at the same time easily
- the ability to revert back to any release when needed
- less mistakes during deployment (like the wrong code going into production)
- the ability to re-use code for future projects (saving up to 50% of effort)
- the ability to reuse architecture designs in the future (again saving up to 50%)
- the ability to use resources across a wider array of projects, making more people available
- the ability to not be held hostage by "bob" who is the "only guy" who can make it happen
- the ability to more quickly deliver projects (more Agile!)
- there's a lot more .. . .
And the best example is the debacle of Y2K. If the organization's who had to spend millions of dollars fixing that problem had done MINIMAL design and requirements documentation then COBOL programmers would not have to be paid $180/hour to fix it, and IBM (and dozens of other firms) would not be billions of dollars richer for the effort.
Is it overhead? I don't think it is, but the real question is "how do you know?" What is your true cost for developing software if you consider re-work, defects, mistakes, misunderstandings in requirements, endless test cycles, production fixes, et al. The honest answer is, they don't know.
I call it "underhead." It's as good a name as any, because the whole discussion is moot and a waste of time when you don't have accurate data.