Nel 2010 il Project Management Institute^® ha aggiornato la propria visione del ruolo del project manager, descritto nel nuovo Role Delineation Study.

In coerenza con le nuove caratteristiche del profilo nell’autunno scorso erano già state aggiornate le modalità di acquisizione delle PDU per il mantenimento della certificazione e ora, coerentemente, cambia la distribuzione degli argomenti nelle domande d’esame. (Vd. Table 1).

Table 1 - Fonte PMI(R)

Quali le differenze per chi si accinge a sostenere l’esame? Di fatto ben poche, in quanto restano validi tutti gli argomenti che già precedentemente venivano affrontati in vista dei test. Non cambia dunque il cosa studiare.

La novità più evidente consiste nell’accorpamento della voce relativa alla Responsabilità Professionale, a cui prima era dedicato un 9% di domande, che ora viene “annegata” nei tradizionali cinque gruppi di processi o domini.

Possiamo allora dedurre in generale domande un po’ più verbose e “sornione”, da considerare non solo dal punto di vista tecnico, ma anche, contemporaneamente, sotto il profilo etico.

In totale circa il 30% del “parco domande” è stato revisionato, per soddisfare la nuova visione del ruolo del project manager.

In particolare il project manager PMP^®:

• non è più coinvolto nel processo di selezione dei progetti, ma solo nella valutazione della loro fattibilità;
• assume un ruolo più attivo nella gestione delle limitazioni del progetto;
• nella raccolta dei requisiti lavora in più stretta collaborazione con gli stakeholder e considera anche le lessons learned;
• sviluppa un esplicito piano di gestione delle risorse umane per definire ruoli e responsabilità;
• si concentra sulle aspettative degli stakeholder e sul loro sostegno, attraverso una specifica analisi;
• focalizza la WBS sulla scomposizione dello scope;
• sviluppa un piano del budget, dei tempi, degli approvvigionamenti e della qualità e li implementa;
• dà enfasi al piano di gestione dei cambiamenti;
• costruisce un piano di gestione dei rischi per gestire l’incertezza, e non più per ridurla;
• guida il kickoff meeting allo scopo di condividere ogni informazione rilevante;
• l’implementazione del piano di progetto è finalizzata non più al raggiungimento degli obiettivi di progetto, ma, più prosaicamente , soltanto dei suoi deliverable nei tempi e nei costi stabiliti;
• non si limita a far crescere le performance della sua squadra, ma punta a massimizzarle;
• presidia più direttamente la risoluzione delle issue;
• orienta la comunicazione all’allineamento del progetto con i business needs;
• affronta la fase di chiusura in maniera più ampia e aperta, preoccupandosi anche di trasferire adeguatamente la ownership dei risultati.

Stessa preparazione, stesse fonti (la PMBoK^® Guide non cambia), ma un diverso approccio basato su una figura di project manager più attenta al profilo globale del progetto ed al raggiungimento efficace dei risultati.

Per maggiori informazioni (in lingua inglese) : Crosswalk Between Current and New PMP Task Classifications

In bocca al lupo!

Nel confrontarmi con i Project Managers dei miei clienti, non sempre ho riscontrato processi ben definiti di Change Management ed il tenere traccia in modo strutturato dei changes ricevuti e gestiti.

In sintesi ho riscontrato la seguente gestione:

1. Fogli di lavoro di Excel, direi il 70%

2. Documenti di Word il 10-15%

3. Applicazioni specifiche di Project Management meno del 5-10%

4. Strumenti come Sharepoint e simili intorno al 10%

Probabilmente voi che mi leggete potete avere avuto  un riscontro diverso, ma penso che le cifre non si discostino molto dalle mie.

Mancanza di gestione centralizzata e visione globale

Fatta salva la gestione centralizzata disponibile con applicazioni specifiche di Enterprise Project management o software sviluppato ad-hoc,, non ho mai visto in giro una gestione centralizzata in modo strutturato ed automatizzato. Solo alcuni PMO che ho conosciuto si fanno carico di aggiornare in fogli di Excel i Change Request trattati nei vari progetti aziendali. Da qui ad arrivare a fare statistiche su quanto e come incidano le Richieste di Modifica ce ne corre e di solito si rinuncia.

Può servire per una migliore e più proficua gestione avere una visione chiara ed aggiornata dell’andamento dei Change Request su tutti i progetti gestiti in azienda?

Secondo me si, sicuramente, e in questo articolo voglio dare un suggerimento su come farlo in modo strutturato e “pensato” sulla piattaforma Microsoft Project Server 2010 (ma può essere estesa alle versioni precedenti di Project e ad altri software concorrenti, ovviamente con le dovute differenze).

Aree di intervento per una visione centralizzata dei Change Request

In questo articolo vedremo alcune parti di Project Server e Project Professional 2010 in cui intervenire, e precisamente:

1. Definizione di una LookUp Table (tabella di codifica sul server)
2. Definizione di alcuni campi enterprise
3. Creazione di un modello di estrazione dati nel modulo di Business Intelligence (per analisi con Tabelle Pivot di Excel)
4. Aggiunta dei Campi Enterprise nei Modelli Globali (Templates) dei progetti
5. Definizione del Processo di Gestione dei Change Request che i Project Managers devono seguire nella pianificazione ed esecuzione dei loro progetti

Dall’elenco precedente si evince che non è come bere un bicchiere d’acqua (soprattutto l’ultimo punto), ma un componente del PMO che ha la responsabilità della gestione della piattaforma Project Server 2010 dovrebbe avere ricevuto la formazione necessaria per implementare le attività che ho delineato (il punto 3 richiede un’expertise maggiore).

In ogni caso cercherò di essere il più chiaro possibile anche con l’aiuto di videate catturate dallo schermo del computer.

Nella seconda parte di questo articolo vedremo come implementare i primi due punti dell’elenco, a presto.

Introduction

According to a number of recent CEO and CIO surveys, strategic thinking has been at the top of the leadership agenda for executives, but implementing a strategy to realize value is not as obvious as it seems and optimizing the use of resources to achieve this is even less evident. Can program management provide executives with the means to achieve their objectives and increase the organization’s competitive edge? Can it provide sponsors with a clear method for defining outcomes and benefits and mastering their delivery? Can it provide users with an assurance that their needs will be fulfilled, as much as is possible, within stated parameters?

There are currently three main program management guides, or standards, published by distinct professional bodies in America, Europe and Asia. In the UK and Japanese guides, program management is associated with the management of complex organizational or societal change. The PMI Standard associates program management with the management of multiple projects within the context of a strategic plan, where benefits can be obtained from managing these projects together. Each of these publications describes roles, relationships with other processes, program specific processes, program knowledge areas and other program management components in more or less detail, but where does this leave the executive, sponsor and user?

Program Management has emerged as a distinct discipline in the late 20th Century. It progressively developed as project management was applied to more and more complex projects, to the management of strategic objectives or the management of multiple interrelated endeavors to produce strategic benefits. It is now generally agreed that programs are a significant undertaking consisting of multiple actions spanning multiple business areas and that they are generally complex. Program management deals in both high ambiguity and uncertainty and requires a high degree of organizational maturity.

Program Maturity

Traditionally most organizations undertake projects as part of their work. Mostly these projects are treated as separate entities, independent from each other. They are often generated within a business unit and managed with that unit’s resources. Larger projects undertaken either for external clients or for strategic purposes are usually managed on an ad hoc basis by a dedicated team. Programs can either be “vision-led”, driven by strategic objectives, or “emergent”, a convenient grouping of existing projects for tactical reasons. Mature organizations will favor the more integrated vision-led approach that enables greater agility and responsiveness. Because of their overall strategic vision; they are more likely to realize business benefits.

As program management is used more and more to manage organizational change, the program becomes a vehicle for interaction between business stakeholders to generate creative ideas and innovative products that increase the organization’s competitiveness. In order to be competitive, a mature organization will use programs to link a number of business processes and understand how to create synergy between its different components (see Figure 1). Traditional organizational structures are well adapted to stable well-defined environments; they are typically hierarchical and based on strong organizational control. In these structures, the portfolio is typically divided into sub-portfolios, programs and projects. Recently, new organizational models have been developed that are more adapted to today’s turbulent and fast-moving environment. These new organizational models are similar to a supply or value chain and the program methodology is at the centre of the strategic decision management process.

In this type of organization, Program Management could be labeled as:

“The governance and harmonized management of a number of projects and other actions to achieve stated business benefits and create value for the stakeholders.”

But, developing a strong program culture involves a shared understanding of a number of objectives and a strong framework that can be outlined in four key program components: decision management, governance, stakeholder management and benefits management.

Key Program Components

The main program guides and standards already recognize governance, stakeholder and benefits management as key program components. Decision management is a new area of development that requires both a learning cycle, the actual decision making process, and a performance cycle, the decision realization process. Experienced managers know that successful change takes time and requires a sound decision making process. They also understand that decision making is not just about tools, but about making the right choices, based on objectives that have been agreed and can be measured. Making sense of the issues at hand, generating ideas and elaborating them into viable options are essential elements of a sound decision making process. Figure 2 depicts the whole program decision management cycle.

Mature organizations also adopt new developments and ideas for the other three program components. Whereas most organizations focus on the control aspect of governance, mature organizations consider a broader area of governance that includes leading: defining the vision; structuring: providing the structures and resources necessary to achieve the vision; and conforming: making sure the vision and value are achieved. They adopt a stakeholders’ management perspective that goes beyond roles and responsibilities of the different program stakeholders to include the steps necessary to manage and engage stakeholders. Understanding the required contribution of the different program stakeholders is an essential element of both program governance and stakeholder management because both boundaries and relationships between the responsibilities of the different program actors should be clearly identified to enable a smooth transition process between the strategy, the program and operations.

Finally, benefits management includes the development of a sound benefits management system, from the definition of meaningful expected benefits to their actual measurable realization. In order to ensure the realization of strategic objectives, the program life cycle is cyclical to enable regular assessment of benefits, evaluation of emergent opportunities and pacing of the process; it takes into account the ‘interdependence’ of component projects to ensure strategic alignment. To achieve this, a program life cycle must be iterative, rather than linear, include periods of stability and have a learning and systems perspective. Executives and sponsors become change leaders by taking responsibility for three steps that underlie every program decision: value creation, transition and value realization.

Program Management Life Cycle

Most books and guides on program management have suggested program “phases” which are simply transpositions of the project perspective. This view can jeopardize the effectiveness of program management and its capability to deliver strategies. Although it is now agreed that the objective of programs is to produce business level benefits by linking the strategy and projects, little management rhetoric has made its way into the program management literature and practice.

The current view of the program management life-cycle can be summarized through five generic stages or processes:

1. The Formulation stage, which consists of the definition of the program’s expected benefits through a stakeholder analysis and the agreement on the program purpose and objectives, which can include a functional blueprint. This process is iterative.
2. The Organization stage, which consists of the development of the program’s detailed business case and technical blueprint as well as operational procedures and structures. This process is iterative with the formulation.
3. The Deployment stage, which consists of the delivery of capabilities through the program’s constituent projects and other actions, including the transition into the business. This is a cyclical process.
4. The Appraisal stage, which consists of a program-level assessment of the benefits realization and evaluation of the success of the transition to operational benefits. This is also a cyclical process.
5. Finally, the Dissolution stage, which consists of the agreement on the timing and grounds for dissolution and implementation of the closing process, which includes long-term benefits measurement processes.

The formulation and the strategy development part of the organization stage are learning cycles, as is the appraisal of benefits realization. These stages require the application of value management tools and techniques. The structuring part of the organization stage as well as the management of projects in the deployment stage, are performance cycles where project management tools and techniques can be appropriately used.

The program life cycle diagram (Figure 3) exhibits the cyclical nature of programs where benefits are appraised on a regular basis and the resulting operational outcomes are used to realign the strategy, if required. Typically the cycles of the program life-cycle also correspond to periods of stability that enable the organization to absorb change at a rhythm that corresponds to its culture. These periods of stability, which usually correspond to stage gates, are typically determined when pacing the program.

Conclusion

Whether you are an executive, a sponsor, a user, a program or project manager, guides and standards can be useful, but it is your responsibility as a program stakeholder to understand what your role in a program is and how program management can help your organisation achieve its objectives.

Program management is the link between the business strategy and the value it will generate when implemented. It is the process through which executives will be able to express their needs and make sure they are fulfilled. Sponsors will be able to define the improvements they are expecting and clearly link them to the strategy to ensure they are realized and aligned with the business objectives. Program managers will understand how to support both executives and sponsors in a tangible way and how to deliver measurable results to the business. Project managers will understand how their role is essential to the program’s success and finally, operational and technical users will be able to make sure the expected improvements are well integrated and produce the expected results.

This white paper was first published in PMForum (The online journal) in April 2010. http://www.pmworldtoday.net/column_series/2010/april/PM-Beyond-Standards-Guides.html

Omar Zein, MBA, Prince2 Practitioner, MSP Practitione

Project Management Consultant
Projectize – London and Turin

Perhaps one of the latest trends in our industry has been the repeated use of the acronym PPP to quickly (and with less ink) say Project, Programme and Portfolio.

I have seen PPPMOs (meaning Project, Programme and Portfolio Management Office !!!), PPP Consultancies, PPP Professionals and often P3 to donate PPP in all the above.

Well, if it is saving us time and ink (it is rather lengthy noting Project, Programmes and Portfolio each time), then what’s all the fuss about !!!

At this point, you should know something about me. I am very fussy about the correct use of terminology in my field, and that field is PPP…….

Lets get some facts right:

• Programmes are not just large projects or a collection or projects
• Programmes have no activities in their own right. Activities fall only under projects and processes
• Portfolio simply put, is a portfolio (i.e. a collection….). It means nothing in itself. On the other-hand “Project” Portfolio Management has nothing to do with either project management or programme management
• From an operational (activity perspective), one can (not so safely…) say: ONLY POJECTS EXIST.

Don’t get me wrong, I am by no means belittling either Programme Management or Portfolio Management. On the contrary, they are absolutely crucial to the success of organizations and large initiative. But they are not similar. Neither to each other nor to Project Management. Little wonder there is so much confusion on the part of receptive organizations and professionals newly entering the filed.

I guess as always, the best way to clarify things it to go back-to-basics:

Projects: Have always been with us and I can with confidence say; there is no confusion there. We all know that “A project is a temporary initiative performed to achieve a unique product or service.” One way or another all definitions say the same. Key words are: “temporary” (not a process) and “unique” (in some ways, each product or service will always differ).

Project Management is the “application of knowledge, skills, tools and techniques to project activities in order to meet or exceed stakeholder needs and expectations from the project” PMBoK, PMI.

When we decide to move office location, develop a new product or build a bridge we are talking about Projects

Programmes: A programme is born directly out of a strategic need (i.e. the need to increase market share in a particular region, reduce staff turnover, or improve the local economy in Southern Sudan). Usually, when the programme is identified, the products or services to be later delivered are not yet known.

Once benefits relating to the strategic needs are defined and quantified, a number of projects and activities are initiated to help realise these benefits.

A program is defined as “a temporary, flexible organization created to coordinate, direct, and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organization’s strategic objectives”. Managing Successful Programmes – OGC 2007

A “Project” Portfolio is simply a portfolio of project. That is a collection of projects that are not necessarily related. An organisation’s project portfolio would refer to all projects undertaken by the organisation (and naturally that includes programmes as all programmes have projects to deliver their products and services).

Project Portfolio Management on the other hand, is the process of continuously reviewing the organisation project portfolio to ensure that all projects (and programmes) are aligned to the organisational strategy and are given the priority they deserve in accordance with that strategy.

Project Portfolio Management also insures that no useless projects are undertaken and that low-priority projects maybe slowed or delayed in order to user their resources on the higher priority projects.

A wise-man-said: “there is nothing so useless that doing efficiently that which should not be done at all” Peter Drucker

So here is what PPP managers do:

-In Project Management we manage and coordinate our project activities and resources in order to have our final product or service on time, on budget and to specification.

-In Programme Management we go further to coordinate projects and manage the Benefit Realisation and any Business Change that is bound to happened due to the scope of the programme.

-In Project Portfolio Management, we work with the top organisational management to understand their strategy and goals. We then make sure that no projects that do not contribute to such strategy are undertaken and that those that are, are prioritised according to their contribution. This is more a strategic than an operational role.

3 disciplines all start with a P…. But they are indeed distinct even if related.

Can you still blame me for cringing at PPPMOs and other PPPs ?

When saying Sawu Bona, the person is acknowledging the other person. The use of the “we” is because through that person, the community he represents and his “ancestors” are also acknowledging the person. It is not just “hello”, without further thoughts. It is recognition.

The counterpart says “I am here”, in the sense that “I can be validated”. “I am available to contribute”. I am also here with my needs, with my community and my history (ancestors).

During a project, how many times do stakeholders really acknowledge and respect each other? How many times there is this sense of recognition and respect of the person, and of awareness of his/her “ancestors” (professional past life, experiences and best practices learnt). In the rush of the project times, very often we place little importance on the context a certain person comes from, only to be seen as a resource and at best a project role.

The first lesson learnt from Ubuntu would be that of acknowledgment. If our project team is like a tribe then any newcomer should be acknowledged, sharing with rest of our Project Team his own value and that of his ancestors (experience he has and community he comes from).