Issue 12 - January 3, 2010

In this issue:

• The series by Aaron Shenhar, Unleashing the Power of Project Management, wraps up with the last article: "Part 4 - The New Adaptive Project Management Framework". 
• Following that is the third article in a series on "Common Barriers to Successful Projects" by me, Ray Posch. 

PM Insights
See PM Insights, our new blog for conversations and shared insights about project management. http://www.pminsights.com/

Authors Welcome
If you are an experienced project manager and would like to write articles for the newsletter, please email me at ray@projectsuccesstips.com. We are looking for first-person project stories with real take-away insights.

Unleashing the Power of Project Management
Part 4 - The New Adaptive Project Management Framework
By Dr. Aaron J. Shenhar

Based on our research we suggest changing the paradigm of project management and accepting things as they are. The new framework is success-focused, flexible, and adaptive, and we can simply call it the “Adaptive Project Management Model;” it differs from the traditional approach in several ways, as shown in Table 1. 

Table 1: From Traditional to Adaptive Project Management 

According to this model projects are not just a collection of activities that need to be completed on time. Projects are business-related processes that must deliver business results. They are not predictable or certain. Rather, they involve a great deal of uncertainty and complexity, and they must be managed in a flexible and adaptive way. Planning is not rigid, fixed, or done once and for all; instead, it is adjustable and changing, and as the project moves forward, re-planning is often appropriate or even unavoidable. Project management styles must adapt to the specific project and its requirements, and one size does not fit all. While this approach represents a shift in thinking, it is inevitable to meet today’s organizational challenges. While no framework could provide all the answers, we believe that every organization can significantly improve its business results and achieve more homeruns from its projects if it will consciously apply the adaptive project management frameworks. 

One final word: We do not suggest, however, eliminating the traditional approach. Rather, we are building on it. Many elements of traditional project management continue to be useful; yet, the overall approach will be augmented. As established by the conventional approach, each project must have a work breakdown structure, a schedule, a budget, an organization and a process. All those are necessary building blocks for well-organized successful projects. These building blocks will only form the baseline to leading the project in a flexible way. Not only do projects have to monitor and review their progress, they must periodically examine the need for the product and the customer’s position. Are the initial assumptions still valid? And if not, what adjustment does the project have to make in order to guarantee better success. Furthermore, in many projects it is impossible to build a clear and detailed plan. The uncertainty involved is simply too high to enable creating a clear project plan with all its bells and whistles. Instead, companies must initiate pilot programs, namely, small-scale efforts that will help remove some of the unknowns before the company can commit to the major large effort. In other situations, managers must create product prototypes that will be tested by customers before the final product requirements are set and determined. 

In sum modern projects involve a great deal of uncertainty and complexity, as well as other constraints such as time, political pressures, economical risks, and many others. Each project is unique and it has to be managed it its own way that best fits it unique characteristics, risk and complexity. Only after companies learn how to manage projects in an adaptive and flexible way, will projects become the powerful competitive assets that they can be.

Dr. Aaron J. Shenhar is a Professor of Project and Program Management at Rutgers Business School and the CEO of the Technological Leadership Institute, a consulting and training company in technology and project leadership— http://www.tli-llc.com/. He is the coauthor of Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, Harvard Business School Press.

Common Barriers to Successful Projects - #15-21
By Raymond Posch

In this series, I am writing briefly about some barriers to project success that are fairly common in my experience. Here are the next seven in my list:

15. Not getting team commitment to the plan – When the plan is developed with team involvement, they will naturally be bought in. But by asking them to commit to the plan, they will more likely point out where they have doubts about or problems with the plan. When the team resolves those issues and commits individually and collectively to the plan, probability of success quadruples. Believe me.    
16. Not involving sponsor and stakeholders in the planning process – The sponsor or customer representative needs to be heavily involved in the planning process because the business/customer organization will be the users of the results and should best understand what is needed. Stakeholders also have some vested interest in the project or the results (since that is the definition of “stakeholder”). Therefore, they need to be involved in the planning process also, but it may be at the beginning and at selected points rather than throughout.  
17. Not leveraging the team throughout the project – The power and synergy of the team can be tapped throughout the project, not just during planning. Keep them informed about the external aspects of the project anything that might impact the project. Remind them of the business goals and expected results for the business/customer. Discuss risks and mitigation plans on a regular basis. The team will provide inputs, ideas, and solutions far more effective that you, the PM, could come up with on your own.  
18. PM not removing obstacles to the team in getting their work done – One of the jobs of the project manager is to facilitate the team in every phase of the project. If something is negatively impacting the progress of the team, the PM must identify that something and eliminate or minimize its negative impact, if possible. One of the big problems today is excessive multi-tasking – project specialists being assigned to work on too many projects at the same time. Negotiation with the resource managers on behalf of your project comes with the territory, but the ideal – getting bigger chunks of the specialists’ time is not always doable. This can be one of those things that needs to be escalated up the management chain.  
19. Poor communication with sponsor and stakeholders – The PM needs to learn about the sponsor’s and stakeholders’ requirements, concerns, and interests in the project. One-on-one discussions, with the PM doing a lot of listening, is often the better way to do that than in group meetings. It is also a good way for the PM to build relationships with these individuals based on direct interaction and learning about the people, their business roles, and what they think (or feel) is most important to them relative to the project.  
20. Inadequate team resources – If the project manager cannot arrange with resource (i.e., team or department) managers to have the right number of people with required skills for the necessary level (%) of effort when needed, then obviously the planned schedule will not be achieved. This is a common problem in many cases, especially when too few people are being asked to support too many projects.  
21. Pulling resources off for “higher priorities” – One of the most frustrating situations for PMs is to think that they have people with the right skills and right personality fit committed to the project on a planned schedule, or even working on project tasks, only to have them pulled off to work on some higher-priority project. This is deadly, because even if there is someone else with equivalent skills available, they may not be as familiar or up-to-speed on the project, or they may not be as good a fit with the team, and the net result may be that much greater time and PM attention may be required to get the planned tasks completed. 

Raymond Posch is publisher of Weekly PM Insights newsletter as well as being a full time project manager. See Ray's bio on our Meet the Experts page. He can be reached at ray@projectsuccesstips.com.

Issue 13 - January 10, 2010

In this issue:

• Glen Alleman discusses risk management frameworks in the third article of his series on programmatic risk management. (We didn't come up with a snazzy title, like I suggested we should, but Glen has included some sexy diagrams that are worth studying.) 
• We take a look at more barriers to project success in the last article of a series by me on common problems to avoid. Those issues that are organizational in nature, of course, are somewhat out the PM's control - but maybe you have an executive sponsor who can help. 
• Elizabeth Harrin examines the results of a survey on PMO effectiveness. If you're in a larger organization that has a PMO, I hope it's a good one. (The best PMOs, in my opinion, focus on making projects successful rather than on enforcing a bureaucratic process.) 

By the way, Happy 2010!  I hope you have a great year.

Authors Welcome
If you are an experienced project manager and would like to write articles for the newsletter, please email me at ray@projectsuccesstips.com. We are looking for first-person project stories with real take-away insights.

Risk Management Frameworks
Part 3 in a Series on Programmatic Risk Management
By Glen Alleman

Let’s start with a quick review of the previous two articles in this series on Programmatic Risk Management. This article will establish the principles of Risk Management, ending with one of the top level approaches to communicating about risk status.

Programmatic risk arises from three sources: (1) the naturally occurring “noise” in the cost and schedule. This is called the Deming risk. Attempts to control this type of risk is a waste. (2) The variances that emerge dynamically through the interactions of the work elements of the schedule, the cost components, and of course the performance of the technology. This is a stochastic risk driven by the underlying probabilistic activities of the planned work. (3) The technical risk causing unplanned delays and cost overruns. 

Managing all three of these risk types calls for a structured approach. There are many suggestions for managing risk. Some are actually credible. Let’s start with a framework for managing risk that is a guide for assessing the success of any specific risk management approach. 

There are two primary frameworks: 

1.  The Software Engineering Institute’s Continuous Risk Management, 
http://www.sei.cmu.edu/solutions/risk/. Start with the tutorial titled Rethinking Risk Management: NDIA Systems Engineering Conference.
http://www.sei.cmu.edu/library/abstracts/risk/upload/dorofeetutorialndia09_8819.pdf

2.  The US Department of Defense Risk Management Process, 
http://www.acq.osd.mil/sse/docs/2006RMGuide4Aug06finalversion.pdf

Both frameworks take care to separate Issues from Risks. Risk management is the overarching process that encompasses identification, analysis, mitigation planning, mitigation implementation, and tracking. 

An important difference between issue management and risk management is that issue management applies resources to address and resolve current issues or problems, while risk management applies resources to mitigate future potential root causes and their consequences. 

The Software Engineering Institute’s CRM has the following structure:
 

While the US DoD Risk Management process has the following structure: 

Both have similar elements and both have been field proven in a variety of domains. The SEI paradigm is centered on software development, while the DoD paradigm has a more general purpose approach. 

Both these paradigms appear to be complex and overbearing in many project environments. But it turns out the failure of risk management is high in many commercial IT environments because of these missing frameworks. You can pick one of the other, but you need to pick one.  

So Using One of These Risk Management Paradigms, How Can You Take the First Steps?

Managing programmatic and technical risk involves more than making lists and checking them twice, it means actively “mitigating” risks with the same project management processes used to deliver the project: 

• Risk is the possibility of suffering a loss  
• Risk management provides the mitigations to address the possibility of suffering a loss  
• A risk adjusted plan identifies risks (probability of occurrence) and mitigations (cost and duration) that maintain the cost and schedule baseline  

Let’s start with some core project failure modes:

• The defined project deliverables are not feasible given the time, cost and technical measures  
• The project deliverables are feasible, but their timing and resource objectives are inadequate for delivery 
• The project deliverables are poorly planned and behave in chaotic ways for cost, schedule and technical measures   

Let’s look at the four standard approaches to “handling” the risks. Identifying, analyzing, planning, and monitoring are important as well. But let’s start with the end in mind – how do we handle the risk? 

• Avoid: alter the approach to the problem and bypass that path in the project network. 
• Transfer: assign the risk to team that can mitigate the risk 
• Assume: assume the risk with no further action other than to watch for a change. 
• Mitigate: the risk by executing the tasks needed to reduce its likelihood and any consequences from its outcome. 

Before ending this article, let’s look at the next most important activity. “Communicating” the reduction of risk. One powerful approach is to show physically how the risk is being reduced with the passage of time. This is a sample from the Active Risk Manager (ARM) tool.  

The key here is to show not only the starting status of the risk, in this case RED, but to show explicitly when the risk will be reduced. With this approach, risk management follows the Tim Lister advice:

Risk Management is How Adults Manage Projects

The next article will show you how to perform the other activities in risk management and construct the picture above in simple Excel spread sheet extracted from Microsoft Project.

This article is part of a series by Glen on risk management. See Glen's bio on the Meet the Experts page. He can be reached at Lewis & Fowler or at his blog, Herding Cats.

Common Barriers to Successful Projects - #22-27
By Raymond Posch

In this series, I am writing briefly about some barriers to project success that are fairly common in my experience. Here is the last set in my list:

22. Lack of resource management in the organization – Of course there is some kind of “resource management” in place, but if the organization has not stepped up to managing specialized people resources in effective ways for competing projects, there will be many issues like several mentioned in this list.   
    
23. Not identifying and managing risks – All large and complex projects have risks which must be taken into account. Risks are known (identified) or unknown (unidentified) events that can have an impact. (They are usually negative impacts, although positive events/impacts can happen too, and they’re called opportunities.) Consideration must be given in the planning process to the events that are most likely to occur and/or that would have the largest impact. For those, the team should spend some time, based on probability of occurrence, of how to deal with the risk either beforehand or when the event occurs. Some of these risks, if appropriate, might justify bringing in some people (executives or specialists) from outside the core team to make recommendations. 
    
24. Uncontrolled scope creep – This one is a classic, but it is a true and common problem. There is often a tendency of the requesters of projects – the customers, or possibly more often, the users of the product being developed – to realize during development that there are other features that should be added. The features might be absolute necessities, or they might be nice to have. But allowing more features to be added almost always expands the work, the schedule, and the cost. 
    
25. Not informing management promptly when help is needed – If the project runs into problems that will definitely or potentially put it behind schedule and over budget by a significant amount, or at risk of not meeting the goals, then the PM must bring the matter to management attention. This is especially true, if the PM does not quickly identify a solution that can bring the project back “on track”, because then escalation and requests for help may be required, depending on exact circumstances. Failure to inform management (or the PMO if it is a point of control) that there is a problem is a serious mistake. Senior management needs to know when any important project is in trouble. 
    
26. Lack of management response when help is requested – Just as serious, is the case where a project manager informs management that a project is in trouble and nothing is done. At the very least, there should be a meeting (or review) to determine 1) if the PM has correctly explored the options, and 2) whether any other solutions are possible from a higher, cross-project perspective. Of course, there are situations where the project in trouble is the lowest priority, or the factors involved are outside of the organization’s immediate control. But in any case, the PM should be given advice on how to proceed. 
    
27. No monitoring (project reviews) and control outside of team – Monitoring and control means checking whether the project is staying reasonably “on plan”, and taking steps to adjust if necessary. It should be done at two levels: by the project manager and team, and by someone with appropriate authority outside of the team – usually executive management or a PMO (if one exists). Large complex projects should typically have formal outside reviews scheduled at certain key points in the project timeline.  

The full list of 27 barriers to success outlines a number of things that can negatively impact projects, resulting in schedule and budget overruns and potentially not achieving the expected or desired business value. So, studying these barriers to success may help you avoid the potential problems. Again, not all of the identified problems are controllable by the project manager, but the large majority of them are. The project manager must step up to the challenge.

Raymond Posch is publisher of Weekly PM Insights newsletter as well as being a full time project manager. See Ray's bio on our Meet the Experts page. He can be reached at ray@projectsuccesstips.com.

How good is your PMO?
By Elizabeth Harrin

A new study has shown that nearly half of Project, Programme and Portfolio Management Offices (PMOs) rate themselves as Fair or Poor in terms of effectiveness. I think that’s terrible, especially as it was the PMO team or those close to them who responded to the survey. As the purpose of having a PMO is to make an organisation more effective there can’t be much job satisfaction for those people.

The study identifies the main objective of a PMO as:

to provide a group dedicated to supporting and integrating operations across organizational boundaries. This is accomplished by providing services that either mitigate or directly address the root cause of the challenges being faced.

The main challenge identified in the study is the perennial problem of departmental silos. This is less of an issue if your PMO just serves one department (and only 26% of them claim to be enterprise-wide). However, say your PMO is one of the 36% just supporting IT. How many projects does IT do that only impact IT? The PMO will still need to work with internal customers to gather data for reports and dashboards – reporting and dashboards being one of the biggest things that PMOs do.

Churning out good reports is not one of the things that makes a PMO effective. The factors highlighted in the research that correlated with being an effective PMO were:

• Having a high level of process maturity.
• Reporting to C-level executives, with teams reporting to the CEO being the most effective.
• Having between four and six dedicated staff, although further analysis shows that more staff equals more effectiveness. The researchers don’t correlate this with staff numbers though. The highly effective PMOs from the study have over 15 staff but if their organisation is only made up of 20 people you would not be able to say this was an effective team in business terms.
• Being around a long time. The most effective PMOs have been in existence over four years, and the survey participants said that the PMO started to be properly effective after three years. That’s a long time to wait for business benefit. I don’t think that they meant that for the first two years the PMO team are pointless, but it does take a while to bed in the new way of working that a PMO brings.

It’s difficult to influence many of these. If you are a project manager working for a PMO you won’t be able to change your line management structure. If you report into a business unit VP you are doomed to be an ineffective team forever more. You can’t change how long the PMO has existed, you just have to sit it out until three years have passed and people can no longer imagine how they ever got by without you. Having said that, there are some things you can do in the meantime to bump up your effectiveness levels.

Terry Doerscher, Chief Process Architect for Planview who commissioned the study, has the following recommendations:

1. Benchmark your PMO: compare it to others in your sector. This is a huge task if you want to do it properly and assess the maturity levels of business processes and work out where the biggest operational challenges are.
2. Assess the performance of your PMO: again, a big undertaking as it means working out where processes are performing poorly and putting that right.
3. Make sure everyone knows what the PMO is: Doerscher recommends ensuring that the PMO has objectives and that its role within the organisation is clearly defined – and communicated.
4. Ensure the PMO can meet those objectives: you need a large enough team to be able to deliver everything you set out to achieve.
5. Get your PMO executive sponsorship: you can do this even without changing reporting lines, if you can find an exec who believes in the PMO concept. If you do a great job for him or her they will spread the word among their colleagues. Guerrilla PMO!
6. And finally, don’t get bogged down in day-to-day admin. Instead spend time doing fabulous work on business strategy.

Unfortunately, these kinds of initiatives are likely the be among the first to suffer in the current economic climate. I think PMOs do add value, but these recommendations all appear to be navel gazing in a time where more focus is on delivering results with less than on benchmarking support functions. I’m not saying that you shouldn’t do this, but not everyone thinks like me and this year I think PMO-improvement projects are going to be a casualty of the credit crunch.

Nice study, shame about the operational realities, but if you can fit in supporting the development of your PMO around delivering what the business is shouting for, then all credit to you.

Elizabeth Harrin, BA, MA, MBCS, is the author of the book "Project Management in the Real World", writes the irreverent blog A Girl's Guide to Project Management, and is a columnist for pmtips.net. (This article was previously published on her blog.) See Elizabeth's complete bio on the Meet the Experts page.

January 17, 2010

These days, it has become critical that every project that consumes any significant amount of resources must 1) be fully aligned with business strategy and goals, and 2) must deliver the desired business results. I will write more on this later - but for now, this should be near the top of your list of project management success principles.

Align with the Business

January 24, 2010

Greetings {firstname}!

Sometimes projects go wrong from the start, and the best course of action is to promptly stop the project, figure out what went wrong, and restart... It happened to me.

Don't Just Manage, Lead