I would have to agree with Ken Dietel, with his decision on implementing a more ITIL way of managing changes. Ken's company was constantly having to do Emergency Changes. He describes the problem as:
"The Software Engineering Institue's (SEI) Capability Maturity Model (CMM) ranking for a software process exhibiting these characteristics in maturity level one (the lowest of the five levels): 'characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.'"He then recommended that his company should move to a more informed way of managing changes in which he was able to, but he still had problems:
He goes on to say that:"All this work only brought this organization to a state I call 'informed anarchy'."
"Information about upcoming changes was beginning to be collected in a centralized location, available for anyone to go look up, but proactive communication was still occasionally lacking. Incidents still occurred with root causes which traced back to changes that affected something unanticipated, which could have been prevented if the right people knew about the change ahead of time. The process was still being significantly adjusted as it was being rolled out to more groups. Adherence to following the process was not always enforced."
Like I said at the start I agree with Ken, He enforced his work group to absorb the ITIL practices of Change Management, however, like he said, he still has a way to go before it's fully implemented.
No comments:
Post a Comment