Not all organizations are based on repetitive Production Operations. Some may deal only with Projects: those initiatives that have a discreet Start, unique Deliverables and Finish.

In such an organization PbM (Problem Management) would surely have a role, for although each Project may be unique in terms of WBS, Resources and Deliverables, the Activities that make up the WBS are usually not unique. As such, Incidents that evolve into Problems need to be identified and managed in a manner that is similar or perhaps identical to the processes and procedures in a Production environment.

Problem Management would deal with trying to find the root cause of 'incidents' which impacted the service.

This means that PbM is concerned about operational environment

If the root cause is Incorrect hardware o software version, and this would mean that a whole new environment - NT4 vice Win2k vice Xp vice Vista on more robust systems, the PbM says this is the root cause and this is the solution.

Then Project Mgmt (PjM) would have to be involved in acquiring the budget, writing the plan etc until the pproject is ready to go to the live environment. Then Change, Release and Configuration gets involved

The PbM case does not get closed until the change release and config piece gets completed and the underlying root cause and the incidents/impact on the service have gone.

If however, the PjM tries tog et the money and the seniro mgmt says no, then the PbM merely annotates that in the record and it stays open_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

If ITIL were concerned with more than just the Production Operations environment, the answer to your question would be "yes". However, ITIL is not. It is only focused on Production Operations and, therefore, technically, the scope for Problem Management is implied to also be within the Production Operations environment.

This being said, though, if you're trying to truly optimize all of IT, you will go beyong ITIL and apply all of ITIL's disciplines to all of your environments.

It is important that a tremendous amount of work and information gets generated long before anything ever gets into Production. Not tracking and managing all of that information and work means that you are throwing away all the information that led to production and can help you debug in production, as needed when future Incidents and Problems arise. Experienced IT leaders and enterprises realize this and apply ITIL to "all" environments. However, in order to make this happen properly, you must have a non-ITIL displine in place and fully functional, which is "Product Management", as all information about a Product, regardless of the environment it's generated in, ultimately belongs to the Product Owners and their teams. A Service, in ITIL, is a wrapper around a Product and/or System (where a system is nothing more than a grander wrapper around one or more Products, Systems, and Services).

Anyhow, I always recommend to my prospects and clients that if they truly want to run their IT organization as a business, the horn that ITIL regularly blows, then you must worry about far more than just Production Operations, as Production Operations is only a very small percentage of everything your IT organization does. There are so many other disciplines, not covered by ITIL that must be put in place if you want to truly run yourself like a business. Strategic, big picture leaders get this.

Application Management book says that Optimization, Operation and Deployment belong to the Service Management, and the Analysis, Design and Build belong to Application Development. I assume the same relates to the other Product Management subjects.
As for the Service Management part, I would put it rather into the Release then Problem Management.
You have testing both in Build and Deployment.

Although the Service Management books (SD&SS) cover the Production Operations only, the other ITIL core books cover other aspects of IT Management.

Frank,
I honestly try to find the scope and coverage of ITIL, but I find it difficult to point out the areas that are not covered by ITIL. Of course there are some "poorly covered" areas, but at least they are mentioned. Do you have any suggestions of where to look for the hard evidence of the uncovered areas?_________________Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent

Barring the fact that ITIL suggest or doesn't suggest Problem Management for Development environment, my query is whether we should have separate Problem Management functions for development and Production environments or not? If we can probably discuss some pros and cons of it - it will help me.

My view is that these should be separate from the very fact that the goals of Development environment and Production environments are differing i.e. for Development teams its the product delivery on time/cost/etc. whereby for Production their objective is fix the problem so that it doesn't impact the quality of service / SLAs. So if they have different interests/objectives, these teams should never be together.

However, there are obvious benefits of having these environments also managed as a combined team which are
- Better resource utilisation
- Easy problem management for services moving from development to production as they would anyways have the knowledge/experience of the service and the problems faced during development.

The issues of 'problems' in the development world should be dealt with as part of the application management (ITIL) or the SDLC.

Problem Mgmt (ITIL) deals with the impact of the service on the live users - live being subjective. If the application was rolled out to the users and it dont work, then Problem Mgmt (ITIL) is one of the areas.

If the application has not rolled out and you find issues when you test the application, this should be dealt with through the app dev processes for finding & fixing bugs in the application before the release_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Barring the fact that ITIL suggest or doesn't suggest Problem Management for Development environment, my query is whether we should have separate Problem Management functions for development and Production environments or not? If we can probably discuss some pros and cons of it - it will help me.

There is no real reason or benefit to having Problem Management functions be separate for each environment. As a matter of fact, you will probably gain significant economies of scale and a much better view of your entire environment, if you execute PM across all environments, by the same groups.

Quote:

My view is that these should be separate from the very fact that the goals of Development environment and Production environments are differing i.e. for Development teams its the product delivery on time/cost/etc. whereby for Production their objective is fix the problem so that it doesn't impact the quality of service / SLAs. So if they have different interests/objectives, these teams should never be together.

Actually, the goals of the non-Production environments are no different than those of the Production environment. They simply have different uses and SLAs. Remember, a QA environment "is" a production environment for a QA Team. A Development Environment "is" a production environment for a Dev Team, and so on.

Forget about ITIL for a second and simply put yourself in the seat of the CIO or CTO. Your responsibility becomes "all" of IT, not just the Production environment. CIOs & CTOs have to worry about the big picture. While ITIL's intent is good, it misses that big picture.

People that come back trained for ITIL seem to have an absolute view of the world, once they get that training. Please remember that IT is very large and if you truly want to run yourself like a business, you will have to accept that ITIL best practices are highly limited and cover only a very small portion of IT.

BTW, to address your statement of "...these teams should never be together...", please understand that only large enterprises have the ability to break up roles by headcount. As, enterprises get smaller, this is not possible and the same people find themselves wearing many different hats. And, there are many efficiencies that these smaller enterprises gain because of it, as you mention in your benefit, below, "Better resource utilization".

Quote:

However, there are obvious benefits of having these environments also managed as a combined team which are
- Better resource utilisation
- Easy problem management for services moving from development to production as they would anyways have the knowledge/experience of the service and the problems faced during development.

How about these benefits...

- Consistency of how you treat and operate in all environments
- Stakeholders in all environments speaking the same language
- Lower costs through economies of scale
- Running all of IT as a business, instead of just Production
- Better transparency across your entire IT org, not just Production
- Higher quality across your greater organization
- Better Knowledge Management, as you collect and manage information across all environments.
- Etc.

Forget about the fact that ITIL strictly targets Production. If you want to truly run IT correctly, like a business, then you have to worry about the bigger picture. Think of yourself as an IT leader that has big picture problems. All of ITIL's disciplines need to be executed across all environments for you to manage IT like a business, properly. Then again, there many other disciplines that you'll have to put in place to manage IT like a business, as well, that are outside the scope of ITIL. Many will even contradict with ITIL, if you do it correctly, since not everything in ITIL is correct. The key is to keep an open mind and "always" try and worry about the bigger picture. If you get caught in the weeds, you're doomed.

- Since, I have my Service Masters exam on 20th, I would like to write things in accordance with what ITIL says and the way John has suggested. (Bcoz scoring is my objective, not the right implementation as such)

- However, if the question is about sharing/discussion/putting my experience or atleast when I have to implement Problem Management in real life or in my environment then I very well concur with Frank that it gives much higher value to implement as one group.

As this was my first post on ITIL community, I am delighted with your responses and the experts like you who spent time to help others - its pretty inspiring.

I will mention a twist to all this. Keep in mind ITIL is to align with what the business needs are and not what the needs are in IT. That is why an SLA is developed. That said, we have a seperate SLA for the developers. The developers are considered part of the business and an impact to their service is an impact to the business in general as they can't bring their product to production when the business needs it. This is an investment bank and they can't retain a competitive edge if they can't bring the latest software products to the desk fast enough.

So in short we see the development community as our clients and are just delivering a different level of service as requested in the SLA.

If development activities are part of your core business (which I believe they are, otherwise you wouldn't put so much money in) then the management of the development environments should be part of the normal operations of the IT department: developers are just another type of clients, probably with specific SLAs. Just imagine the cost for the company if all the development work of the past 3 months was to get lost... In many cases, development environments would be somehow part of the continuity plan as well. Missing to deliver projetcs may jeopardize the entire business of the company.

Another area where I would think PM is linked with projects is during the design and build phase of a project: PM is the area where expertise on relationships between the various components and contributions to service delivery is built; therefore I would consider it is the best place to assess and evaluate solutions being designed (activities like Fault Tree Analysis used in problem resolution, can also be very helpful, used backwards, in solution design).

My experience says that if the ITIL processes and roles are only involved in Real Production, it is sometimes too late or really costly to handle. The objective is not only to best deal with incidents and problems that happen in the production life , but also (rather?) to avoid them as much as possible...At the end the "projetcs" will have to be integrated in the production world.

In my experience large changes to corporate infrastructure, or significant new applications development, many organisations run these as self-contained projects.

These projects are almost always seperate to the production environment and often even to the enitre IT department, e.g. the project is outsourced to another company.

In the context of our discussion, in this case problem management isn't involved at all until the new product, service etc. goes live.

However, say this new service (delivered via a project) has a particular number of incidents that trigger a problem record. Further investigation of the problem reveals that the error is attributable to some defect in the way the service is created, i.e. in the project process. Now this actual error might not be fixable, but the error in process could be fixed.

Now if the project processes are carried out in-house perhaps they may be able to enforce the fix to the project medthodology. If the projects are external they may not be able to influence that beyond persuading management to choose a different supplier.

So in answer to the question "Should PM be concerned with project, dev and test areas" I'd say yes. Anything that can possibly affect the stability of a service falls within the realm of reactive or pro-active problem management.

How actively they are involved in these areas is totally dependent on your environment.

Dave

BTW when running projects I always try to implement a mini ITIL environment within the project to perform many of the change, release, problem management functions.

The Production environment is relative. Everyone in the organization uses a "Production" environment. The developers expect the sub-Production environments to be available to them during their working hours so even though the "business" users aren't customers of the sub-Production environments, the developers are. Sure, anything that affects the bottom line may be granted higher priority however the cause of a development server outage should be investigated with the same diligance as the cause of a production server outage.