the bubble, the pressure to improve is lessened. In the case of many organizations, where it escapes the sphere, what percolates up is that someone violated a process rule. To those outside the bubble, that can look like red tape holding back the heroes instead of truly seeing the process preventing the hero-wannabees from costing the company more in the long run. We need to be held visibly accountable and not sweep our repeated indiscretions under the rug. It makes us less of an organization.
That means allowing the light to pervade all areas of our lifecycle and all projects. Accountability is the evil twin of quality. If we build our processes to reflect that attitude of excellence and clear responsibility, and then build the tools around them, we can also export that data to show those outside the bubble that we repeatedly run efficiently and justify our requests for resources. CM integration to non-intrinsic software development tools is where we need to go in order to cross the bubble's membrane and provide the greatest benefit. And we don't have to reinvent the wheel to do that. CM tool writers can create an add-on interface or perhaps simply an open standard that management and executive tools can tie into. It's simple vertical integration. So we should be building interfaces to the server support systems and tying in the maintenance efforts. The SD LC does not end when a product goes to production but when it's retired from production.
From an external view, we're so busy perfecting our tools for our own benefit that we aren't serving the real customer, and for that we face uphill battles for new or better tools. The client is not our customer. It's our customer's customer. Senior management is our customer. Having awesome tools that completely control the SDLC but that few beyond our perimeter know or understand is too much like being the proverbial black hole they pour money into. If you are not part of the visible product, you are just part of the bill of materials where the only focus is cutting cost. Perceived value is as important as real value. Honestly, many of us are comfortable in IT because we rarely have the interpersonal skills for marketing. It's not how we're geared mentally. But that's exactly where we need to take this discipline. CM is incredibly valuable to an organization. Why not demonstrate it? Why not hand them easy tools to understand the issues we so desperately need them to know. A little self-promotion isn't such a bad thing.
One of the most consistent gripes of IT organizations I've been involved with and seen frequently commented on in journals is the lack of requirement stability or just the lack of requirements to start with. As heroes we try to take what the client wants and turn that into code, even when it's a little or a lot vague. Then we as a project team get hammered because defect rates skyrocket, testing takes longer than expected, and deliverable dates aren't met. We have to provide better metrics for our own safety and, more importantly, for the customer's expectation of quality. What percentage of defects are being dispositioned as misinterpretations of requirements? That would be indicative of the quality of the requirements/design documents, an IT internal issue. Comparatively, what number of change requests are coming through? That makes it obvious that the customer didn't know what they wanted but that IT has been working hard to meet their needs. Those are things we can do today but how do we push that up the chain? The tools need to be geared to both collecting that kind of information and making it easily presentable across project databases. Then we can get those traditional issues fixed more readily.
And that is the real issue. We have a TON of data. What