CM Journal Articles Ordinary Exceptions
|
We could potentially end this article here with a discussion of planning. Six P’s save the day. Proper planning prevents p***-poor performance. Allowing time for problems to arise during each stage of the software development lifecycle (SDLC) would significantly reduce the potential for later fixes. Spending solid time on requirements and design would also help. But, we don’t always have those luxuries. We’re supporting business which strives to compete in the world and that means time matters. And we have to do it cost-effectively. So we too must compromise. But such compromises are often expensive. Code is pushed to production before it’s really ready, knowing we can deliver fixes later. That means additional merges back into other development streams for us. Increased development time. More regression testing. Later projects are paying the price for the late fixes. As mentioned before the number one cause in the organizations I’ve seen is the timebox bandit. Quality doesn’t always follow the desired schedule. Time to market is crucial and business just can’t wait. If we can deliver basic functionality, they’ll take it. We are knowingly pushing inadequate feature sets and known problems into the production environment, just to keep the business competitive. That’s acceptable if business and IT are speaking the same language. And we know they speak in dollar signs. The second biggest problem is in the identification of emergencies. And just for the record, deferred changes do not constitute emergencies. In one period, a group I shall not mention processed 74 emergencies. A periodic audit of those determined that fully 72 of them did not rate a “severity 1” identification and the changes could have gone in with scheduled implementations. So why does that happen? Because we pay people for short-sighted results. “Wow! Jane really performed, working all night to get that done. She works hard and should be rewarded for being so loyal to the company.” Was that loyalty? Certainly it was heroism (which is what we try to avoid). If she had stood up and said, “look, I’m working on something else that goes in next week and I can make the fix with that. We should wait because it’s much more cost effective and the ‘problem’ isn’t as significant as we are being told.” Would she have been given such accolades? Perhaps our “consumer culture” is pervading our SDLCs? Give me something quick, cheap and I can forget about it when the next emergency arrives. And btw, when are you going to stop patching things and just build a better system? But I digress… So does anyone know what the true costs of these delayed fixes are? Is anyone actually measuring them adequately? Is there a way to reduce cost and the coordination necessary to keep all the development projects up to speed? Are we doing our fiduciary duty in conveying those costs to the business? Let’s look at an example of a “quick fix” cost schedule. The real numbers are probably higher but it’s the thought that counts here.
First, I think it is incumbent on the emergency release to incorporate the merge costs rather than shift those to the other projects. Regular releases are project cost but emergencies should be identified outside that scope. Secondly, a lot of people would look at that number and say it’s a pittance compared to the losses being incurred or the size of the IT budget. Sure it’s an easy decision now. It’s always an easy decision with a gun to your head. But when should that decision have been made? What if we ran the numbers for when it could have been included in the original cost?
And what costs aren’t factored in? What about the lost productivity because Jane either went home at 8am to get some sleep or her eyes were too blurry to see straight. What outstanding items are not being worked on because everyone else was busy doing the “Emergency Square-dance”? Frustration? Moral? People who saw the issue coming but weren’t heard aren’t the ones doing the backslapping and handshaking. I’m sure they’d rather work for a more “professional” company. And what about off-hour work? Who pays lighting and air conditioning? There are more costs here than we typically convey. Costs that are being assimilated by someone. The saying is that the customer is always right. And it’s our fiduciary duty to ensure that the customer realizes the costs involved. Perhaps my numbers are not accurate for you but it’s a way of starting the guestimate. Every delayed implementation is worth $2000. Sooner or later those become real numbers. Sooner or later it’s the difference between working here and seeing work done from India, China, or Singapore. If we can adequately assign these costs and then provide business with the analysis of the past year, we could probably say they spent $100,000, or in my case $140,000 that didn’t need to be spent. While I’d like to believe the gun would point in another direction, the likely question is why IT is so expensive. But that’s another discussion. Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala 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.
Set as favorite
Bookmark
Email this
Hits: 5695 Trackback(0)Comments (0)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Last Updated on Sunday, 05 August 2007 16:19 |
TrackBack URI for this entry
Subscribe to this comment's feed