Tuesday, September 20, 2011

Can PMO's and Centres of Excellence Coexist?

Project Management Centers of Excellence (PMCOE) are becoming increasingly popular as a solution for organizations to streamline their processes while increasing efficiency, profit and competitiveness.

Generally, a Center Of Excellence (COE) is a business unit that has organization-wide authority. It coordinates continuous improvement initiatives, ensures that value is achieved in all areas, and fulfils the role of organizational thought-leader or consultant.

COEs are also created to capture an organization's best practices, standards and industry benchmarks. The COE facilitates the approval, transfer and integration of these best practices across the organization. For example, in a global manufacturing company, the COE may identify a best practice used in its European plant, tweak it, and implement the practice in its Saudi plant, too.

There seems to be confusion between the roles of a Project Management Office (PMO) and a PMCOE. Some argue that the PMO sufficiently leads the organization to project management excellence. So, why would an organization with a well-structured PMO need a PMCOE?

In his book, Advanced Project Management: Best Practices on Implementation, Second Edition, project management expert Dr. Harold Kerzner states:

"The definition of project management excellence must extend well beyond experience and success ... Success is measured by having achieved performance that is in the best interest of the whole company, as well as having completed a specific project."

PMOs and COEs are only successful when they achieve the objectives for which they are created. Leaders in the profession note that the number of projects or years an organization has been delivering projects can't define project management excellence. Neither can the methodology it follows.

Larger, complex organizations may need a PMO and a PMCOE -- but their roles should be clearly defined.

A PMO is an important central hub with a mandate to coordinate and deliver all project activities as determined by the organization's needs.

PMCOE executives would operate as part of the business decision-making process. These individuals would report on the organization's project portfolio as a whole and provide the organization with project consultancy.

The PMCOE also supports the PMO through research, innovation and leadership initiatives and bridges the gap between PMO teams and business units within the organization.

Article by Saira Karim for Voices on Project Management.

Tuesday, September 13, 2011

Windows 8 – Finally Providing Competition for Linux?

The “one platform” approach

Windows 8 retains the “old style” Windows desktop as, essentially, another app in the Metro interface. The result is a single OS that is both tailored to tablets, but also to mouse-bound desktop users.
On a Linux related note, Ubuntu 11.04 saw Canonical fold the various netbook spins of Ubuntu into the main release. Similarly, although Canonical insist that Ubuntu is not heading to the tablet sector any time soon there’s no denying that various developments to the Ubuntu interface – particularly with regard to Unity and uTouch – mean Ubuntu already functions well on a tablet, although is by no means ideal.
Windows 8 is being sensible in this ‘unification’ approach. It’s less confusing for consumers, and easier for developers. That said, I still somewhat expect Microsoft to stuff it up by announcing an ensemble of “Tablet Edition Premium” and “Desktop Metro Home Professional” varieties.


Article by Joey Sneddon for OMG Ubuntu

Read full article at: http://www.omgubuntu.co.uk/2011/09/windows-8-interesting-competition/

Mitigating Risk with Project Advocacy Consultants

Besides scope, time and budget, the core of project management success is stakeholder acceptance of project deliverables. As such, the risk of stakeholders rejecting deliverables should be identified and mitigated in a project's early stages.

For example, stakeholders in infrastructural development projects, like members of a surrounding community, make certain choices about project execution, such as location, quality and schedule. But, this doesn't always happen. If residents, say, are denied vehicular access to their homes because of an ongoing road re-construction, it's clear there was no stakeholder representative during the execution planning of the project.

African governments often rely on public private partnerships (PPPs) for utility and infrastructure projects. But most proponents of PPPs settle for a design-bid-build business arrangement, in which a single vendor may win concessionary bids to develop, operate and transfer utility infrastructure schemes. In this instance, a concessionary bid is a solicitation process for PPP projects.

This kind of business arrangement increases the risk of eroding the values and interest of that community. Sponsors and vendors could decide to satisfy themselves to the detriment of the residents or other project beneficiaries.

One way to mitigate the risk of communities rejecting infrastructure projects could be to use project advocacy consultancies, which are composed of community and government representatives. The committees ensure that infrastructure projects address the needs of the communities and are accepted by them.

In Africa, it would be a major stride in project management if stakeholders approved of the deliverables of PPP infrastructure projects. Of course, projects would be more widely accepted if communities were involved during the planning and execution of deliverables.

In my opinion, highly leveraged infrastructure projects that are initiated under concessional business arrangements and executed without the involvement of the would-be users should be discouraged. In turn, profits made by promoters and vendors from infrastructure projects could be better justified vis-à-vis community acceptance of the deliverables.

If communities approve of infrastructure projects, post-project operations and facilities management, it would benefit everyone. Promoters would smile at the projected cash flows, vendors would satisfy both contractual and project obligations, and ultimately, the project would be successfully completed.

10 Years of Agile - the Prophecy of Failure and the Failure of Prophecy

If complexity is going to be happen anyway, we have to allow those patterns to emerge from the interaction of people on projects, and from the interaction of those projects themselves. We're guilty, as a community, of signing up to "individuals and interactions over processes and tools", then mandating processes to control the interactions, while supporting the processes - and not the interactions - with tools. In future, the practices we teach will be those which enable interactions, rather than controlling them. We've seen this already with the rise of metaprocesses like Kanban. Models for understanding complexity, and particularly the complexity of people, are also being taught in Agile conferences worldwide - Systems Thinking, Complexity Thinking, psychology and sociology.

These are also the kind of practices we need to change behaviour at higher levels in the organisation; to make the impact of anti-patterns apparent. We haven't seen as much change as we prophesied at the beginning. Maybe over the next ten years, we'll see a different manifesto emerge - one which starts, "We are uncovering better ways of enabling change by doing it and helping others do it."

About the author:
Liz Keogh is an experienced Lean and Agile coach, trainer, blogger and well-known international speaker. Coming from a strong technical background, her work covers a wide variety of topics, from software development and architecture to psychology and systems thinking. She is best known for her involvement in the BDD community, and was awarded the Gordon Pask award in 2010 for deepening existing ideas in the space and "coming up with some pretty crazy ones of her own".

Read full article at:
http://www.infoq.com/articles/agile-prophecy-failure

Monday, September 12, 2011

Different Perceptions of Risk on Projects

1. Risks as facts: Risks are treated as objective, technical, neutral events that can be managed based on the knowledge produced by objective analysis using probabilities and expected values. The outcome is rational decision making.

2. Risks as subjective constructions with multiple dimensions: Risk managers choose the context and perspective they adopt. This allows multiple rationalities to coexist, depending on the values and perspectives of the observers. (This explains why some people find jumping out of an aircraft fun.)

From a project perspective, risks are uncertainties that matter. All estimates about future project outcomes incorporate a degree of uncertainty. This includes the three key dimensions of project management: timing, cost and quality of future project deliverables.
 
The project manager cannot be certain that the estimates that make up the project schedule or cost plan will prove to be correct, or that the project team will create deliverables to the appropriate quality standards. The rational management approach is to assess the risk factors and develop appropriate time and cost contingencies, backed by appropriate reviews and tests to ensure optimum quality. This approach is highly objective and rational.

However, you cannot rely on your stakeholders having the same view as you. If a stakeholder sees your project in a different context, their perspective on risk will be different.

For example, if you created a contingency plan using a Monte Carlo analysis, an executive may interpret the plan as a sign you don't understand the project because he or she expects a single definitive result. From this stakeholder's perspective, the precise calculation of a critical path method schedule offers certainty and minimum risk.

The authors of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) have a different perspective, which understands the benefits of 'three-point estimating.' You cannot assume your stakeholder will have the same view.

The challenge is to accept that a range of stakeholder perspectives will occur. Stakeholders may derive completely different opinions from the same data.

You should anticipate this possibility and adjust the way you package your project information to communicate more effectively and ensure both you and your key stakeholders have a common understanding of the risks and issues confronting you project.