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
No comments:
Post a Comment