The Business Customer says using a process adds cost to our project. How much does it really add?

Dear Appraiser:

Our business customer is constantly saying that any new process is going to add overhead and cost to our projects. They want to quantify it before agreeing to go forward. Help!


The answer is "9" :). No, just kidding.

How would they know?

I am working with a customer right now that used to say that. They complained that the new process IT was about to deploy would add 10% cost in overhead AND that it would slow IT down. The strawman they would use was "if the system costs $100 it only makes sense that if you "add" process in, now the same system would cost them $110. Only a neophyte could claim differently right?

Now that sounds like a pretty good argument eh? So, contrary my advice (which happens more than you might think) the CIO ordered a study to determine how large the overhead was to implement the new process. They dedicated a team for two weeks and they worked round-the-clock to document their findings. You know what they found? Nothing. Zip. Nada. They were not able to attach an overhead cost to the process because they were not able to determine what the actual cost to develop software was to begin with.

Sure, they knew what was budgeted, and they knew if the project had to "go back to the well" for more (it happens often), but what they didn't know were things like how much re-work ocurred, how many defects caused the developers time and energy, and even whether or not the system met the requirements of the business community. Heck, they weren't even sure what features the system contained in it when it was delivered.

You see, the perception of speed and cost are typically only that ... perceptions. If I can call a developer on the phone and get a change "slipstreamed" into the software, isn't that better, more efficient, faster, and easier than going through that pesky change control process? If I keep a design on my laptop isn't that easier than logging on to a control system and checking it out? Maybe once. But try to scale that up to even 5 developers and you're facing an entirely different situtation. How do we know projects are on time? Because the project manager with the best communicating skills (or the loudest) is always the one who is on time . . . or at least says they are.

This type of "black-box" software engineering is just bad for everyone. When no one knows what is actually happening inside the project they all make assumptions - and most of them are wrong.

When someone complains about overhead, what they're often saying is that you've asked them to change the way they do things, and their first reaction is to push back in whatever way they can.

Sure, you can over-engineer your process and make it worse, but let's assume for now that you have done an excellent job and it really is more efficient now.

How can the CMMI help you with this? You can start by positioning CMMI ML 2 as a "foundation" for managing projects across all relevant stakeholders and for information sharing and measurement of project performance as it is progressing though its project lifecycle. It will help provide that visibility into the black-box. In a way, it will give you a set of process tools and "levers" to begin getting an answer to that question "how do you know?"

A lot of good reasons to do this are listed in subsequent posts, but when you start to hear this common tune, it pays to start with the question: "how do you know?" and work from there. Chances are pretty good no one knows and that some of them are reacting to the change in a normal and understandable way.

Then again, how would you know?


www.broadswordsolutions.com

Our customer doesn't care about process and says it's just overhead. How do I respond to that?

Dear Appraiser:

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.


www.broadswordsolutions.com