Enterprise Architecture in Spain.: P3O

Mostrando entradas con la etiqueta P3O. Mostrar todas las entradas

domingo, 10 de enero de 2016

Strategy Planning, IT Portfolio Planning and the role Enterprise Architecture plays in it

https://sites.google.com/site/articlesledsneed/home/strategy-planning-it-portfolio-planning-and-the-role-enterprise-architecture-plays-in-it

miércoles, 29 de abril de 2015

BE A MINDFUL PROJECT MANAGER

http://www.projecttimes.com/kiron-bondale/be-a-mindful-project-manager.html

Lean PMO as a change agent

http://www.slideshare.net/PepeVazquezS/lean-kanbanpmo-as-change-agent

lunes, 13 de abril de 2015

Enterprise Transformation Office

https://www.linkedin.com/pulse/eapmo-matthew-kern

A PMO or Project Management Office is an element of the enterprise that maintains project management standards. Enterprise Architecture plans and monitors enterprise transformation. The two may be (and have sometimes been) combined in an EAPMO.

Other approaches to enterprise transformation or improvement fall far short of the breadth of vision and potential gains of agility, efficiency and effectiveness offered by the EAPMO organized to combine oversight of all transformative projects. I suggest the term Enterprise Transformation Office or ETO for this kind of organization.

PMO: The project management office (1,2) commonly maintains standards for project management, program management and portfolio management. It is a single unique operation within the enterprise. As the enterprise should have only one portfolio to avoid suboptimization, there is discussion as to if the PMO should perform the portfolio management for the organization.

EA: Enterprise Architecture, as described in FEA and FEAF, is decision support for organizational portfolio management. It is closely connected to portfolio management in its main or top-level process. (3,4,5,6,7,8,9, 10) EA and portfolio management should be organizationally close, tied together, to achieve gains through transformation.

Transformation: Transformation changes the enterprise, improving operations or creating new capabilities. The primary means of causing this transformation is the project, possibly organized into programs, and managed by the portfolio. This is differentiated from functional or operational management which oversees steady-state operations in the enterprise. The primary purpose of the PMO is to achieve organizational transformation. (11,12,13,14, 15, 16) Again, organizational proximity would help.

Portfolio Management: There are strong reasons to integrate, or tightly relate the portfolio management function with its enterprise architecture decision support. These are intended to operate in a tight cycle. If you also agree that the PMO should perform the organizational portfolio management, then there is significant potential synergy in combining the PMO, EA and portfolio management in a single organizational unit. (17,18)

Such an organization would contain experts in the distinct disciplines of EA, project management and portfolio management, presumably in distinct sub-units, located together for organizational efficiency. It would possibly be headed by the person responsible for organizational transformation.

When these functions are not combined significant synergy, efficiency and effectiveness can be lost.

(In the US Federal Government portfolio management is called CPIC. The relationship between EA and portfolio management is described in OMB Circular A-130, and this relationship is the policy of the US Federal Government. Program and project review is also describe there as the "control" and "evaluate" phases of CPIC. Compliance with law and policy requires that these be treated together for all IT. Best practice would have these functions combined for non-IT as well, all transformational efforts of any kind.)

Roadmap: A roadmap is a schedule for transformation efforts. The enterprise transformational roadmap is a central artifact for both a PMO and EA. (19) Combining would again improve effectiveness.

Waste: Placing EA in the PMO can reduce waste. (20,21)

Governance: Unifying EA and PMO governance can save effort. (22,23)

Standards: The PMO promotes and possibly audits for standards applied to projects and programs. EA is intended to be the standards clearinghouse for the organization in various frameworks. This function can and should be unified. (24)

SDLC: The system lifecycle is a standard that should be managed and enforced by EA and PMO efforts, together. (25)

Vision: A key product of EA is the vision of the target (to-be) enterprise. This is what the programs and projects are attempting to create. There is bennefit in having that function performed in the PMO. (26)

EA Principles: Principles describe how projects and programs will perform transformation. There is benefit in having the PMO select and promote EA principles. (27)

Strategy: EA seeks to create a portfolio that implements the strategic plan. The PMO also seeks to create and management the portfolio of projects and programs to implement the strategic plan. There is benefit in unifying or centralizing these functions. (28, 29, 30)

Business and Technical Drivers: EA tracks the forces that drive organizational change, attempting to accommodate, leverage and even anticipate these forces. It is advantageous to merge this function into the PMO. (31)

Innovation: An ETO style EAPMO can reduce barriers to innovation and improve agility. (32)

Acquisition or Procurement: Each project or program must select implementation methods for its bit of organizational transformation. Some efforts may be outsourced. Some may be purchased. Some may be developed within the organization. Many require purchase of supporting software or other elements. With an ETO/ EAPMO acquisition or procurement is tactical support for the strategic efforts of the ETO, applied to the project or program. In effect, the ETO implements "strategic acquisition" or replaces any notion of or independent implementation of "strategic acquisition". However the ETOhas greater potential to do so in an effective and compliant way vice modern current organizational standards. (33)

Audits and IV&V: The ETOis the proper place to sponsor or conduct audits and IV&V (Independent Verification and Validation) Efforts, in addition to program or project reviews and progress reporting. (34)

Conclusion: If you perform portfolio management, enterprise architecture and management oversight of programs and projects then you should probably combine these functions into an ETO style EAPMO. There is significant overlap of function, and significant synergy to be achieved.

References:

lunes, 6 de abril de 2015

Requirements Management

http://www.pmi.org/learning/requirements-management/resource-library.aspx

http://www.projectmanagement.com/Practices/Requirements-Management/

miércoles, 4 de marzo de 2015

Praxis Framework

http://www.praxisframework.org/

martes, 24 de febrero de 2015

Los Hábitos de un Director de Proyectos Eficaz

http://jose-barato.blogspot.com.es/p/about.html

domingo, 15 de febrero de 2015

Trello

http://es.gizmodo.com/como-organizar-toda-tu-vida-utilizando-trello-1684529913

lunes, 15 de septiembre de 2014

ITPM = APM + PPM + RPM + ???

http://projectmanagement.ittoolbox.com/groups/strategy-planning/it-portfolio-management-sp/itpm-apm-ppm-rpm-1833134

IT portfolio management surely means different things to different people.
I notice Wikipedia defines IT portfolio management as comprising three
strands:
APM: applications portfolio management. (My main interest.)
PPM: projects portfolio management.
RPM: resources portfolio management.
.
My question is this: Why doesn't it include technology portfolio management?
Supposing technology includes desk tops, servers and infrastructure that
runs on them?

jueves, 11 de septiembre de 2014

CITPM

http://www.itbmcomat.com.sg/Courses/ITProjectManagement/CITPM.aspx

jueves, 3 de julio de 2014

17 Tools for PM

http://www.calidadytecnologia.com/2014/04/herramientas-Open-Source-Gestionar-Proyectos.html

domingo, 11 de mayo de 2014

An enterprise architect’s view of capability maps

http://ashridgeonoperatingmodels.com/2014/05/01/an-enterprise-architects-view-of-capability-maps/

http://enterprisearchitects.com/business-function-does-it-have-a-place-in-business-architecture/

I would personally prefer to define a capability as a grouping of organisational resources or assets (i.e., people, information, tools) and processes, necessary to deliver one or more strategic objectives.

viernes, 25 de abril de 2014

The Difference between Service Catalog and Service Portfolio

http://www.intact-tech.com/blog/service-portfolio/

miércoles, 9 de abril de 2014

Making Better Decisions in Project and Portfolio Management

http://link.brightcove.com/services/player/bcpid1247065358001?bckey=AQ~~,AAAA0vRfbjk~,bxfECA99Y1BXdWeSwQwKxfISk6c6Mrxs&bctid=1799535609001

martes, 8 de abril de 2014

Power, the 5th Element

http://bauzanotebook.blogspot.mx/2013/05/governance-models-how-enterprise.html

In the traditional diamond shaped model used by consultants (where Strategy, Process, Technology and People play a part) there is a 5th element, Power. In most of the projects I have participated (ranging from Post-Merger Integration to Supply Chain consolidation), the dynamic of the power for a recent created capability is always an issue. The problem is that if we don´t define power relationships properly, the sustainability of the “diamond” will be in jeopardy.

Defining Governance Models is a mix of science and art, where the specific power dynamics within the organization plays a critical part. In the other hand, all Governance Models are not created equal, although they have several aspects in common.

In this article, we are going to explore the power dynamics (or Politics) between the Governance models for three specific capabilities in the organization: Enterprise Architecture, Balanced Scorecard and Program Management Office. It is clear that there are others governance entities that will interact with these three players (i.e. IT Governance Model, CAPEX governance, etc.), however, we will focus in the mentioned above.

How to define Governance Models, a framework

Governance Models are defined in all projects, but sometimes they look fuzzy and without a specific purpose. In order to solve this problem, it is required before drawing boxes and lines, to define clearly 7 elements that will help to create the guiding design principles for the Governance Model. Such elements are:

Sometimes, we rush to define a Governance Model without having crisp and clear the elements mentioned above. We are going to elaborate about some of these 7 key questions for EA (Enterprise Architecture), BSC (Balanced Scorecard) and PMO (Program Management Office).

The Seven Key Question for EA, BSC and PMO governance

The first step is to respond to the mentioned key questions of the framework. In this article will focus on questions 1,2, 5 y 6. It is important for the organization to know why the enterprise will concede a quote of power to the newly created entity. Also, for communication purposes it is necessary to properly respond to these questions to the organization.

Key questions
EA
BSC
PMO
Why a governance model is needed?
In order to design, implement, manage and measure the EA.
In order to achieve vision/mission/strategic objectives in a structure way, aligning the BSC perspectives, initiatives and KPIs.
In order to achieve program and project objectives, in time and fulfilling project client quality expectations.
What is governed?
Business architecture framework.
Meta-architecture.
Enterprise Architecture model.
Process orchestration (BPM/SOA).
Dimensions of the EA.
Process KPIs.
Standards, methodologies and techniques for EA.
Strategy.
Strategy maps.
Strategy KPIs.
Initiatives.
Standards, methodologies and techniques for BSC.
Program and projects execution and tracking.
Program and project KPIs.
Standards, methodologies and techniques for PMO.
Who will govern what?
EA Governance processes and rules.
BSC Governance processes and rules.
PMO Governance processes and rules.