Change, Release, and Projects: Difficult interfaces (Part 2)
Reasons for this situation
As already mentioned several times, ignoring similarities between both processes leads to having other frameworks fill the gaps, whose responses are not always comparable since their scopes and philosophies are so different.
There are also historical splits in the purpose of their activities. As mentioned before, Design departments rarely accept Release constraints easily. But this chapter gives the opportunity to illustrate a larger difficulty ranging from Business Units behaviors to IT departments difficulties:
► During Design stage, Business Units put pressure on Design departments to deliver developments as soon as possible, independently of operability precautions
► During Run stage, the same Business Units demand a high quality service which cannot be provided because of insufficient embedded quality. In this case, the “customer” is somehow amnesic about their previous demands
As long as the Development department and the IT operation department act as two independent suppliers instead of contributors to a same IT Service (one as designer and the other as operator), customers can exploit system inconsistencies and flaws, more or less intentionally. It is indispensable to build IT Service as a whole set, whose lifecycle upstream stages merely prepare the quality of downstream stages. Today, everybody acts as if each party produced a different product, whereas they basically share a contribution to the production of a single deliverable: the IT Service. Which leads the author to stress the capacity of the ITIL framework to forward this message better than Project frameworks do, because they produce on the one hand an Information System and on the other hand Services (meaning “deliverables”).
Copyright © 2013 - PRACT Publishing