cost, we can then relate that to labor burn rates and show a reasonably accurate cost comparison for a new tool.
It's also no surprise to many of us that a small percentage of individuals seem to cause a disproportionate amount of workload for others. In a recent example, we noted one release request that was followed by 16 updates, not including testing issues that were corrected. In a perfect world, we'd see 1 request that moves through the cycle with no updates. Obviously that's not always possible but 16 corrections for one initial request is entirely unacceptable to the organization. That type of information needs to be filtered back to at least the line manager so that appropriate steps can be take to train or encourage individuals with frequent issues.
No doubt this is a touchy issue and people will have legitimate (or not) reasons for the events. Few want to be the cause of someone else's call on the carpet but sometimes that's just what is needed to prevent recurrences and restore balance. Occasionally, process gets out of balance because one group doesn't recognize its impact on the rest of the company. The only way to create the whiney/temper tantrum child is consistently indulging poor behavior and it's unfortunately true in the corporate world as well. Statements like "Well, we could never get the developers to do XXXX" not only encourages poor behavior, it increases workload for others down the line. We should be able to identify the extra steps required and track them. That's not to specifically pick on developers since all areas have such nuggets but rather to note that if we aren't holding people accountable for work, they often won't be. We can use focused reporting to show how those missed opportunities are costing the organization real money.
We know that issues uncovered later in the lifecycle are more expensive to address than early ones. And many of the issues have indefinable costs, like damage to the client
relationship for missed dates or failed functionality. In many organizations, issues are treated the same across the lifecycle rather than highlighted by timescale. If we see as many or more issues in a later testing environment as we did in the initial test environment, we either have environment discrepancies or the environments are not appropriately controlled from configuration or code perspectives. We can push information like that up the chain to help get the funding necessary to make environments more equal, if that's the case.
Focusing the Lens
We're often asked to provide transparency in the form of reporting (or tool access) to upper management. With just a bit of extra work we can capture data in a way that isn't
just activity related but process related as well. We can focus the flashlight lens on areas that consistently slow down the lifecycle and reduce efficiency. We can generate real cost/benefit data to justify better tools or revamped processes. IT Governance isn't just about seeing work concluded successfully, it's also about getting there efficiently. We can use our tools and processes to help focus the lens in the right directions.
Randy Wagner is a Contributing Editor for CM Crossroads and Senior Configuration Manager with EFD in Sunrise, FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com