I have been tasked to produce and RFC e-form to allow members of the IS department to raise RFC's via our corporate intranet. This e-form will incorporate workflow.

Our company has an agreed an 'at risk' day of Tuesday, when we release all approved changes. The CAB is scheduled to meet each Wednesday to approve/reject all new requests and to review previous weeks releases.

Currently an RFC is a request in an e-mail to our Service Delivery Manager (Order) seeking approval. Fortunately our organisation has now embraced ITIL, hence my development.

What I don't want to do is make the RFC e-form too complex. I want to include in the RFC links to any Incidents/Problems from our Service Desk and link to the CMDB via a unique CI number.

Have any of the other members of this forum undergone a similar development.

I would be keen to learn from your experiences. How often does your CAB meet? How long do you wait post implementation to review the change? And especially how to manage teams that circumvent the Change Management process and release things on the QT!

If anyone has a RFC template (paper based or e-form) they are willing to share, it would be appreciated.

From your post, it sounds like you're reinventing the wheel, as many vendors have already built web based solutions for tracking and managing Changes.

It also sounds like you don't know what you're getting yourself into. What you're calling "simplied" is actually far more complicated than you think. If you make the form too simple it will truly be worthless but if you try to capture everything you really need and provide the "appropriate" linkages to everything else you need, as well as provide all the right features and functionality, you will get yourself into a much larger development effort than you truly expected.

Unless your company is in the business of building and selling Change Management systems, why would they want to waste their valuable resources on building solutions for things that already exist? Why don't you simply just look to buy a tool that does it all for you, so you can go back to working on the company's realy problems?

FYI... You will build the form, then you will realize it's not integrated into other tools, then you will realize that you don't have reports built around it, then you will realize that you need for more static and dynamic seed data then you thought, then you will realize that your data model will be very weak and limited, then you will realize that you don't have enough features in the UI, then you will realize that you have a highly limited toy that will have cost you far more than if you just bought something that you could have implemented in your environment in a fraction of the time...

Building simple applications is not simple. In this day and age, "simple" solutions are very complicated. Don't get caught up in the trap of "Gee, I think I'll build a simple web form." If you do, you'll be many years behind your competition and the rest of the world. You may not want to waste expensive resources on using modern technology to build a stone tablet and a chisel...

Unfortunately within the public sector in particular the police environment off the self packages rarely 'deal' with police business.

I am a great believer of Keep It Simple Stupid (KISS) and not re-inventing the wheel, hence my request for examples of RFC's.

As my organisation has just embraced ITIL we are starting in small chunks (how do you eat an elephant?).

The big difficulty, which you pointed out, is integration with other systems. Our service desk application uses Oracle, our CMDB uses Lotus Domino so a Java based web application suits our technical architecture. As we are moving towards portal technologies to obtain interoperability our final goal is achievable.

Building simple applications is simple if they are managed properly using Prince 2 methodology

All I need now is some templates so that I can cancel the recruitment of a wheelwright

Unfortunately within the public sector in particular the police environment off the self packages rarely 'deal' with police business.

Feel free to share what you're doing that is different than any other enterprise in the world that's implementing ITIL. ITIL is all about "consistency" across all of IT. If you're doing something different, chances are you're doing something wrong.

Quote:

I am a great believer of Keep It Simple Stupid (KISS) and not re-inventing the wheel, hence my request for examples of RFC's.

As my organisation has just embraced ITIL we are starting in small chunks (how do you eat an elephant?).

There is nothing more simple than turning on what someone else has already built and hosts for you, is there?

My recommendation is that you're very careful about your approach. The reality is that most enterprises have no real experience in implementing ITIL solutions, and if you're just staring out with ITIL, as you mention in your post, there's a high probability that your enterprise has no real experience with it, either. As a result, such enterprises know they have to get to "an elephant" but have never created one before and think that they can do it one small piece at a time. The end result is always the same... after piecemealing solutions together, they usually wind up with something that is far from the elephant they had in mind and far from a good, solid, and affordable solution.

Quote:

The big difficulty, which you pointed out, is integration with other systems. Our service desk application uses Oracle, our CMDB uses Lotus Domino so a Java based web application suits our technical architecture. As we are moving towards portal technologies to obtain interoperability our final goal is achievable.

You are already on your way to having something that is far from the "elephant". Throw out your eRFC solution and your spamming your enterprise with Yet Another Tool (YAT) that will have a cost to support, enhance, and integrate... a cost that your enterprise really doesn't want if it thinks about it.

Quote:

Building simple applications is simple if they are managed properly using Prince 2 methodology

I'd be careful about believing this. You can follow Prince 2 or any other methodology to a tee, but if you don't know how to properly design and leverage advanced and complicated technologies to build highly distributed solutions, you will be far from a simple application. In this day and age, to build a simple 3 tier web application requires "many" different technologies, paradigms, protocols, etc. to be implemented. And, as a result will require many different resources with many different expertise requirements to build and support. Any CIO will understand this.

Quote:

All I need now is some templates so that I can cancel the recruitment of a wheelwright

You seem adamant to implement what already exists. May I please ask why? Doesn't your enterprise have more important things for you to be working on?

Wish I could help but I can't. We're currently using HPOpenview Service Desk for Change & Config (not that the 2 actually have any useful connection here!). Previously we had a homegrown LotusNotes app.
An E-form sounds like a good idea if it will have high acceptance, accessibility & availability. (Sorry Frank!) I especially like the link to Config (required) and Incident (nice to have).

In terms of ITIL, our organisation is not doing anything different to other organisations. My comment on rarely meeting the needs of the police environment was probably too general. In the past we have purchased applications that meet the 80% functionality, then spending additional funding to obtain the other 20% by asking suppliers to modify the code.

I know that with full management 'buy in' we're not going to implement ITIL over night. So we are taking it (probably like most organisations) in bite size chunks. Any development would use re-usable object code to allow greater flexibility. You wouldn't develop one large class to do everything; you'd create a package of re-usable classes, building blocks for future developments.

In this day and age, developing a three-tier application is easy with rapid application development tools. HTTP, XML, SOAP with a RDMS, isn't rocket science.

Sometimes (If you have the right resources and skills) to develop in-house, you get exactly what the business needs at a lower TCO than off the self packages. IT delivers the tools/services necessary for staff to carry out their duty. As a public sector organisation, we are spending public money. We make no profit; we deliver a service to our community. Therefore our philosophy may be different.

(Sorry Frank!) I especially like the link to Config (required) and Incident (nice to have).

Don't be sorry. I didn't say I don't like the idea of an eForm. I do, very much so. I said I wouldn't recommend building one, from scratch, especially if your intent is to integrate it to one or more dabases and other back end systems and information. My reason is that an eForm for RFC submission already exists with a number of different tools out there. Not only do the forms exist but so do the integrations and all the other features that you'll need, like the reports you'll need to generate for metrics, based on all the submission and management information. If you're building your own ITIL tools, you're definitely reinventing the wheel. And, since ITIL is all about not reinventing the wheel, I'm simply pointing out that if it exists already it's probably worth not repeating.

You mention that your Service Desk uses Remedy. Purely assuming from this that you are using the HelpDesk module for the logging of incidents, requests and problems. Are you using Remedy's change module? If so, I believe this module gives you the ability to use a Web Based client, meaning that users could raise their own changes via this client. No need for a separate form, or any additional processes per se. Would need some effective job instructions, and perhaps a review of user access levels.

I know that with full management 'buy in' we're not going to implement ITIL over night. So we are taking it (probably like most organisations) in bite size chunks.

I would be careful about this. I will tell you from experience that comes from going into many companies who have already implemented pieces of and/or are in the process of implementing pieces of ITIL, that this approach fails for most enterprises. We find that it's the approach taken when the implementers don't know how all of the ITIL pieces fit together, with themselves and with other operational areas of the enterprise. The reality is that most home grown, non-core applications that are built in house are usually long term problems for most enterprises. If you don't believe this now, let's talk in about 5 to 7 years.

Quote:

Any development would use re-usable object code to allow greater flexibility. You wouldn't develop one large class to do everything; you'd create a package of re-usable classes, building blocks for future developments.

In this day and age, developing a three-tier application is easy with rapid application development tools. HTTP, XML, SOAP with a RDMS, isn't rocket science.

Sometimes (If you have the right resources and skills) to develop in-house, you get exactly what the business needs at a lower TCO than off the self packages. IT delivers the tools/services necessary for staff to carry out their duty. As a public sector organisation, we are spending public money. We make no profit; we deliver a service to our community. Therefore our philosophy may be different.

A few things on this...

First, if you build something in house, you create what's considered a "perpetual support need". What this means is that if you build an app using those technologies you listed, you will require your enterprise to keep staff on hand, that have those skills, to continue to support that application through it's lifecycle, out to it's eventual decommission. You've just encumbered your enterprise. No enterprise wants to be in the business of supporting anything at all that's not their core business. If you don't believe this statement, talk to any experienced leaders... CEOs, CIOs, CTOs, COOs, etc. If they wanted to support things that are not their core expertise they wouldn't have already outsourced things like their benefits, payroll, accounting, legal, internet service, etc. A smart leader knows the impact of building, buying, install, and maintaining things, yourself. The TCO is that they have to keep at least "you" on board to support everything, not to mention pay for the entire infrastructure and any services that the application might leverage.

Second, I'm fully aware of and intimate with each and every one of the technologies you've listed. If you want to build a little toy, then yes I agree with you... go ahead and build a little web app that shows you are about 7 to 10 years behind everyone who is leveraging SaaS based solutions. You can definitely create a form to dump data to a set of simple tables in a database. By the time you build all of it for "one" form, test it, deploy it, and train to use it, customers of our own SaaS solution can simply turn on about 50 advanced and completely integrated tools that include thousands of forms, reports, visualizations, self generated objects, etc. They'll get more in one week, for a fraction of your cost, then you and an army of "qualified" developers will most likely be able to provide in 10 years. SaaS is a pretty interesting paradigm. If you haven't looked into it, yet, I suggest you do. It's purpose is to eliminate having developers build things that already exist. Enterprises just connect through a browser and run... freeing up the developer(s) to focus on more critical business problems.

To be honest, if you want to build a seriously "simple" and "usable" application, in this day and age, it will have to include things like:

Self generation of code, objects, and constructs, so you don't really need many developers to code things for you and can eliminate huge portions of your tools and infrastructure, and/or...

Hundreds of thousands of prepopulated static reference data records for on the fly user clasification and indexing of information, and/or...

Fully integrated and qualified searches through the use of indexing paradigms and self-synthesizing queries paradigms, so that users can find what they want, when they want it, how they want to find it, and/or...

Dynamic caching of objects through a dabase abstraction layer that decouples your object-oriented business model from your relational data model, so that you can deal with large user bases and large data volumes, and/or...

Highly dynamic reports and visualizations using advanced forms of JavaScript, like AJAX and prefuse visualization libraries (prefuse.org and visualcomplexity . com), so that the user can happily work in one place and not have to jump from tool to tool to tool, and/or...

Full pub/sub so that you can create dynamic bindings between your system and other systems and/or...

And much more that I won't bore you with...

Third, I have to say that reading your post and how you lay out a lesson for me, it appears you've made an assumption about what I do or don't know when it comes to design, implementation and delivery, without ever having really spoken with me. I recommend that you please not make assumptions about what I do or don't know about design and development of any kind. I have approximately 25 years of advanced design and development in highly distributed, large volume SW, Systems, Processes, and ASICs (computer chips). And, while I will never claim to know it all, you might be a little surprised to find out what I do or don't know and what my experience levels are.

But rather than getting into the details, I'll let you judge for yourself any time you're interested. You're always welcomed to a private demo of what we do so that you can understand what I'm saying, for yourself.

BTW, it is my opinion, based on my own experiences, that building a web form is not building a real application. It's building a very limited toy. In this day and age, building a truly usable app that scales for a distributed enterprise requires far more than I believe you are willing to admit. Simply take a look at everything listed in the following two links: TraverseIT. com/ it_ops.html, TraverseIT. com/ tech.html

This is not a small list. In fact it's huge. And, while you build one form at a time and make your enterprise more expensive to support and run, we simply eliminate the need for dedicated infrastructure and headcount by allowing customers to simply point their browsers to us and run, for a very low user based yearly fee. Our business model is to simply go into organizations, where developers are building tools, like you are, or where they know they need tools but haven't invested in any yet and show them what they get for their investment in 1 developer vs. what they get for a fraction of the cost of one developer, if they simply point their browsers to us. It's most often a pretty easy conversation.

It's always funny, too... When I deal with a developer, I always get statements like "That's not that hard. I can do that." (Usually denial about what it takes to do it all.) However, when I deal with an experienced leader, I always get statements like "There's no way a hundred developers could do that in 10 years, for me. Why would I try and compete with you?"

There's also another easy conversation with IT leaders. Just ask the question: "Do you want your expensive developer focusing on your non-core horizontal space and building what already exists or do you want him or her focusing on problems that improve your vertical core business?" What do you think that leader will say? I "never" get the answer: "I want him/her focusing on my non-core horizontal spaces (like ITIL)."

Finally, in your post you mentioned that you were in the public sector. I don't know where, but at all levels of government that we engage in, here in the states (city/municipality, county, state, federal, etc.) the primary push is to not build what you don't have to (i.e. to outsource it all to experts that are in the full time business of solving such problems and have the dedicated expertise to do so) so that public sector resources can focus directly on vertical core business problems. No public sector IT leader we've come in contact with is happy when their developers are building non-core things in house. I honestly do find that to be too consistent for it to be a coincidence. It appears that all public sector agencies, organizations, etc. that we deal with are not in the business of IT and if they're smart, they're typically trying to significantly reduce their IT footprint (staff, infrastructure, facilities, etc.) not increase it by building/buying, implementing, and supporting their own IT solutions.

Anyhow, it's been a pleasure exchanging information with you. I certainly hope you find it all useful.