For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - When is an RFC Submitted? Before or After the Work?
Joined: Jan 04, 2011 Posts: 6 Location: Central Virginia, USA
Posted: Wed Jan 05, 2011 4:11 am Post subject: When is an RFC Submitted? Before or After the Work?
My university is adopting ITIL-based processes and using a tool to implement its workflow. We had a meeting today with some rather loud disagreement as to when an RFC was supposed to be submitted for a change.
Me, representing software development, argued that an RFC should be submitted to sort of get "permission" from the Change Manager and CAB to begin the work for a change. Operations rather loudly argued that the RFC should only be submitted when a change is all ready to be deployed/implemented/installed. In other words, I didn't want to commit resources for a change that might get disapproved and operations wanted to do the work and then present their case to the CAB.
What is the more normal or ITIL-compliant approach?
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Wed Jan 05, 2011 5:58 pm Post subject:
Arrrgh
Does any one know what ITIL is for any more
For what reason is the university adopting ITIL Based processes ?
Where is the ITIL based processes going to be used
As ITIL is for managing IT services, I would, expect that is, presume that the unviersity is trying to improve the services in the IT Department for all the students/staff - incident mgmt etc
As for you, eddiel, Software Development is NOT managing IT services per se; therefore, ITIL does not come close to you until certain conditions are met
1 - a service that you wrote - application, applet, etc - has been released to the general users for use. It is live and in use.
2 - Incident management comes in when it dont work as it should
3 - Defect management comes in when there is a flaw in the application and it needs fixing - then as part of the solution for the defect/incident, you follow the software development lifecycle and the internal softwasre configuration controls to write the solution, test the solution and deploy the solution to the general population - that involves release management, configuration and of course change management.
4 - once you get ready to deploy the tested solution, and in accordance with your org's CM policy, a RFC, Change Request, a CR or whatever you call is raised and then discussed at the Change Advisory board to determine when the solution can be deployed so that a) the users are NOT inconvienced and b) in an apprpriate window
5 - Your argument you were having about when to raise the RFC is mixing solution development terminology, project management terminology and operational management terminology (ITIL)
The last couple of questions are as follows
If your university wants to use ITIL, does it have any ITIL certified (beyodn foundation) staff who have experience implementing IT Service manageemnt usign ITIL better practices?
If so, why not ask them first for guidance
If not, why not _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Jan 05, 2011 8:54 pm Post subject:
Before I start, I'll address the final form of your question. I have no idea what is more normal, but equally, I have no idea whether that which is more normal is best (either in situ or for your situation). And, although I suspect you asked with some savvy, there is no such thing as ITIL-compliant.
Now, I'm going to appear to be in disagreement with John here. But I'm not really. I wouldn't dare.
You confined (by implication) your question to software development of changes, meaning, as I took it, changes to currently running applications. however I believe my answer is also valid for the development of new systems - which are of course also changes.
You expressed concern over the risk of consuming resources to no end because the change might be rejected and this is key. It might be rejected as something wholly unacceptable or as infeasible; it might be rejected sending you scurrying back to the drawing board; etc.
In the old days, development used to talk to the customers, design a product and, at the last minute, pour it down operations throat with the imperative that they had already promised it to the customers by today at the latest.
When a change is first perceived as required or desirable, many things have to be done to achieve it and change management has a hand in them all.
Do you buy new hardware before confirming it is compatible with your infrastructure and you have sufficient capacity (floor space, electricity, cooling towers ) etc.? - No.
Do you commission software without ensuring it will be designed appropriately for your environment (operating interfaces, local GUI conventions, performance characteristics, availability of suitably trained support staff, commitment to maintenance and further development? No and this is regardless of whether it is in-house or not.
So change management begins at inception. and continues, providing scrutiny and control through all phases until the change is bedded in, having passed all its acceptance criteria and the post-change review has been completed.
However, the RFC, as we know it, lies at the door to service delivery. And therefore, if it is raised before finalizing specification and procurement, you are involving service delivery from inception. This is something that Operations Managers screamed for in the old days and is exactly what I would do (if someone were to give me a job).
If the RFC is not raised until development and testing are complete, then you need to do other things to mitigate the risks. Things such as consult with Service Management throughout, ensuring your work conforms to service delivery requirements and that other changes taking place do not lead to problems either for them or for your change. It can be done, but if it is consistently done well then, in effect, you have a seamless change management system in which the actual RFC is simply to ensure that all has been properly prepared for implementation, to determine the scheduling and to control the implementation planning and actions (including regression planning).
You will see that I have come in a circle, because that is what service management change management is all about. If things are done properly, there should be no risk of rejection of such a change. but any wildcat development will be stopped in its tracks by its lack of conformity to requirements.
I like to see control be both conscious and formal and therefore I would put the RFC at the very beginning, to ensure that everyone was on-board [I seem to be cliché ridden today!], that all aspects of the specification were covered appropriately, that all necessary approvals were identified, that all stage checks were agreed, etc. (yes I know this is project management, but if the specifications for how to do the project come from the change management process, they have a chance of being right).
When it comes time to implement, I would reconvene the change board to do the necessary at that time.
This has got a bit long and I'm not sure I've done it justice, but hopefully the idea is in there somewhere _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Jan 04, 2011 Posts: 6 Location: Central Virginia, USA
Posted: Wed Jan 05, 2011 11:41 pm Post subject:
Quote:
You confined (by implication) your question to software development of changes, meaning, as I took it, changes to currently running applications. however I believe my answer is also valid for the development of new systems - which are of course also changes.
Our university does do a lot of in-house development, but our discussion was all-inclusive of all kinds of production changes, both the kind that would result from a software development effort and, say, the kinds of changes system administrators might do without a customer's request.
We were discussing our adoption of a general model for change management and were using a "best practices" workflow we received from our tool vendor as the topic of discussion. That workflow created tasks for planning, building, testing, and implementation AFTER CAB approval for the change. Operations (the sysadmins) were complaining that by the time they were asking for CAB approval all the "building" had been done already, and I was suggesting that I thought the CAB's approval should come before the building, since it was the CAB's job to evaluate the business justification for the change.
Quote:
You expressed concern over the risk of consuming resources to no end because the change might be rejected and this is key. It might be rejected as something wholly unacceptable or as infeasible; it might be rejected sending you scurrying back to the drawing board; etc.
In the old days, development used to talk to the customers, design a product and, at the last minute, pour it down operations throat with the imperative that they had already promised it to the customers by today at the latest.
When a change is first perceived as required or desirable, many things have to be done to achieve it and change management has a hand in them all.
This was my point. Operations was pushing back, saying that they didn't want all that transparency to them just "doing their jobs" by finding patches, researching upgrades, etc. They were asserting that their job in doing these things was different than what software development was doing... and I was disagreeing with them.
Quote:
Do you buy new hardware before confirming it is compatible with your infrastructure and you have sufficient capacity (floor space, electricity, cooling towers ) etc.? - No.
Do you commission software without ensuring it will be designed appropriately for your environment (operating interfaces, local GUI conventions, performance characteristics, availability of suitably trained support staff, commitment to maintenance and further development? No and this is regardless of whether it is in-house or not.
So change management begins at inception. and continues, providing scrutiny and control through all phases until the change is bedded in, having passed all its acceptance criteria and the post-change review has been completed.
However, the RFC, as we know it, lies at the door to service delivery. And therefore, if it is raised before finalizing specification and procurement, you are involving service delivery from inception. This is something that Operations Managers screamed for in the old days and is exactly what I would do (if someone were to give me a job).
Then you seem to be ageeing with the point I was making in our meeting, and the very point that the operations managers were pushing back on. They did not want a CAB telling them whether or not they should pursue an effort (like procurring a new tool or hardware improvements). They just wanted the CAB to tell them when they could install them. I said they were, then, pursuing IBM's change management model and not ITIL's, and I guess my question in this topic is whether or not I was correct.
Quote:
If the RFC is not raised until development and testing are complete, then you need to do other things to mitigate the risks. Things such as consult with Service Management throughout, ensuring your work conforms to service delivery requirements and that other changes taking place do not lead to problems either for them or for your change. It can be done, but if it is consistently done well then, in effect, you have a seamless change management system in which the actual RFC is simply to ensure that all has been properly prepared for implementation, to determine the scheduling and to control the implementation planning and actions (including regression planning).
We do this for software development, and are getting better at it all the time, through a project management and software development model. I was asking, if not through change management, how operations was going to track the same kind of effort from their own teams.
Quote:
I like to see control be both conscious and formal and therefore I would put the RFC at the very beginning, to ensure that everyone was on-board [I seem to be cliché ridden today!], that all aspects of the specification were covered appropriately, that all necessary approvals were identified, that all stage checks were agreed, etc. (yes I know this is project management, but if the specifications for how to do the project come from the change management process, they have a chance of being right).
When it comes time to implement, I would reconvene the change board to do the necessary at that time.
Then it appears that you are supporting my position, though I won't be arrogant and assume that I understood you correctly in the first pass.
Joined: Jan 04, 2011 Posts: 6 Location: Central Virginia, USA
Posted: Wed Jan 05, 2011 11:43 pm Post subject:
UKVIKING wrote:
Arrrgh
Don't "arrrgh" me, young man. I'm just asking a question.
Quote:
If your university wants to use ITIL, does it have any ITIL certified (beyodn foundation) staff who have experience implementing IT Service manageemnt usign ITIL better practices?
About 30 of us have the basic certification, though it is obvious that many of us came out of that class with some different interpretations.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Thu Jan 06, 2011 12:59 am Post subject:
Eddiel
I will arrgh whomever I like. And I am not a young man. I have most likely been in IT longer than you have been alive. I am the defacto GoG here in the forum. I earned it
As I suspected, you are a group of freshly minted ITIL Foundation certificate holders. Are you all v3 certified or some are v2 certified
The problem is that you are looking at things in the same way from different angles. or different ways same angle
Existing services to the customers (professors, staff, students)
The CM process needs to be focused on reducing the amount of arrgh that the users have - deploy in announced windows to production, test where appropriate before, approve and schedule before hand, identify standard, low impact low risk changes and operational work that seem to be changes but are not
New Services or changes to the existing services
this process must marry into the above process - concentrating on ensure the release and testing and documentation portions are done before introducing into the above mix
One of the major issues I have found in my career in IT, Change mgmt is that every one thinks a project change request is the same as a operational change request
An operational change request is upgrade O/S from Windows 2000 SP1 to SP2
A project change request is develop a course management system to request classes
The former does not need separate funding etc and development resources to be approved before hand and schedule / plannign for the deployment to production ( months away)
The latter does
both need testing before production deployment
the amount of work for the operational change may be smaller for the testing but larger for the deployment
both may have complex deployment plans - in different ways
The bottom line is
ITIL is basically telling you this
1 - document how you do it
2 - make it clear to all #1
3 - have control points - well documented
and finally
If a process is documented and it works for you, and the auditor are happy and every one knows where it is when it is there, then the process is better practice ( you can always get better) and therefore ITIL like
ITIL is a book full of recommendations and guidance from many years of trial and errors
It is NOT a strict set of instructions that says...
You use it to formulate what your org needs
The hard part is when you got 20 people who learned who to cook a pie and all want to cook the pie and you only got 1 stove and pie plan
You get no pie and 20 frustrated chefs _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 04, 2011 Posts: 6 Location: Central Virginia, USA
Posted: Thu Jan 06, 2011 1:14 am Post subject:
UKVIKING wrote:
Eddiel
I will arrgh whomever I like. And I am not a young man. I have most likely been in IT longer than you have been alive. I am the defacto GoG here in the forum. I earned it
Oh... well, then, arrgh me at will then, I guess.
So, John, if you were going to write an RFC for an operational change, would you do it before or after you had spent 40 hours building and testing the change? That's essentially my question.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Thu Jan 06, 2011 2:51 am Post subject:
You wont liek the answer
It depends.
It depends on the type of operational change
If the change can be done by the support teams as part of their work - Windows team for an example -
If the op change is to upgrade to SP1 to SP2 on the workstationss
if I have a test environment that is similar to the general setup, I would do the following
Raise a RFC for the CAB informing of the plan to upgrade SP1 to SP2. I would have the deployment plan (production) and schedule
I would have the test plan and the key users and applications to test (with sing offs)
I would conduct my testing in my test environment if I have one.
I would go to the CAB and describe my change with all the risks etc and the planned deployment dates if testing is successful
From the CAB point of view
The CAB would examine / interogate me - Dragon's Den reference (OK ?) - as to the deployment plan, back out plan, test plan, back out triggers, schedule of deployment and test plan as well as when, the communication to the users etc
I will tell them the testing is on going and whatkey applications have to be useable after the SP upgrade.
I most likely will be told to come back once testing has been done
I complete successfully testing of the patch - all key app are signed off - commercial and custom apps - and go back to the CAB and get it approved to be scheduled in accordance with the plan
Once approved by the CAB, I deploy as they tell me - by region, office, team, department, etc, laptop, desktop, etc.
If there are issues with non standard apps, I can point to the CAB and the rigorous testing done and the key apps passed and the CAB approval. I can work with the specific teams to solve their non standard apps issues
- if that is part of my remit else they need to move to standard apps - as noted by the IT Department
------------------
Incident / Problem Solution Operational change
I am part of the application support team that has a development team. We are tasked with fixing a minor issue in the custom app where the main screen does not show one field in the right place or with the right data. The work around is handled by the application user - key user group
We have a defect mgmt tool / tracker referenceing to the incident / problem record. We, as part of our day-to-day role, make minor app code changes.
We complete the solution.
We test the solution in a test environment where we can recreate the incident / problem. We get key users to test / verify the solution
Once this has been tested or is near completion of successful testing, I raise the RFC to bring this to the CAB and have it approved to deploy to production
The same requirements -deployment, test, back out, implementation - time window, communication is still needed
once approved and scheduled, I deploy to the app
Once deployed, I check with key users to verify it is working
I work with the IM and PM teams to close their tickets and my defect _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 04, 2011 Posts: 6 Location: Central Virginia, USA
Posted: Thu Jan 06, 2011 4:30 am Post subject:
Thanks, John. I think your example demonstrates what I was trying to say to the operations engineers: the CAB is involved in a change that IT operations wants to make (the windows patch) before they are ready to deploy the change. Some of our operational teams only want the CAB to be involved as a last-minute opportunity to reschedue the implementation of the change to production. The stated reason was that they do not want "that kind of transparency into the work we are doing".
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Jan 06, 2011 8:37 pm Post subject:
eddiel wrote:
I was asking, if not through change management, how operations was going to track the same kind of effort from their own teams.
I won't interfere in your love match with John, as you seem to be reaching an understanding. But I'll just make one small point.
"change management" is how changes are managed whether it is through a formally labelled process or otherwise. When you step back from things like the ITIL so-called framework, you can still ask the question: how are changes being managed? And then you can scrutinize Operations or Development or any other unit. The case for having an all embracing shape to the change processes is that , in the end, the risks are to the customers through their use of the services. How you best design and apply this across your organization very much depends on circumstances, and this is exactly what John said.
The short answer to the question is that however operations manage this effort, it is change management, even if it is not using Change Management.
One last caveat. If you are all new to ITIL, don't try to run too soon. A half decent stab at these issues can always be improved or even replaced and probably quicker than you can get to the perfect system first go. The more sophisticated you try to be without the background experience, understanding and culture, the more likely it will all go wrong and lose credibility before it is properly going.
Good luck. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Jan 04, 2011 Posts: 6 Location: Central Virginia, USA
Posted: Fri Jan 07, 2011 12:18 am Post subject:
UKVIKING wrote:
The first that needs to get done is the change management process, procedure and policy document needs to get drafted
That's what we're doing, and that's where the debates are coming from.
I have implemented software release management in a handful of companies before, just not under the "umbrella" of ITIL definitions, though the process put together resembled what ITIL defines. In those other companies, we had meetings before software was changed or written to discuss and argue about the priorities of software change requests (bugs and enhancements) that would be gathered together into a software release. These meetings consisted of representatives from all parties, much like ITIL defines the CAB, and were always very colorful as the arguments were had to determine the business justification and priority of each change. We had a software quality process that all releases went through.
After the changes were made, I put together a lot of documentation to verify that what we had agreed to in the beginning is what we actually had, and deployment dates were confirmed.
There were two people managing this process: one who was working at the front end with the representatives (the "CAB"), and one who was coordinating the execution of the process and its delivery at the end. I think that model is close to what ITIL is suggesting: our guy at the beginning was the change manager and the guy at the end was the release manager (according to ITIL's definitions, not ours).
Our operations group in my current company (they don't write software, they update tools, hardware, operating systems, etc.) in IT is having a hard time adjusting to thinking about a culture where they have to address the CAB and a change manager at the front of the process. They want to simply take a completed and ready to go change to someone to get permission to deploy AFTER they have done all the work. Their argument is that the managers of the operations engineers should be trusted to do due diligence without being required to be scrutinized by a CAB.
I'm pushing back on that idea. I do see that their work effort may not need as much scrutiny or be as complex as a software effort. I just do see that the plan for their change should be monitored just as the software efforts are.
And John, if you were in IT before I was born you were using an abacus.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Fri Jan 07, 2011 1:37 am Post subject:
I see your problem now
The solution is as follows
1 -the CM - or poor sod doing it - writes the Policy documents explaining how the process is to be don
2 - the CM sends out policy for comments with a short response window
3 - the CM gets snr mgmt sign off
4 - first CAB, you let the people come to the CAB thinking the way they have been and then
....
the change manager rips them apart and sends them back to the drawing board
sigh..
Actually Diarmid is right -- however you want to write it up to start is up to you all.
once in place, review every six months
key points, test before deployment, approval before deployment, good installation - no errors, good communication to users
how ya do it... well that is the art
Asto my age.. abacus no.
VAX 11/70, PDP 11, were what i used
I was stationed at Fort George G Meade at the ssssh as i was a cryptographer in 1983
I got to deal with TCP/IP 3 month after it went public when I joined BBN to manage ARPAnet & MILnet
Since then... well things have changed .. and not changed _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
