Repost, article originally posted on ComputerWorld UK
Have you ever noticed how good humour can make you laugh and cry at the same time? Laugh because the situation it describes is so ridiculous, cry because it is “too close for comfort”.
Recently I came across “the Hitchhikers Guide to the Galaxy” (again) and once again I was confronted with the “Not my problem field”. For those not acquainted with the guide the “Not my problem Field” explained in my own words (I hope the creators of the guide do not object too much to my interpretation): In the distant future it is recognized that most creatures are curious by nature. Therefore trying to establish invisibility technology goes against a basic force in the universe (curiosity) and thus is very hard if not impossible to achieve.
However another basic force in the universe is the tendency of creatures to shy away from things that might have a negative impact on them. So instead of convincing creatures that something is not there one should convince them that they should consider it “not their problem” because showing an interest might have negative impact for them.
As a result they will ignore items surrounded by the “not my problem field” effectively blocking it from their mind and making them invisible. Hence the “Not my problem field” technology is developed in the future according to the Hitchhikers Guide.
When I came across this section of the guide once again I had the tendency to laugh and cry at the same time. Since I was reminded of the “not my problem field” theory I became convinced this is not an Einstein like theoretical line of thought (disguised in comedy) I am now convinced we see the practical impact of these forces in the universe in everyday life. When I hear a project manager say that operational maintainability of the IT System he is supposed to deliver is not described in the specification and therefore not his….. I think: Field operational! Or the IT domain that has no idea what business value of IT means, strong field in place!
But the worse of them all is the field created by outsourcing. It is amazing how many organizations believe that if they outsource their IT (Support, development, etc.) things like Information Security, IT Compliance and even IT (related) Risk are no longer their problem. Only recently somebody told me that they had an SLA (with penalty clauses) with their external providers so IT Security, IT Control and IT Risk were no longer their problem.
So I asked him if he thought the existence of penalties ensured that the provider would always meet the SLA values. As an example we looked at the Service Level were the provider promised he would resolve 90% of all high priority incidents within 4 hours and 100% within one workday. Focusing on this promise alone we could easily come up with a number of scenarios were the provider just would not be able to meet the commitment even if he wanted to.
This showed two things:
1. One should look at 100% promises with suspicion
2. Penalties are not risk mitigating controls
At best penalties transfer the risk from the customer to the provider. Based on this realization customers should think of the potential impact of their providers failing to meet their service levels. On most cases they will find that the penalties imposes do not even start to cover their potential losses (both material and immaterial) recent examples of data privacy breaches for example show the incredible reputational damage these can do.
The fact that the IT Service Provider might share some of the blame almost never eases the pain for the organization. The situation becomes even worse if one realizes that it is common practice amongst IT Service Providers to implement risk mark-ups for those contracts involving penalties. In this case the mark-up is reserved to pay the penalties should they be imposed so basically the customer pays for his own penalty!
So where do all these “not my problem fields” come from if they are so undesirable? In the case of outsourcing they are actually a sales argument “outsource and all these operational issues are no longer your concern we will handle them for you”. What this statement fails to recognize is that you can outsource (operational) responsibility but not overall accountability towards the organizational owners and stakeholders.
Furthermore “not my problem fields” are the (unwanted) side effects of establishing governance structures and their supporting assignments of authority and responsibility. On the one hand it is undesirable that everybody is involved with each and every decision because such an organization would lose all agility. On the other hand every time somebody is excluded from the decision making process a small “not my problem field” is established and it might become stronger over time.
So when you accept that “not my problem fields” exist and are very often undesirable how should one react? I came across one organization that had (at least in theory) the answer and till date I feel they do a good job with the operational implementation of the solution. For this organization the solution comes from one of their core cultural values. The value is called “enterprise first”.
It basically means that the overall good of the organization comes before the individual interests of, managers, departments, divisions, etc. If somebody is asked to assist with an issue he cannot respond that he will not assist since “he is not responsible” (read: not my problem) if the enterprise benefits from resolving the issue everybody should think “enterprise first” and assist if required.
With this solution it is important to realise that it is comparatively easy to commit such a corporate value to paper. However to implement it and make it part of the standard attitude of all those who take part in the daily operation of the enterprise is a completely different challenge. The more so if you realize that those involved with daily operations are not necessarily employees of the organization these days. In recent years a growing percentage are temporarily assigned external (human) resources that might not share (or be exposed to) the same core corporate values.
Thursday, November 24, 2011
IT project management: The standards of change
Reposted from the original article on ComputerWorld UK
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.”
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.
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.
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).
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:
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.
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.
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.
ITIL
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
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)
Programme management
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.
Subscribe to:
Posts (Atom)