Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: SMacCarth
New Today: 55
New Yesterday: 79
Overall: 144690

People Online:
Visitors: 57
Members: 5
Total: 62 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

When is an RFC Submitted? Before or After the Work?

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
eddiel
Newbie
Newbie


Joined: Jan 04, 2011
Posts: 6
Location: Central Virginia, USA

PostPosted: Wed Jan 05, 2011 4:11 am    Post subject: When is an RFC Submitted? Before or After the Work? Reply with quote

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?

Thank you in advance for your reply. Smile
Back to top
View user's profile Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3312
Location: London, UK

PostPosted: Wed Jan 05, 2011 5:58 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Jan 05, 2011 8:54 pm    Post subject: Reply with quote

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 Smile ) 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 Rolling Eyes Rolling Eyes Rolling Eyes
_________________
"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
Back to top
View user's profile Send e-mail
eddiel
Newbie
Newbie


Joined: Jan 04, 2011
Posts: 6
Location: Central Virginia, USA

PostPosted: Wed Jan 05, 2011 11:41 pm    Post subject: Reply with quote

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 Smile ) 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. Smile
Back to top
View user's profile Visit poster's website
eddiel
Newbie
Newbie


Joined: Jan 04, 2011
Posts: 6
Location: Central Virginia, USA

PostPosted: Wed Jan 05, 2011 11:43 pm    Post subject: Reply with quote

UKVIKING wrote:
Arrrgh


Don't "arrrgh" me, young man. I'm just asking a question. Smile

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.
Back to top
View user's profile Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3312
Location: London, UK

PostPosted: Thu Jan 06, 2011 12:59 am    Post subject: Reply with quote

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
Back to top
View user's profile
eddiel
Newbie
Newbie


Joined: Jan 04, 2011
Posts: 6
Location: Central Virginia, USA

PostPosted: Thu Jan 06, 2011 1:14 am    Post subject: Reply with quote

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.
Back to top
View user's profile Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3312
Location: London, UK

PostPosted: Thu Jan 06, 2011 2:51 am    Post subject: Reply with quote

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
Back to top
View user's profile
eddiel
Newbie
Newbie


Joined: Jan 04, 2011
Posts: 6
Location: Central Virginia, USA

PostPosted: Thu Jan 06, 2011 4:30 am    Post subject: Reply with quote

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".
Back to top
View user's profile Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3312
Location: London, UK

PostPosted: Thu Jan 06, 2011 6:50 pm    Post subject: Reply with quote

Eddiel

The first that needs to get done is the change management process, procedure and policy document needs to get drafted

Please also note that I am a Change / Release Manager and I dont manage teams - wintel etc. This is what I do and expect to be done

However, I have had people bring their work to me for approval with very little information and I shoot it down faster than you can imagine

Then I go to the mgmt
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jan 06, 2011 8:37 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
eddiel
Newbie
Newbie


Joined: Jan 04, 2011
Posts: 6
Location: Central Virginia, USA

PostPosted: Fri Jan 07, 2011 12:18 am    Post subject: Reply with quote

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. Smile
Back to top
View user's profile Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3312
Location: London, UK

PostPosted: Fri Jan 07, 2011 1:37 am    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.