Category: Operations

The following is a guest post by Susan Shearouse, author of Conflict 101.

Early morning, the mists rising off the placid river, the crew racing in that long sleek boat, each team member pulling through the strokes in unison, the team leader sitting at the back calling commands. Ahhh, teamwork…

What happens when the reality of teamwork doesn’t match the vision? The meeting is a little tense, there are several ideas about the best way to proceed. One person starts to speak, another cuts in. A head tilts, a jaw tightens, the voices get just a little bit louder, and everyone in the room stiffens. Fear vibrates through the room – fear that an argument is about to take over, fear that conflict will derail the team and the project once again. Some want to get out of the meeting as quickly as possible, others want to pile on, jump into the disagreement on one side or the other.

What is a project manager to do?

(1) Slow down. Take a break. Allow yourself time to think through a way to proceed. Disagreements are healthy and useful to the team. Better ideas can be created when people can share concerns, ideas and creative solutions. Everyone on the team benefits from feeling that their views are heard and valued.

(2) Take a solution-seeking approach. When and where can we meet? We need a place that is neutral and conducive to hearing one another and enough time for people to air their views. What additional information might team members need? How can we get it to them?

(3) Create a safe place for people to talk. Establish guidelines for the exchange of ideas: stay focused on issues not individuals, listen, respect differences, monitor your airtime, let one person talk at a time…

(4) Be curious. What do others think? And why? Ask questions and wait for their responses. Check that you have understood what they have said – without disagreeing.

(5) Listen. Demonstrate your willingness to hear different points of view without jumping in. Ssshhh – keeping quiet encourages others to talk.

(6) Define the problem. In neutral terms, based on everyone’s views and concerns, develop a common understanding of the problem or question at hand.

(7) Explore options. Create a list at least five to seven possibilities before evaluating any of them. This will help diffuse either/or thinking.

—————————

For more resources, see the Library topic Project Management.

—————————

SUSAN H. SHEAROUSE is the author of Conflict 101: A Manager’s Guide to Resolving Problems So Everyone Can Get Back to Work (AMACOM 2011). She has served as Executive Director of the National Conference on Peacemaking and Conflict Resolution and on the Advisory Board of the Institute for Conflict Analysis and Resolution at George Mason University. Her clients have included Lockheed Martin, Philip Morris, the IRS, the US Environmental Protection Agency, the US Army Corps of Engineers, and many others. Find out more about Susan Shearouse and Conflict 101 here: http://www.amacombooks.org/book.cfm?isbn=9780814417119.

In this blog we talk mostly about project managers and how they can steer the project towards success: how they can start with a strong business justification, do robust planning, enact good change control. But there is another player in the project’s cast of characters who is just as important, if not more, than the project manager. It is the Project Sponsor.

Ultimately, it is in the Project Sponsor’s best interest that the project or initiative be successfully deployed. The Sponsor has, in all likelihood, made a commitment to their own management, to their corporate board, or to an important client. They may even have financial rewards awaiting them, once the initiative has been deployed successfully. So as project managers, we should not feel guilty about involving our Project Sponsors and, in essence, giving them a few items to perform in support of the project’s success. Let’s consider a couple of examples.

Oftentimes, at the beginning of a project, I ask the client for their “Project Charter”. Those of you who have studied the PMBOK® may remember that this is the formal document that authorizes not just the existence of a project, but also authorizes the project manager to start assigning resources to project tasks. Already at the outset we can ask the Project Sponsor to document for us the high-level scope of the project; the resources envisioned; the duration; and the background business case that makes this project a necessity.

Once the project scope has been agreed and assigned, change will probably take place. As part of our Change Management procedures, we should agree with the team that certain levels of change (extra funds, excessive delays, technical approaches) will require the approval of the Project Sponsor. Even if I have been given his authority as Project Manager, I seek the Project Sponsor’s agreement. This achieves two things: (1) The Sponsor could point out different perspectives the project team may not have considered as they address the change and (2) If we have made the Sponsor part of the problem-solving team, he or she is less likely to be unhappy with the outcome. So go ahead and leverage the fact that, in the end, our Sponsor should be the boss.

—————————

For more resources, see the Library topic Project Management.

—————————

As a general rule, project teams will agree with the idea that Risk Analysis makes for a better project. It gives the team visibility of worrisome items, a forum to prioritize them, and some time to react before the risk materializes. So why don’t more project managers incorporate Risk Analysis regularly in their project’s governance?

Oftentimes, the response I hear is ‘lack of time’. A colleague said to me recently: “We already have such limited time to meet as a team, that when we do come together, we have to stay with tactical moves”. Certainly a valid point. But we can streamline as much as possible the Risk Analysis exercise, and incorporate it at the end of a regular Status Meeting once every few weeks (how many weeks will vary — different projects have different risk content). Once done, Risk Analysis might avert problems that would have caused many hours of these “tactical moves” to resolve later.

Here’s how the exercise goes:

• If Risk Analysis has never been done, bring a list of “Risk Categories” to the team meeting (such as organization, technology, infrastructure, subcontractors, logistics, client finances, etc). Of course, categories can be added once at the meeting. And if a Risk Log already exists, bring that to start the discussion.

• Ask the team members: “What are your worries?” regarding these categories. Worries are equivalent to risks. This is your initial list of Risk Events.

• Vote on this list of Risk Events, both in terms of likelihood of each one happening and impact, if the event were to happen. The quickest scale I have found is assigning values of ‘low’, ‘medium’ or ‘high’. So each Risk Event ends up with two scores: one for likelihood, one for impact.

• Write down in a Risk Log only the events that were considered ‘High’ in likelihood and ‘High’ in impact. As a team, decide what would be the best response from the project: a mitigation? a way to avoid it?

• Finally, like action items, each one of these risks is assigned a person in the team to monitor it. So if the risk looks about to happen, this person can alert others and the agreed response would be put in place.

Again, a few weeks later (four? six? eight?), depending on whether the project environment is more stable or more uncertain, we can repeat the exercise at the end of a regularly scheduled Status Meeting.

So go take care of that “Risky Business” in your project and, in the process, look more professional to your Executive sponsor.

—————————

For more resources, see the Library topic Project Management.

—————————

A guest post from Kevin Lonergan, coach at PMIS Consulting Limited.

It is often said in firms that “we simply don’t have a project management culture”. This can be true but a) what doe it mean and assuming it is true, b) what can be done about it?

So, what is Organisational culture?

Organisational culture definitely exists. There is much written on organisational culture – just Google it and you’ll find loads of detail but in essence this is what it means.

All organisations that have existed for at least some time will have developed a “culture”. In its most simplest, it is the values and habits that are promoted by the organisation is being important, or even crucial to the business. This could be and often is extended to the behaviours that individuals and even teams’ exhibit in discharging normal business – and this can and will include projects. It will also extend to what (does and does not) get noticed by seniors in a business. A great form of this is the examples of behaviours or practice that are “promoted” (say in a corporate magazine) as being or value to the business – often though this focuses more on results than process, sometimes with the two becoming very confused.

To determine your own culture it is quite easy to write or find a list of terms that describe typical cultures, and use that to ask a cross section of people from a single business to assess which of those terms most closely describe their firm – it usually works very well to highlight the sort of things like behaviours that are highlighted as being desirable – including that which is sometimes be referred to as the “hero factor”.

So how does this relate to project management? Well, many firms will have developed at least a framework to describe how projects should be defined, planned, managed and closed-out. Often, these frameworks will follow or replicate practices that are generally considered to be valuable or even fundamental to project (delivery) success. However, despite this, when real projects come along the actual practice on the ground is often light years away from the written framework or procedures. Often, this could even have been driven directly from somewhere at the top in the business. That is usually the point when two or more people are having a coffee chat and one will say ”…… yes, but it’s just not in our culture….. etc etc”.

In practical terms, this can often mean that staff within the business will not necessarily follow (even in principle) what someone in the organisation believes is strategically important to planning and delivering successful projects. Others in the business may feel that managing projects is little more than running or chairing meetings, and that “Project Management” adds little value. Sadly, in their business they may well be right.

So, if this is the case, what can we do? I will address this in my next post and in the meantime, please feel free to add your comments and suggestions.

—————————

For more resources, see the Library topic Project Management.

—————————

There will be milestones in our projects –or initiatives- that are important because they determine what the project team does next. Maybe it’s a ‘Scope Definition’; maybe it’s a ‘Design Review’. When these important decisions surface, sometimes project teams tend to swell – even though you, the Project Manager, have not asked for more resources. There may be uninvited guests at your meetings. You may see emails from people you don’t really know. I remember a particular project briefing, where the conference call provider actually advised that “the maximum number of lines has been reached”. Who were all these people? These situations can be addressed with the adage “less is more”.

As Project Managers, we are moderators of the information exchanges in our projects. If we have a workshop with N amount of participants, we will have to moderate a total of (N) X (N-1)/2 information exchanges. This means that, in a meeting with 6 participants, there are (6 X 5)/2, or 15, possible communication channels to moderate. In a meeting among 8 people, we will have (8 X 7)/2, or 28, possible communication streams. You can see how, very quickly, meaningful exchanges that yield a final solution become harder to moderate. The PM has to focus mostly on ‘crowd control’, and consensus may not be reached.

So if an important decision is required, a small but very skilled committee is a better option than a cast of thousands. Hopefully these few project team members can even be empowered to commit their organizations on, say, deadlines or funding. But even if they need to consult someone before doing so, at least they can manage their own communication streams in order to give you a decision. Of course, we must be very grateful and diplomatic as we say ‘no’ to those who have invited themselves. But at the end of the day, a small yet skilled team will yield a better decision than a large, rambling gathering. Less is more.

—————————

For more resources, see the Library topic Project Management.

—————————

Your next project involves implementations here as well as in other countries. Are congratulations in order? Or are condolences more appropriate?

No doubt installations in other geographies come with their own inherent set of challenges. Currency fluctuations; centralized versus local procurement; languages; time zones. And those are even before considering difficulties due to the particular technology being deployed, or the source of spare parts, or infrastructure in the country.

This discussion aims to introduce a technique which can help you increase the acceptance of your initiative in other geographies, as well as resolve any disagreements quickly and with much improved team spirit.

No, it is not the traditional Project Management methodology: I will not start extolling here the virtues of the “Project Charter”. The magic ingredient in international projects, as I have discovered throughout 18 years of successfully deploying such, is treating our colleagues from other countries in a manner which puts them at ease.

Notice that this recommendation goes well past the tired old adage: “Treat those from other countries with sensitivity”. That much is obvious, and we would certainly try to conduct ourselves thus. The recommendation is to approach colleagues from another geography with a demeanor they would find in their own country. In other words, if you are dealing with Brazilians, try to ‘act Brazilian’ as you collaborate with them; if you are working with a Finn, try to ‘act Finnish’.

So how do we develop a good picture of what ‘acting Australian’ or ‘acting Japanese’ might entail? Fortunately, there’s excellent research on intercultural cooperation we can consult. Fons Trompenaars’ Riding the Waves of Culture, or Nancy Adler’s International Dimensions of Organizational Behavior are some of the best books on the intercultural topic.

My personal favourite in the “intercultural” arena, as relevant today as when its first edition was published in the UK in 1991, is Cultures and Organizations: Software of the Mind by Dr. Geert Hofstede.

The ground-breaking contribution of Dr. Hofstede’s research is that, through thousands of surveys of IBM professionals in dozens of countries, he is able to arrive at a numerical value for certain elements or “dimensions” which make up Culture. So for example, we learn that Malaysia, on average, has the highest score (104) for “Power Distance”, meaning that as a group they are quite comfortable accepting power inequalities in society. At the other extreme, Great Britain and Canada have low scores (35 and 39 respectively), which translate into a “limited dependence of subordinates on their bosses”. In other words, British and Canadian employees (as a group) are not afraid to approach their bosses or disagree with them.

Another useful observation centers around the topic of “collectivistic” cultures (where the interest of the group prevails over the interest of the individual) compared to “individualistic” cultures (in which the interests of the individual prevail). It comes as no surprise that the country with the highest individualism score is the USA (91), closely followed by Australia (90). At the other extreme, the countries with the lowest individualism scores are Ecuador (8) and Guatemala (6).

Personally, I have leveraged his findings to arrive at the following communication paradigms, in order to make my counterparts in other geographies more at ease as we negotiate and coordinate project milestones. It has proven a huge advantage, as the largest difficulties in technology projects are not about the technology. They are about people.

With colleagues from Latin America (Venezuela, Panama, Mexico, Brazil, Colombia) and certain Asian countries (Pakistan, Thailand, Malaysia, Indonesia) with large acceptance of power,

• Stress clear definitions: what constitutes in-scope vs. out-of-scope
• Stress the benefit to the whole project/company
• Stress checkpoints for scope verification
• Lively exchange, having fun, yet sticking to the rules

With collegaues from Northern/Western Europe/Australia/New Zealand, which exhibit large individualism,

• Have all the facts, be decisive
• Recognize the contribution of these colleagues
• Relaxed approach, not stressing hierarchy
• Sell/negotiate work deliverables
• Stress value of the project to their particular unit

How would you know a country’s “Individualism (IDV)” or “Power Distance” (PDI) scores? The best source would be Dr. Hofstede’s book. Alternatively, ITIM International has kindly published the scores in the website http://www.geert-hofstede.com/

I hope you find these recommendations useful and that they make you very successful in your next international project.

—————————

For more resources, see the Library topic Project Management.

—————————

there was a debate for years around whether Project Management is an art or a science.

The truth is that neither are correct on their own – it is both.

Successful project managers (with a track record of more than one project) typically employ the science stuff (core PM concepts), sometimes religiously.

They also harbor a good deal of the “art” side as well. One example of the art would be the harder to define competencies or even what some people call personal qualities that good PMs have, for example judgement. You cannot be a successful project manager (of anything non-trivial) without very good judgement.

Something that is (sadly) not found in all of us.

—————————

For more resources, see the Library topic Project Management.

—————————

I wrote recently about the difference between senior and junior project managers in terms of decision making. More specifically, I argued that while senior managers focused on potential project difficulties, junior managers were more easily swayed by their project’s plan and its deficiencies.

Spotting problem with your plan and being able to foresee difficulties are both essential skills for a project manager, but I would argue that while the first one can be acquired by anyone willing to put in the needed effort, the second skill is much harder to develop. This is why I believe in the importance of managing a project in a field you master.

Everyone does not share this view. Some people indeed hold the opinion that project management is a “standalone” skill: once you master the mechanics, you can apply it to any context. In the same vein, it could be argued that even a project manager with a lot of experience in a given field cannot possibly hope to master every single aspect of the project he will be working on. Why bother at all with choosing someone with field experience, then? This perception of project management does have its appeal, but it forgoes some of the most compelling advantages offered by choosing a project manager well versed in a given field.

The first one is obvious: when you know what you’re working with, you also know who to turn to when in need. Good data is essential when the time to take a decision comes, and that data can only be obtained by asking the right questions to the right members. Field knowledge is definitely a big plus in this case.

There’s also the fact that without mastering every skill, a project manager with knowledge of a given field still usually has a good idea of what every member of his team does. This is invaluable when evaluating the impact of a decision. Unforeseen consequences can be very damageable to a project’s progress; the more you know about your field, the more you can plan ahead.

Finally, a lack of project management skills is simply easier to remedy than a lack of field knowledge. Between coursework, mentoring and following commonly accepted best practices, the options are numerous and accessible to anyone willing to learn.

Combining field knowledge with project management skills invariably leads to making better decisions. Which is ultimately what being a good project manager is all about.

—————————

For more resources, see the Library topic Project Management.

—————————

I hate project audits.

My days are already full with planning, controlling, communicating, managing stakeholder expectations and making the right decisions. In my mind, a good project manager pretty much audits his project every day! That’s how I know what is going on:

Is my project delivering the expected result at this point in time? I must always be knowledgeable about the state of my project. My audits target the evaluation of the project’s health (cost, time, scope, risks) and I do them minimally at every milestone occurrences with the different project stakeholders.

Am I satisfied that everything is done to mitigate risks on future project expectations? Risks are part of a project. There may be risk associated with any expected results. Do I have a strategy to mitigate them? I need to be able to answer this question.

So, why should I care about project audits?

Project risk management is a vast topic. Many strategies and techniques exist to make sure you identify, measure and mitigate project risks. But what about project process risks? A best practice is a technique believed to be more effective at delivering a particular outcome when applied to a particular condition or circumstance. The Project Management Institute (PMI) proposes to use “best practices” as a mean to correct any deficiencies to reduce cost of quality and an increase in sponsor and customer acceptance of the project’s product. Project audits are used to answer two questions:

Are project management best practices being followed to mitigate risks? We can surmise that a project manager who uses best practices should have a higher degree of success than someone who doesn’t.

Are there any lessons learned from my project experience? Project management is an evolving science. My organization may benefit from my good or bad decisions.

I love project audits.

It’s easy to write a bunch of guidelines on a piece of paper. But how do I use them so I feel it is improving my chance of success? Since best practices are implemented to reduce process induced risks, I should audit my practices to ensure the process will impact positively on my project results.

Best practice auditing targets issues related to the project organization and management. I put forward that best practice auditing should occur as often as possible.

—————————

For more resources, see the Library topic Project Management.

—————————

Well here’s my view. If project management (or delivering projects successfully, on a more often than not basis) were purely common sense, then the evidence to do with project delivery performance would tell a completely different story. For example, a UK report by the Royal Society of Engineering a few years ago quoted some frightening numbers on the cost overruns (in £) that is wasted each year in the UK on IT projects alone. There are many other examples from other industries to back this up this assertion.

It is an interesting thought as well that in many fields of business (engaged in projects) there are often professionals in abundance (i.e. degree or better qualified staff) working on those projects, and often they still produce disappointing results, i.e. unsuccessful, sometimes spectacularly so. You would suppose that this group could master what some say is just “common sense”, if this is true?

The reasons for poor project delivery can sometimes be complex, including:

– lack of real pressure (in some industries) for improved delivery performance
– lack of corporate capability relating to business level Governance of key projects
– lack of accountability of key individuals across the project for delivery performance
– issues of communication, poorly applied practices etc

The list could go on and on, and does depending partly on Geography and industry sector.

The best examples of project management practice are: a) relevant to the industry, technology (or domain) being managed, b) focused on the issues that are key to the sponsor or business; and c) are routinely employed by project teams as key disciplines which they get obvious value from; they do not consign them to the “we haven’t had time to do that yet” pile. In other words key professionals understand the relationship and difference between core project work and project management. In the history of the industrial era to date, evidence does not seem to support that this “common sense” prevails yet in buckets in most people in most organisations?

—————————

For more resources, see the Library topic Project Management.

—————————