IT projects are a vital element in the activities of the IT domain. For a project manager what standards are there to help organise their work and how do they relate to the other IT activities and standards?
The IT domain offers services related to the information used by the organisation. When we look at the internal working of the IT domain there are two important fields of operation. First ensuring the continued availability of services currently offered by IT and used by the business. Second building new services or changing current offerings to keep aligned with the ever changing requirements of the business. Creating new services or changing current services are often organised in the form of projects.
Wikipedia defines project management as “the discipline of planning, organising, securing and managing resources to bring about the successful completion of specific engineering project goals and objectives.”
Pure project management methods
When looking at the above definition for project management it is clear it is not just for IT Projects but applies to any type of project. The second observation is that the goals and objectives are a given in this definition.
When we look at project management an important organisation to start with is the Project Management Institute the Wikipedia page gives an overview of the PMI and their offerings. Note worthy are that the PMI offers certification and owns the Project Management Body of Knowledge (PMBOK). The PMBOK is a world-wide known and accepted standard for project management which offers a common language, structure and definitions for those using the standard. However PMBOK was created as a standard for any type of projects not specifically for IT Projects. As a result it can be challenging to decide what sections are applicable and how they should be used to structure IT projects.
Developed specifically for the management of IT projects is PRojects IN Controlled Environments (PRINCE 2). The Wikipedia page gives a good overview of prince 2. Furthermore the Office of Government Commerce (OGC) maintains the official website for the method. The official website also shows that OGC owns a number of related models such as ITIL (a best practice model to help organise the operational section of the IT Domain).
Since the deliverables of the projects are handed over to this part of the IT Domain alignment between these organisations (and the models used) is important. The strength of Prince 2 is that it offers a lot of help to internally structure IT Projects. Since the OGC is an institute from the British Government it is no surprise that Prince 2 is widely accepted and used in Europe. Even more so it is one of the leading project management methods worldwide.
Critics of Prince 2 say it is too much internally focused towards organising the internal project structure and does not offer enough focus on the interaction of the project with the “outside world” and “what comes next”. Prince 2 advocates counter that the method is OK but that it’s the way the method is used that does not pay enough attention to the outside world. Furthermore that ITIL and Prince 2 are developed, ran and maintained but the same (OGC) institute helps to ensure aligned between the two models which should help to facilitate the hand over from service creation into service production.
Other relevant models for project management
How to organize the interaction between the project (manager and team) and the environment? Depending on the size and nature, a project can have many different external stakeholders.
For a Project Manager stakeholder management is a very important skill. Stakeholder management is all about indentifying those who are affected or who can affect the project, understanding their needs and managing their interests. Unfortunately there is no generally accepted standard approach for stakeholder management. The above link to Wikipedia gives a general introduction and a starting point for those interested in the subject.
We identified one stakeholder already: IT Operations, charged with the run and maintain of the deliverables of the IT project. For a project manager who does not like negative surprises at the end of his projects it is good to ensure a basic understanding of what drives this stakeholder. ITIL as one of the leading process frameworks for this stakeholder would help facilitate the relationship. Owned by the OGC (also owner of Prince2) the day to day management of the model is left to the IT Service Management Forum (itSMF).
The ITIL model is the leading process model for the operational management of IT Services. According to critics it is too much focussed on Infrastructure Management and does not pay enough attention to Application Management. With the introduction of ITIL version 3 the model also addresses topics regarding the strategy and design of Services but it still does not address the topic of Project Management.
An even more important stakeholder is the project owner. Somebody (usually in the business) has a requirement for a new or changed IT Service and, just as important, can make available the resources mentioned in the definition of project management. Mismanagement of this stakeholder is arguably the primary reason of IT Project failure. Clear and correct translation of the requirements from the project owner and limitations set by this stakeholder into workable project goals and objectives is a science if not an art in itself.
Business case creation and management is a field of expertise focused on structuring and improving the Project Owner/ Project Manager interaction. Especially with bigger longer running projects, circumstances change over time and the initial owner requirements might change during the course of the project. So Business Case management does not stop at business case creation, continued validation and updating of the business case is also part of this discipline. Since this is a relatively new area of attention there is currently no clearly leading method for Business Case Management. Prince 2 offers some assistance here. So does the ISACA framework for Business Technology Management (ValIT).
ValIT uses an angle towards the relationship between the Project Owner and Project Manager different from pure Business Case Management. According to ValIT the relation between the business demand and IT Supply is not just one set of requirements for a new or changed services combined in a single project. The relationship consist of a portfolio of services the IT Domain offers towards (sections of) the business. Given the limited resources of the organisation Business and IT together have to decide how to ensure maximum business value from the IT Portfolio in an ever changing environment.
So not only different (change) projects are competing for the scarce resources but also the funding for the operational services is taken into consideration. The benefit of this approach is that it places the individual project into its contexts towards other IT-related investment categories and thus gives information about the “boundaries” for the project. On the other hand the project manager often has very little influence on the decisions made in the “grant scheme of things”.
Since the definition of Project Management also mentions “securing resources” a project manager should have an understanding of (IT) Portfolio Managementbecause this discipline is responsible for the allocation of resources to projects and other IT-investment categories. Besides the ISACA model already mentioned the OGC has models and methods addressing this field of attention:
- Management of Portfolios (MoP)
- The Portfolio, Programme, and Project Management Maturity Model (P3M3)
- Portfolio, Programme and Project Offices (P3O)
Besides projects and portfolios we also recognise programmes. In practice one often finds that organisations call large, influential projects programmes. This would indicate that programme and project management are basically the same.
In theory however there is a clear difference between the two Wikipedia describes it as follows: “Project Management... It is sometimes conflated with programme management, however technically that is actually a higher level construction: a group of related and somehow interdependent engineering projects.”
Without further discussing the distinction between projects and programmes it is important to recognise these two are closely aligned. A Project Manager working in an environment where program management is established should ensure that he has a basic understand of programme management, specifically what the applicable definition in his environment is. The OGC offers a model for “Managing Successful Programmes” (MSP) furthermore the PMBok offers a lot of information about program management.
A special application of programme management techniques are the so called “organisational change programmes” these recognise that when you change one component of the (business) organisation this will impact other components as well. For example if you change a system this will most likely change the way is it is used (the business process) it will affects the users (People), etc.
A business change programme looks at all these different aspects that need to be addressed by as many different projects. These projects are clearly related and might have interdependences. From a manageability perspective however, the program is dissected into multiple better controllable and manageable projects.
The importance (and value) of IT for the correct operation of the business has grown over the decades. This also means that failed IT Projects can have an ever growing devastating effect on the organisation. As a result more and more stakeholders have a growing demand for control over IT Projects. The requirements for control might come from the higher management and/ or enterprise directors (IT Governance), internal or external rules and legislation (Compliance), demand for the management of security and/ or risk (Security and Risk). For the project manager all this translates into requirements to proof he is in control of the project and its inherent risk.
These requirements can differ greatly depending on the size and nature of the organisation and the individual project. These days you find that more and more organisations have an IT general control framework applicable to their IT Domain this framework would most likely also contain general controls for projects. Standards and frameworks used are (amongst others) the ISO 27000 standard for Information Security Management Systems, ISACA’s Cobit and RiskIT.
Part of the stakeholder management required from the Project Manager is to understand who the parties are that require control and what their requirements are. The control models target the complete IT Domain not just the IT Project organisation so choosing with standard(s) to adopt is often decided elsewhere in the organisation.
Organisational and process improvement models
Until now we have looked at the use of standards and the way they impact projects from the viewpoint of individual projects. However standards like CMMi from The Carnegie Mellon Software Engineering Institute (SEI) and Six Sigma (originally developed by Motorola) aim to organise the processes for the complete IT Project Organisation (the section of the IT domain responsible for all IT Projects combined).
These approaches basically try to learn from past mistakes and create and improve the organisation specific Project Management processes for time. For the individual project manager this means he can build on past experiences and does not have to re-invent the wheel for each specific project.
This article does not pretend to offer a complete overview of all models and standards that might be relevant to IT Project Management. Other organisations like ISO, the NIST (from the American Government) and Standards Australia have a wide variety of standards and frameworks which might help organise specific IT Project Management related topics.
It is important to realise: You need a screwdriver if you want to fix a screw but a hammer for a nail. Depending on the issue a nail or a screw will offer the better solution. Understanding the positioning, goals, strengths and weaknesses of individual models is the best way to decide which is most appropriate given the individual situation.