Jun09Gartner 2009 PPM Magic QuadrantPosted at 20:04 in Project Management

Gartner just released their PPM Magic Quadrant for this year (if you want to compare to last year's PPM Magic Quadrant). Not many changes in the Leaders quadrant (Microsoft EPM is still there, so are CA Clarity; HP PPM; Compuware; and Planview (when I attended the 2007 Gartner Summit, I was clearly not impressed by this product, seeing it for the second year in the leader quadrant comes as a surprise to me); and Oracle who recently acquired Primavera); apart from Daptiv drops out to the visionaries quadrant (Tim, what happened?). This year's trend indicates that the global situation has had an impact on the PPM market (personnel lay-off; curtailing of product development; travel expenses associated with on-site PPM systems deployment; etc), and vendors are being challenged to reduce their pricing due to very low to no 2009 PPM budgets. Software-as-a-service (SaaS) might be the way to go.

Jun06Project reportingPosted at 07:36 in Communication, Project Management

Stacey Douglas published a very good post about communication management, and more specifically about "how much detail is enough for project reporting".

To make the long story short, there is an appropriate level of reporting coming from your PMO: if your project reporting does not dig deep enough, your organization will struggle by always asking for more; and so will it be if your project reporting goes too deep into the details, dragging everyone away from actually performing the work to be done. Déjà-vu? Of course, it happens all over the place.

There are no easy answers to this problem, and I believe it goes through skilled PMO leaders who know how to gather reporting requirements; and building trust between them and the business leader. Any suggestion about tools and techniques to succeed in this field?

Jun04The Chaos Report 2009Posted at 08:41 in Chaos, Project Management

The Standish Group has just released their 2009 Chaos Report, and things are not looking good, despite the growing trend of PMOs in companies. For the record, the Chaos Report collects and analyzes the success rate for projects in the IT industry. Below is the chart for 2009:

Some people argue that they are only measuring time, budget and scope (thus leaving out quality, risk and customer satisfaction, half of the "triple constraint"), but two things I have to say here: first of all, this is still the best benchmark for IT project management; and at least they measure the same since 1994, so we have something to compare:

Successful means on-time, on-budget, and with all features and functions as defined in the initial scope; challenged means late, over budget, and/or with less features and functions than defined in the initial scope; failed means cancelled prior to completion, or delivered but never used.

What it tells me is that we are not doing good. Seeing a marked decrease in project success rates when building a PMO is a leading trend in the industry for the past 12 months worries me somewhere. What is this the symptom of? Lack of organizational maturity? Lack of skilled and trained project management staff? Something else?

May22The Risk Management PlanPosted at 10:16 in Project Management, Risk Management

The Risk Management Plan is the key element of the Risk Management Process. It defines the Risk Process for the project, including Methodology, Roles and Responsibilities, Timing, Thresholds, Reporting, monitoring and review formats and procedures. You can find several templates on the net (like this one from PMHut), but what is really important is how you will use it, and how well it suits your own risk management processes. Amongst all criteria for judging the maturity of such a document, the two the most important in my eyes are the ability to manage threats as well as opportunities, and the ability to efficiently respond to a risk becomes an issue.

What is the risk? Why might it occur? How likely is it to occur? How bad or good might it be? Does it matter to the project? What can we do about it? When should we act? Who is responsible for the risk? Who is responsible for the response? These are all questions that should find answers in the Risk Register (part of the Risk Management Plan). This document must be reviewed and updated regularly, since new risks might arise during the lifetime of the project, and risks might realize, becoming issues, needing responses that might trigger new risks, etc.

In my Risk Register, I typically have 13 columns:

• The RiskID, which is the unique identification for a risk, used by everyone to refer to that specific risk.
• The ProjectID, which is the unique identification for the project within the corporate portfolio. If a risk is likely to happen in several project, it needs to be documented with several RiskIDs.
• The Risk Category helps predefining responses or owners. It also serves for reporting purposes, thus helping on the predetermination front for future projects.
• The Date Raised serves to track the evolution of the risk profile of a project. The more stable the risk register, the lower the risk profile of a project.
• The Risk Owner has the ultimate responsibility to monitor the risk, and to raise the occurence of the risk to the Risk Manager. This needs to be documented in the Roles and Reponsibilities section of the Risk Management Plan.
• The Risk Description is ... well ... the description of the risk.
• The Impact is the result of the Risk Qualitative Analysis process. This field will usually have three possible values (low/medium/high), or if you want to more precisely rank your risks, five possible values (very low/low/medium/high/very high).
• The Probability is the result of the Risk Quantitative Analysis process. This field will have similar values as the Impact (i.e. 3 or 5 possible values).
• The Priority is a calculated field (which is why I usually use an Excel spreadsheet for my risk registers, unless I have access to an Enterprise Project Management software. It is a combination of Probability and Impact, and you can live without it, it just allows a quicker filtering on those who need your attention.
• The Response Description is ... well ... the description of the response to the risk.
• The Response Type is one of the following: Avoidance, Trnsfer, Mitigation, Acceptance. This will also help monitoring the efficiency of the risk management processes.
• The Response Owner has the ultimate responsibility to act in the event of a risk realized. It can be someone else as the Risk Owner, and it needs to be documented in the Roles and Responsibilities section of the Risk Management Plan.
• The Realized Date is the date when a Risk has triggered. This is the moment when a RiskID leaves the Risk Register to enter the Issue Log to continue being monitored in this document.

I understand this might look a little cumbersome, but in most situations, it can be the difference between saving a project and pulling the plug...

Mar30The ideal size for a teamPosted at 08:24 in Project Management

I stumbled upon an article from Ken Thompson, The maximum team size for effective working, based on The Dunbar Number as a Limit to Group Sizes from Christopher Allen. While Christopher's post talks about groups in general (online gaming, social networking, etc), Ken tries to be more specific to the work environment. In short, he says: "Your teams are too big: break them up". He is right, there is an ideal size for effective teamwork. Too small teams lack resources and are unstable; while too big teams split into factions and need more individual attention than possible due to lack of time available to maintain relationships. He says the ideal team size for optimal teamwork is 5 to 9 individuals, which I tend to agree roughly. What do you think?

Mar27Pulling the plugPosted at 12:59 in Communication, Project Management, Risk Management

Very few organizations are capable of admitting that possibility of success is gone and that a project is failing. If expected benefits can't be delivered and deadlines can't be met, for the greater health, such projects must be terminated. It is never an easy decision to make, and it requires an objective and pragmatic analysis: Trade-offs need to be carefully weighted, and you need to have a comprehensive plan to address all anticipated issues (politics, expenses, relationships, etc).

Pulling the plug is important, because the cost associated with continuing the project might be (much) higher than the cost of terminating the project. This is valid for every single type of project, even a job hunting project: sometimes, it is better to back off if you don't feel comfortable with the way things are looking like.

Mar15An uncertainty that mattersPosted at 22:12 in Project Management, Risk Management

It has been a long time since I wanted to talk a bit more about risk. Risk Management is one of my preferred knowledge areas in the Project Management Body of Knowledge, but the sad thing is that it is often misused. It starts with the definition of a risk. In the common language, a risk has always a negative connotation: it refers to the possibility of misfortune or loss; to hazard; to something exposing to danger; perilous. To be honest, most people just keep looking at that single side of the coin. If you want to implement an integrated risk management process, you will have to consider that risk isn't always just a bad thing.

The PMI defines risk as an uncertain event or condition that, if it occurs, has a positive or negative effect on an objective. Dr. David Hillson has a much simpler definition of a risk: an uncertainty that matters. I love this sentence. It clearly outlines the two dimensions of a risk: the uncertainty (or probability); and the effect on objectives (or impact). That makes things easier to understand: if you can predict 100% of chances for something to happen, then it is not a risk. Nor is it a risk if it is uncertain, but has no impact at all on the project or its deliverables.

That being clarified, the PMBOK defines Risk Management as the systematic process of identifying, analyzing and responding to risk. There is a suitable set of processes in the framework to deal with risks, that works for both threats and opportunities. These processes naturally follow the phases of a project, but really need to be taken seriously. Underestimate them and chances are high that you will end up pulling the plug.

Coming next: The Risk Management Plan

Feb15Chaos & Project ManagementPosted at 11:15 in Chaos, My Work, Project Management

You might have noticed that I have renamed my blog to "Lost in Chaos". I'm not talking about my geographical location, although some people might argue that it would be a perfect match. No, I'm here talking about Chaos in Project Management, which is my favorite field of research, and I intend to post more about it in the future.

The word chaos did not initially mean "disorder", but this became the common acceptance of its meaning as of today. Mathematically, Chaos means "an aperiodic deterministic behavior which is very sensitive to its initial conditions" (i.e., small perturbations of the initial conditions lead to large variations). A chaotic system typically looks random but is not: It is very difficult to predict accurately, but still predictable if you have enough information (it is called a deterministic system, e.g. weather forecasting). The whole idea behind my work, and this re-branding of my blog, is to be able to reveal patterns of order out of seemingly chaotic systems (a.k.a. Projects), and why not use this information to "Control the chaos" !

Oct20IBM CIO Conference 2008Posted at 16:25 in Dubai, Project Management

Yesterday, I attended the CIO Conference 2008 from IBM at the Atlantis Hotel on the Palm Jumeirah. Key Senior Executives of IBM and other Senior Industry Leaders from Banking, Telecommunications and Public Sector presented on the trends for tomorrow's enterprise. IBM is conducting every two years a CEO Study shedding light on what the future may hold. Through interviews with 1'130 business and public sector leaders worldwide in 45 countries, they provide new and compelling perspectives on strategic issues. The tagline of this conference was "Design for people, Build for change" and the content of it was as great as the venue.

Sep29OPM3Posted at 09:47 in Project Management

Two weeks ago, I attended a workshop on OPM3 (Organizational Project Management Maturity Model), organized by the PMI Arabian Gulf Chapter ang given by Lotfy Sabry (OPM3 certified consultant #2). This is the only project management maturity model developed with the input of thousands of professionals across 35 countries using a monitored and open consensus building process resulting in an industry standard providing requirements for assessing and improving capabilities in project, program, and portfolio management (source: Wikipedia). I found it quite useful to see something above the discipline I'm currently working in, and to see true organizational benefits coming out of it. I will definitely be pursuing the Assessor/Consultant certifications, once PMI opens the registration again.

All content (435 posts since 25/06/04) published on this weblog is © Frédéric Casagrande, unless stated otherwise and published under Creative Commons licence. This weblog is hosted by Sixapart.

This weblog uses third-party advertising companies to serve ads when you visit it. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.