Category: Project Management

Recently, an acquaintance who owns his own business installing industrial valves, remarked how difficult he thought the field of Project Management had become. “Why is there so much paper?” and “Why do the concepts have to be so hard?” (He does have a point, what with Earned Value Analysis…) He indicated that if it weren’t for these hard terms and all the trappings, he would take the time to learn a few concepts and run his projects better. So here goes a simplified version of Project Management, without ‘all the trappings’:

IN THE BEGINNING
Although our first impulse may be to start planning right away when to do what, don’t. Step back for a moment. Get an understanding from the person sponsoring and paying for the project about what they hope to accomplish. What’s the purpose? What’s the motivation for it? Why now? Hopefully there will be strong answers to this kind of analysis. A very few times in my career, after analyzing the business case, I have seen that the assumptions require an astounding amount of good luck. I have told the client so, at which time he has chosen to save his money.

THE TRIPLE CONSTRAINT
But hopefully the justification or business case does indeed pass muster. What then? You may have heard of the ‘triple constraint’ as applied to projects: it means reconciling a reasonable amount of scope, with a reasonable timeframe, for a reasonable cost. It is iterative, and we usually have to do a couple of laps discussing all three topics, until we have an agreed triple constraint. Who should be in this Scope-Time-Cost agreement? Ideally the project sponsor, the project performers, and those who will use the result of the project (a.k.a. users). Don’t forget to write it down and circulate it to these audiences. And any time the project starts diverging from the original agreement, discuss and agree a new triple constraint. Of course, there is other planning we could do in important areas, such as risk and communication. But today we are doing the pared down version, remember?

PROGRESS, PROGRESS
If a balanced triple constraint has been reached, we can start implementing the project. But we can’t just hope that, with a fair wind, the work will materialize in the timeframe we had hoped for. We have to actively track it. Yes, I know we are expending hours every week, but are we actually achieving what we agreed, when we agreed? If we are not, renegotiate once again a new triple constraint. And hopefully this one will not require as much fair wind.

—————————

For more resources, see the Library topic Project Management.

—————————

When I started my working life, at IBM, years went by before I had any sub-contractors as part of my project team. We could handle just about every request with in-house skills. Alas, almost 20 years later those days are gone, and the opposite has become the norm. It is nigh on impossible to deploy a project without the active participation of sub-contractors, often in key roles. Companies now concentrate on having staff with core skills that will be fully utilized. So for additional projects, or talents, we must routinely turn to sub-contractors.

The current societal change of “collaboration”, facilitated by internet technologies, has also contributed to the rise of sub-contracting. Through various sites we can quickly connect with people who have unique skills, be it for a quick consultation or for a 6-month engagement. This trend of quicker access to specialized skills is good news for our projects. In a business book I read not too long ago, the author speculated that very soon companies will need line managers to actively manage entire departments of sub-contractors, not just manage their full-time employees.

So given that sub-contracting is here to stay for the foreseeable future, what can Project Managers do to make these team members as effective as possible? Here are a few suggestions:

Project Quick Reference Sheet
A one-page summary of key information is helpful. Sub-contractors will probably have different systems for, say, time-keeping or travel expense reporting, so I try to have a list of Frequently Used Sites ready for their first day on the project. A few names of technical and administrative personnel, should the Project Manager not be available, will also help them feel welcome and quickly become productive.

“KPIs” or Metrics
It is vital to get across to our subcontractors why they are needed. What expectations does the project have for them? And not just specific achievements. If possible, we should share and agree with them the rate at which these achievements should take place, even if it is just a range (eg, ‘install three routers per day’). If there is an issue with this rate of achievement, the sooner you know the better.

Progress Monitoring
Often I come across project teams that have done a good job of agreeing metrics…. and then do not follow-up to see if they are materializing. They hope for the best outcome, or trust that because team members are specialists in their field, they will not need supervision. Even if we are managing PhDs in Nuclear Physics whom we can barely understand, we should review progress periodically. A simple checkpoint like, “30% of our time duration has elapsed… would you say you are 30% done with your tasks?” will uncover valuable project information. Then, hope the answer is not too technical, and you actually understand it.

—————————

For more resources, see the Library topic Project Management.

—————————

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.

—————————