For more information about the Process Reference Model for IT, see the PRM-IT page. 

PRM-IT Frequently Asked Questions (FAQs)

1. Why doesn't PRM-IT use the ITIL® names "Access Management" and "Release and Deployment Management", but instead use "Identity and Access Management" and "Release Management" and "Deployment Management"?
2. Are all changes implemented in Release Management?
3. Where are new solutions created and existing solutions modified?
4. Why do changes sometimes go to IT Portfolio Management instead of going directly to Solution Development?
5. What is the relationship between a change request and a standard change?
6. Do incidents ever turn into problems?
7. Do any processes develop anything besides Solution Development?
8. What are the process frameworks?
9. What is the relationship between RUP and Solution Development?

1. Why doesn't PRM-IT use the ITIL names "Access Management" and "Release and Deployment Management", but instead use "Identity and Access Management" and "Release Management" and "Deployment Management"?

Access Management is only part of what is performed in that process.  Identity Management is an important area of functionality that must be performed.  PRM-IT emphasizes this important area by using it in the name of the process.

Release Management and Deployment Management are separate processes for two primary reasons.  First, Deployment Management involves a great deal of work, including transitioning to a different supplier.  In order to provide sufficient coverage of that type of work, the process is separate from Release Management. 

Second, some deployments are quite simple, including self-service deployments of IT-authorized software.  Changes that require such deployment should be able to go directly to Deployment Management without having to be concerned with Release Management considerations. 

2. Are all changes implemented in Release Management and Deployment Management?

No. It would be nice if it were that simple.

The ITIL documentation makes it clear that not all changes are implemented through Release and Deployment Management. The document is not entirely clear what types of changes are implemented using a release. In PRM-IT, this is defined within the Change Management Framework. The framework spells out when an approved change goes through Release Management and Deployment Management.

Release Management and Deployment Management are primarily for rolling out hardware and software within the infrastructure. They are not primarily for rolling out procedural changes or for correcting individual things within the infrastructure.

3. Where are new solutions created and existing solutions modified? What about small-scale software?

Solutions are created and modified in the process category called Solution Development. This category includes Solution Requirements, Solution Analysis and Design, Solution Build, Solution Test, and Solution Acceptance. This includes not just software and hardware built from scratch, but also existing software, hardware, and patches.

These processes are used regardless of whether this is a large solution or a very small solution. For smaller solutions, the trip through these processes should be quicker.

4. Why do changes sometimes go to IT Portfolio Management instead of going directly to Solution Development?

There is always a business aspect to any development project. Solution Development primarily addresses the technical aspects of a development project. However, before a development project is initiated, it must be determined if the project can be funded, can be properly staffed, and whether it makes good business sense. IT Portfolio Management makes that decision and precedes the processes of Solution Development.

5. What is the relationship between a change request and a standard change?

As described in the ITIL documentation, some proposed changes are so simple and routine that they are called a standard change or a preapproved change. These changes include things such as providing equipment to a new employee. Standard changes do not need to be processed by Change Management because they do not need to be assessed and authorized.  In general, users submit requests for standard changes to the IT organization via Request Fulfillment.  (It should be noted that a standard change is a type of "service request".)  These standard changes are under the control of Request Fulfillment but may need to be routed to other processes for fulfillment.  Typically, this does not require involvement from Change Management.  However, if a change request that is submitted to Change Management is actually a standard change, then its fulfillment will be coordinated by Change Management.

Change requests may also be submitted by users via Request Fulfillment, but they are sent to Change Management for processing, whereas standard changes are not. 

6. Do incidents ever turn into problems?

Incidents are never turned over to Problem Management to be resolved. Instead, Incident Management and Problem Management operate in separate, but complimentary ways.

Incident Management attempt to resolve each incident until service is restored. However, Incident Management might not be able to understand the root cause and resolve the real cause of an incident. Instead, Incident Management might only be able to provide a workaround. Thus, the incident might not be resolved by Incident Management.

Problem Management looks at all incidents, including those that have not been resolved. In addition, Problem Management might look at individual major incidents. In this way, it can appear that an unresolved incident is handed over to Problem Management. However, this is not the case. Instead, Problem Management is merely looking at the root cause of all incidents, including unresolved incidents and major incidents.

7. Do any processes develop anything besides Solution Development? Do other processes participate in developing a solution?

The processes in Solution Development are the only processes that develop solutions. This includes Solution Requirements, Solution Analysis and Design, Solution Build, Solution Test, and Solution Acceptance. Other processes can initiate these processes; they participate by specifying what should be created. For example, Security Management specifies the security-related solutions to be developed by Solution Development.
It should be remembered that processes are not necessarily performed by different organizations. Solution Development is not necessarily something performed by another organization but might be performed by the same organization as the one that specified what is to be developed.

8. What are the process frameworks?

Each process has its own process framework. For instance, Change Management has a Change Management Framework, Release Management has a Release Management Framework, and so forth.

A process framework provides the overall description of the process and the overall operating parameters for carrying out the process. This includes, but is not limited to:

    * Process goals
    * Process scope
    * Capabilities for carrying out the process, including tools
    * Key policies
    * Standards used by the process
    * Conceptual models that describe the overall working of the process
    * Data needed by the process
    * Data produced by the process
    * Process roles and who in the organization maps to those roles
    * Procedures for carrying out the process
    * Measurements and controls
    * How the process interacts with other processes

The other activities in the process use the process framework as a guide in carrying out the process. The framework is revisited periodically and updated as needed.

9. What is the relationship between RUP and Solution Development?

Both Solution Development and the Rational Unified Process focus on development projects. Both include the development of new systems as well as the modification of existing systems. However, Solution Development does not specify the particular development approach to be used. The Rational Unified Process is just one development approach that could be used. Other development approaches could be used instead of RUP in Solution Development.

For more information, see the RUP pages about this topic.