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: IFetherst
New Today: 8
New Yesterday: 49
Overall: 148351

People Online:
Visitors: 81
Members: 1
Total: 82 .

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 - Should PM be concerned with project, dev and test?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Should PM be concerned with project, dev and test?

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


Joined: Feb 14, 2007
Posts: 2

PostPosted: Thu Feb 15, 2007 1:19 am    Post subject: Should PM be concerned with project, dev and test? Reply with quote

Should PM be concerned with project, dev and test areas, or is Problem Management (as well as Incident, Change etc) only concerned with the PRODUCTION environment?

It seems to me PM is busy enough with production to be tied down with non-prod issues.
Back to top
View user's profile
7thPillar
Itiler


Joined: Sep 21, 2006
Posts: 20
Location: Great Lakes, North America

PostPosted: Thu Feb 15, 2007 4:01 am    Post subject: Reply with quote

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.

Alex Zayachkov
ITIL Process Engineer
Great Lakes
Back to top
View user's profile Send e-mail
nutsford
Newbie
Newbie


Joined: Feb 14, 2007
Posts: 2

PostPosted: Thu Feb 15, 2007 8:46 pm    Post subject: Reply with quote

Granted,

but what about 'normal' operational states where prod is busy, and Project/dev is a seperate entity?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Feb 15, 2007 10:57 pm    Post subject: Reply with quote

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)

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


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Feb 26, 2007 2:20 am    Post subject: Reply with quote

Hello nutsford,

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.

Anyhow, I hope this information helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Mon Feb 26, 2007 10:45 pm    Post subject: Reply with quote

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


Joined: Mar 15, 2007
Posts: 2

PostPosted: Thu Mar 15, 2007 6:54 pm    Post subject: Reply with quote

Hi There,

I have a query related to this post - hope someone reply to this Question

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.

Looking forward to your suggestions.

Thanks
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Mar 15, 2007 7:37 pm    Post subject: Reply with quote

Anshu,

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)

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


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Mar 15, 2007 10:27 pm    Post subject: Reply with quote

Hello Anshu,

Please find my response, embedded below...

Anshu wrote:
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.

Anyhow, I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Anshu
Newbie
Newbie


Joined: Mar 15, 2007
Posts: 2

PostPosted: Fri Mar 16, 2007 4:06 am    Post subject: Reply with quote

Thanks John and Frank for your prompt suggestions.

I would like to use your suggestions in the following point of view:

- 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.

Cheers
Back to top
View user's profile
ITILiano
Newbie
Newbie


Joined: Mar 15, 2007
Posts: 5

PostPosted: Sat Mar 17, 2007 5:22 am    Post subject: Reply with quote

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


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Mon Apr 02, 2007 9:28 pm    Post subject: Reply with quote

I fully agree with the last statement.

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.

rgds
_________________
JP Gilles
Back to top
View user's profile Send e-mail
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Tue May 01, 2007 10:41 pm    Post subject: Reply with quote

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


Joined: May 16, 2007
Posts: 1
Location: Boise, ID, USA

PostPosted: Thu May 17, 2007 6:03 am    Post subject: Reply with quote

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.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem 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.