Why no mention of project management in ITIL docs? How does a project office fit into an organization modeling itself on ITIL precepts? Saving Changes...
ITIL is a set of activities/processes for the operational management of an IT shop.
Project management is a set of activities/processes for the delivery of a solution (IT and non-IT)
In essence the products produced by a project are ongoingly managed and supported by ITIL.
The core interfaces (which are not well documented) are between the Project planning and executing and Change management.
The Project Office fits in by providing dates fot the forward schedule of changes and other necessary information to a CAB to allow approval of the request for change.
Keep in mind one project may have multiple changes during the its life. Each of these changes goes through the Change Management processes within ITIL.
Projects need to be aware of the requirements set out by ITIL to ensure smooth implementations as well as ongoing support. The project office should work to ensure these things happen within the project deliverables. For example a work breakdown structure of a project may identify a design phase is required. This phase will need to consider what is expected under Service Level Management and Availability Management.
A point of interest... ITIL and Price2 orginate from the same source. (OGC)
Anon, PM happens along side the Change Management process in ITIL theory.
Theory indicates a Planned CI (configuration item), say request for new application buy/build is submitted as a request for change.
As Mark points out, Change manages the process of PM activities, ensuring the project is on the forward schedule of changes (FSC)for the organization and keeping tabs along the development process.
For instance, it may be critical to the project success not to schedule its implementation during a major WAN upgrade. The FSC provides that information because it is an overview of all Changes happening in the organization.
There "should" be a high level of communication between the two areas. If you read through ITIL Support Delivery documentation on Change Management, app dev happens somewhat outside mainstream change management. This is because Change Mgmt usually does not want to slow down dev by documenting every code change.
Let me know if you have any other questions. Saving Changes...
Tracy DrewDirector, Program Management| ISM CanadaRegina, Saskatchewan, Canada
PM is mentioned in several ITIL documents. In particular, PRINCE, which is the British PM standard. As an ITIL trainer and consultant, I always use and encourage PM with any ITIL project. PM is not specific to any one process. Any improvement or implementation project sdhould be run with sound PM principles. Saving Changes...
Anonymous
just as a thought...with so many government projects failing by going over budget, over time, or not performing...and mainly a combination of all three. Why do companies want to implement these processes and systems, like ITIL? surely the best thing to do is find someone who does it well and copy that, yes? Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
Anon, Don't fall into the trap of thinking that the problem is bound to be the process, and if only I used what others are successfully using then I too will be successful. Although a good process is important, and it is all too easy to develop a cumbersome beurocratic one, it is more important to focus on the basics and use common sense. Projects can be run well with PRINCE2, and they can be run badly. If you find some organization that is successful, try to find out what makes it successful. You will probably find that it has more to do with the people and their mindset than the process - the process is there to help people get their work done, focusing on the work is more important than the process. Saving Changes...
The government generally has problems with project management because the users cannot clearly define what it is they actually require ("Keep working on it, I'll know it when I see it.") The failure of users to have accountability for their impact upon the IT-providers' budgets adds to the problem. Compound this with the lack of strategic, tactical, and operational IT planning in most Government organizations; and you will have doomed projects. In simple terms, everyone must agree on what constitutes success in a project. The ITIL process is one methodology that is intended to bring all of this together across the business enterprise to produce more effective and efficient IT support. Saving Changes...
I tell you, as a employee for a government IT group, we struggle with this consistently.
Anon-Some of this just seems like common sense, doesn't it? Yet it's always a struggle for governments in this "do more with less" culture. My dept. is just coming to the realization that just because you call someone a "Project Mgr," doesn't mean they'll know how to manage a project. Often times a programmer will be given the job.
I also agree with some of the things Mike Cooper points out. Sometimes the process is the problem, sometimes the employees. In government these types of processes are very difficult to implement. In any organization change is always difficult to accept and deal with.
In our organization these processes have been very difficult to implement, especially change management. It requires people to come out of their silos and share information. Previously, many people in all areas of our IT gave little, if any, thought to how their changes impacted the rest of IT or the users.
As Michael Carl points out there is a lack of a lack of accountability on both the part of the users and the IT staff.
As IT professionals, it's incumbent upon all of us to begin to learn "soft skills." All that "touchy-feely" stuff that makes for good customer relations.
Just my thoughts
Saving Changes...
Alejandro SeguraProject Coordinator - PMO| Universidad de los AndesBogota, Colombia
Hi all,
I've been reading all your posts and I wonder why all (me included) say: project management should be related to Change Management. However, in the Service Support book of ITIL (OGC) it states: 'changes to any components that are under the control of an applications development project... do not come under Change Management but would be subject to project Change Manamente procedures'...
Does it means that a RFC which is project related, should be requested as a normal RFC, even though it is not a live system we are working in? Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
When thinking about change management, three flavors come to mind; Application Change Management, Infrastructure Change Management and Organizational Change Management. When it comes to PM all 3 can be in play. Clearly major changes in the application environment impact business processes and workflow and that means change to the way people interact and communicate and thus Organizational Change Management. In that context the PM is a change agent who must be adept in facilitating a successful transistion from the old way to the new way. The traditional concept of Change Management around insuring that changes to systems are implemented with proper controls and governance is but a small piece of the overall concept of change management when it comes to changing the way value is delivered to stakeholders. It gets confusing since the same phrase can relate to so many different schools of thought. Saving Changes...
PMI Team Member
