Projectmanagement
Chapter 1: Project management in its bare essence
What is the definition (definitie) of a project:
- A project is a temporary endeavor undertaken to create a unique product, service or result.
3 key elements in this definition:
- Temporary
- Create
- Unique
Definition (definitie) project management:
- ‘Project management is the application of knowledge, skills, tools and techniques to project
activities to meet project requirements.’
Figure 1 – Portfolio, program and project management
Portfolio management:
- Is about deciding which programs to run in order to support an organizations business
objective. (Strategic)
Program management:
- Programs are initiated to realize benefits through change. (Tactical)
Project management:
- A project is a temporary endeavour undertaken to create a unique product service or result.
(Operational)
The shortcut for these 3 is called P3M
,The table below provides a general comparison for these 3
Portfolio Management Program Management Project management
Translation of strategy into Program scoping and Production of planned project
portfolio of executable realization of planned program deliverables and achievement
programs and projects outcomes (business benefits) of agreed milestones
Portfolio prioritization of Installation of program Development and execution of
investment resources across Governance and project management plan,
programs and across business implementation of program team leadership and project
cycles standards, policies, processes, stakeholder management
tools and metrics
Portfolio benefits tracking and Management of project Escalation of project issues,
realization interdependencies and change requests and risks,
program performance where necessary
monitoring
Corporate/Business Unit level Multi implementation Used for 1 implemantation
Strategy realization activities
Figure 2 – Portfolio-program-project business process/project stage gates
All executed projects are initially triggered by explicitly stated ‘Business Needs’. After careful
consideration (‘Business request’), some of these needs are researched in more detail: a ‘Business
Case’ is drawn up. Those business cases that get approved result in launched projects (‘Project
Execution’). The governance of this structure is regulated at the so-called Toll-gates (G1 to G4 in the
illustration above), securing that the next steps only start when approved by the portfolio manager
and relevant business managers. Lastly it should be adding value to the organization (‘Business
Benefits’) This final stage can only be monitored by executive management and administered by
portfolio management.
Every organization that takes its IT seriously, should have 3 capabilities (within IT) in place:
- Architecture
- IT and IM Operations
- Project management
,Figure 3 – Project management as a business process
The basis of this model goes back to Henderson and Venkatraman’s well-known Strategic Alignment
model (SAM), and Peter Hinssen’s more challenging ‘Business-IT Fusion’-paradigm. These cover a
specific domain called Business-IT Alignment (BITA). The basic idea of the model above is to position
the PM-capability in the broader context of the IT department. The model the demonstrates how
P3M interacts with the other 2 IT capabilities, namely Architecture and Operations.
Here is how these 3 capabilities interact with each other:
Architecture <-> P3M: Business innovations can materialize independently, but IT innovations should
find their origin in strategic choices and be planned using IT architecture roadmaps. The formal IT
architecture guidelines and standards also serve as a reference to validate new IT solutions against.
P3M <-> IT daily operations: When projects implement their results, any modification of the IT
operational environment has to be governed by the change management process. This is illustrated
through the arrows entering the ‘change management capability’ circle in figure 3. These changes
should be connected to operations as early as possible. The initiation of project-related changes
should be guided into the daily operations in a controlled way (often referred to as ‘Transition
management’)
IT architecture <-> IT daily operations: Finally, there is also a direct relation between IT architecture
process and the daily IT (and information management) operational processes: the Change Advisory
Board (CAB) has to validate against the architecture guidelines and standards.
Notice that in figure 3 the organizations different strategies are fed to the IT department and that the
CAB is in the central position. This is based on the idea that the only constant for the IT department is
the continuous change they are supposed to deal with.
1.2 What Contributes to project success?
A project is successful when it meets its scope, time and budget goals. These are the 3 elementary
parameters within each project, often referred to as the ‘Triple Constraint’. Successfully managing
, these 3 is the core of the project manager’s work. Another way of assessing that the project is
successful is if it satisfied the ultimate client.
What is necessary to run a successful project, or better yet: What are the ‘Critical Success Factors’
(CSF’s) for project management? A lot of research on this matter is available in ‘CHAOS’-reports.
These are the 5 CSF’s:
1. Executive support
2. User involvement
3. Experienced project management
4. Clear business objectives
5. Minimized scope
• Executive support:
- The support of the executive is very important and ranked No.1 CSF.
• User involvement:
- Involving users from the very beginning, regardless of the nature and anticipated outcome of
the project, is key for the project result.
• Experienced project manager:
- Highly visible, risky projects goes to more experienced project managers and the less
complex, less visible and less risky to young and eager project managers.
• Clear business objectives:
- Each project should be underpinned by a sound Business Case. It should clearly state how
the project outcome is going to generate, influence or support the business objectives.
Projects that cannot be linked to business objectives should not be started in the first place!
• Minimized scope:
- The scope defines what the project is covering and delivering. The broader the scope of a
project gets, the harder it will be to manage it. Keep the scope clear and manageable. If
that’s not possible given the result you’re aiming for, then consider splitting up the scope
into multiple projects.
Chapter 1: Project management in its bare essence
What is the definition (definitie) of a project:
- A project is a temporary endeavor undertaken to create a unique product, service or result.
3 key elements in this definition:
- Temporary
- Create
- Unique
Definition (definitie) project management:
- ‘Project management is the application of knowledge, skills, tools and techniques to project
activities to meet project requirements.’
Figure 1 – Portfolio, program and project management
Portfolio management:
- Is about deciding which programs to run in order to support an organizations business
objective. (Strategic)
Program management:
- Programs are initiated to realize benefits through change. (Tactical)
Project management:
- A project is a temporary endeavour undertaken to create a unique product service or result.
(Operational)
The shortcut for these 3 is called P3M
,The table below provides a general comparison for these 3
Portfolio Management Program Management Project management
Translation of strategy into Program scoping and Production of planned project
portfolio of executable realization of planned program deliverables and achievement
programs and projects outcomes (business benefits) of agreed milestones
Portfolio prioritization of Installation of program Development and execution of
investment resources across Governance and project management plan,
programs and across business implementation of program team leadership and project
cycles standards, policies, processes, stakeholder management
tools and metrics
Portfolio benefits tracking and Management of project Escalation of project issues,
realization interdependencies and change requests and risks,
program performance where necessary
monitoring
Corporate/Business Unit level Multi implementation Used for 1 implemantation
Strategy realization activities
Figure 2 – Portfolio-program-project business process/project stage gates
All executed projects are initially triggered by explicitly stated ‘Business Needs’. After careful
consideration (‘Business request’), some of these needs are researched in more detail: a ‘Business
Case’ is drawn up. Those business cases that get approved result in launched projects (‘Project
Execution’). The governance of this structure is regulated at the so-called Toll-gates (G1 to G4 in the
illustration above), securing that the next steps only start when approved by the portfolio manager
and relevant business managers. Lastly it should be adding value to the organization (‘Business
Benefits’) This final stage can only be monitored by executive management and administered by
portfolio management.
Every organization that takes its IT seriously, should have 3 capabilities (within IT) in place:
- Architecture
- IT and IM Operations
- Project management
,Figure 3 – Project management as a business process
The basis of this model goes back to Henderson and Venkatraman’s well-known Strategic Alignment
model (SAM), and Peter Hinssen’s more challenging ‘Business-IT Fusion’-paradigm. These cover a
specific domain called Business-IT Alignment (BITA). The basic idea of the model above is to position
the PM-capability in the broader context of the IT department. The model the demonstrates how
P3M interacts with the other 2 IT capabilities, namely Architecture and Operations.
Here is how these 3 capabilities interact with each other:
Architecture <-> P3M: Business innovations can materialize independently, but IT innovations should
find their origin in strategic choices and be planned using IT architecture roadmaps. The formal IT
architecture guidelines and standards also serve as a reference to validate new IT solutions against.
P3M <-> IT daily operations: When projects implement their results, any modification of the IT
operational environment has to be governed by the change management process. This is illustrated
through the arrows entering the ‘change management capability’ circle in figure 3. These changes
should be connected to operations as early as possible. The initiation of project-related changes
should be guided into the daily operations in a controlled way (often referred to as ‘Transition
management’)
IT architecture <-> IT daily operations: Finally, there is also a direct relation between IT architecture
process and the daily IT (and information management) operational processes: the Change Advisory
Board (CAB) has to validate against the architecture guidelines and standards.
Notice that in figure 3 the organizations different strategies are fed to the IT department and that the
CAB is in the central position. This is based on the idea that the only constant for the IT department is
the continuous change they are supposed to deal with.
1.2 What Contributes to project success?
A project is successful when it meets its scope, time and budget goals. These are the 3 elementary
parameters within each project, often referred to as the ‘Triple Constraint’. Successfully managing
, these 3 is the core of the project manager’s work. Another way of assessing that the project is
successful is if it satisfied the ultimate client.
What is necessary to run a successful project, or better yet: What are the ‘Critical Success Factors’
(CSF’s) for project management? A lot of research on this matter is available in ‘CHAOS’-reports.
These are the 5 CSF’s:
1. Executive support
2. User involvement
3. Experienced project management
4. Clear business objectives
5. Minimized scope
• Executive support:
- The support of the executive is very important and ranked No.1 CSF.
• User involvement:
- Involving users from the very beginning, regardless of the nature and anticipated outcome of
the project, is key for the project result.
• Experienced project manager:
- Highly visible, risky projects goes to more experienced project managers and the less
complex, less visible and less risky to young and eager project managers.
• Clear business objectives:
- Each project should be underpinned by a sound Business Case. It should clearly state how
the project outcome is going to generate, influence or support the business objectives.
Projects that cannot be linked to business objectives should not be started in the first place!
• Minimized scope:
- The scope defines what the project is covering and delivering. The broader the scope of a
project gets, the harder it will be to manage it. Keep the scope clear and manageable. If
that’s not possible given the result you’re aiming for, then consider splitting up the scope
into multiple projects.
