Showing posts with label Best Practices. Show all posts
Showing posts with label Best Practices. Show all posts

Saturday, September 29, 2012

Conflict Resolution - Is There An App For That?


Conflict is a common and natural event in any project environment.  Conflict can even be healthy to a certain degree, if it is the result of creativity and a diversity of views, but soon becomes unhealthy if left unresolved to fester and breed animosity and distrust between project team members.



Conflict can occur between all project stakeholders and during all project phases.  Sources of conflict typically vary during the project life cycle but can be caused, for example, by disputes and disagreements over priorities, processes, schedules, roles, budgets, resources - to name just a few.




Of course, the best way to resolve conflict is to prevent it from occurring in the first place. 

Two good approaches for preventing or reducing conflict are:
Focus On Goals (Not Particular Solutions).
By making project goals the focus, conflicts can often be easily resolved or avoided by asking a simple question: Which solution is going to get us to meet our project goals more quickly and effectively?  Quite often conflicts tend to arise over trying to implement a particular "pet solution", but when examined in the light of what is most expedient and practical to meet the project goals, the pet solution may be deemed less practical and the resolution becomes very clear.

Foster Trust And Teamwork On Your Project
To do this, the project manager needs to lead by example:
-  Listen to and trust your team.
-  Be open to all ideas and suggestions.
-  Foster a fun and collaborative work environment for your project teams (and yourself).
-  Praise and encourage more, criticize less. 
-  Collaborate with your project team to develop a Team Operating Agreement, to include their  suggestions for team values and team operating principles - and adhere to it.


To resolve any conflicts that do occur, the following are some approaches you should consider:

Mediate
This is the approach most often chosen by project managers, who feel they have no recourse but to jump in and make a judgement call to resolve the conflict, but it is my least recommended approach.  If the project manager happens to be not only the mediator, but also one of the parties involved in the conflict, then you can see how this might not be a satisfactory approach.  Even if the project manager is not one of the parties in the dispute, the "losing" party will inevitably feel that the project manager has unjustly favored the other party, and resentment (hidden or otherwise) will accrue. 
Depending on the type of conflict, external groups such as HR or external mediators and facilitators can be helpful in mediating and resolving some conflicts.

Delegate
A project manager can never delegate too much, and delegation is particularly beneficial if one of the parties in the dispute owns the responsibility for the task or solution under dispute.  In this case, the owner of the task or solution should be given the authority to proceed with his/her recommended approach. 

Ignore
Ignoring a conflict is a good approach if both the conflict and consequences are minor, or not directly related to the project.  In this situation, the project manager getting involved could only make the conflict bigger.   However, ignoring a serious conflict will also be more difficult to solve as positions get entrenched over time and project delays and impacts increase.  

Toss A Coin
Don't laugh.  Here's a true story:
Many years ago, I was Director of one of the two large Data Centers for my company in Toronto.  The company had an identical Data Center building in Montreal, but over the years differing computing facilities and operating procedures had been implemented.  My counterpart for the Montreal Data Center and I made the strategic decision that we would move towards achieving equivalent computing facilities and operating procedures, so that in the event of a disaster, one Data Center could serve as the backup for the other. 

Every now and then we would be approached by one of our managers, indicating that they wanted to use a particular solution or software tool, but that the other Data Center wanted to use something else, and they of course assumed we would side with them and try and convince the other Data Center to use our solution.  So the other Director and I agreed that when this situation arose we would "toss a coin" to pick the solution. The main point, of course, was that the particular solution was less important than the goal, and since both solutions would work, pick one and let's move on.

Well we only had to do this once, and were never approached again.  The managers realized that they could toss the coin themselves, or better still, make their case to each other, give and take appropriately and resolve it amicably.  A few years later, when we did have a major fire in one Data Center and had to recover our applications in the other, having a good working relationship and identical operating procedures was "priceless".


Is There An App For That?
Of course!  Tossing a coin is so last century.  And what do you do when you are confronted with three or more choices, all of which can work?  Just push the green button (or spin the wheel) and let the magic of technology decide.  Your managers will be impressed (or not), and will be less likely to come to you to make these decisions, when they can make the decisions themselves, using the same technology (or not).

There are a variety of "Decision Maker" apps that you can customize for yourself, but I used the Decide Now! app, available for the iPhone, iPad or iPod touch (sometimes free, but currently $0.99).




What techniques have you used to resolve conflicts on your project?


Sunday, August 12, 2012

How Late Can Your Project Be Before You Push The Panic Button?



In my previous post, I discussed this formula for success:

Success = Motivation + Knowledge + Commitment + Perseverance * Action.

Let's assume we are strongly motivated to bring in our project within budget and on schedule. The easiest way to achieve both goals is to just focus on bringing the project in on schedule.  If we can do that, then we will also come in within budget.

Make the commitment with your project team that your project is going to finish on schedule and then take the actions that will facilitate achieving that goal.

This raises a question - how late can a project be before you need to push the "panic button" and take dramatic and remedial action?  Let's say your project is one year in duration, and after the first month the project is a few days behind schedule.  Surely you can catch up.

As we know from experience, work on projects (like climbing mountains) never gets easier with time, only harder.  If you are a few days behind early in the project, then you are going to be weeks or even months late by the end of the project.

So my answer to the question is that your project should be "Not A Day Late".  As the sun sets each day, your project should be on schedule.

How can we possibly achieve this?  Here's one way.

Set the goal with your project team that every activity on the critical path of your project has to come in on schedule and if they find that they are going to miss a target, they need to notify you as early as possible, but no later than 3 pm of the day that the activity will be late.

At that point, this is what I recommend you do.  Immediately call an emergency meeting of the whole team and work out an action plan using all the resources and experience of your team to get that activity back on schedule by the end of the next day.

This may sound dramatic, and it is, but you will only need to do this two or three times, before the objective and importance of coming in on schedule will be very clear to your team and you will find the occurrence of missed targets becomes few and far between.   No-one wants to stay behind, whether for their late activity or for others, so you will find more attention is paid to anticipating issues and addressing them earlier, before they cause activities to be late.

Try this approach out on your project, and let us know how well it worked towards bringing the project in on schedule.

==
If you are interested in learning some good project management best practices and techniques for keeping your project on schedule and within budget, sign up for our recorded APM03 webinar "How To Keep Your Project On Schedule And Within Budget" at www.alphapm.com/webinars.  Our next AlphaPM Project Management Webinar Program starts Tuesday September 4, so this webinar will also be available live at 12 noon EST on Tuesday September 18, 2012.

Sunday, August 5, 2012

The Formula For Success Is Really Easy - Except For That Pesky Little Bit At The End



The formula for success is indeed really easy - at least easy to understand and remember:

          Success = Motivation + Knowledge + Commitment + Perseverance * Action.

Let's apply this formula in the context of the goal of getting our project in on schedule and within budget.

Motivation
In my previous post, I discussed how success starts with motivation.  The probability of success is directly proportional to how badly we need or want to achieve a goal.  We must strongly want to bring in our project on schedule and be confident that we can and will achieve that goal.

Knowledge
The next ingredient in the formula is Knowledge.  What does it take to achieve the goal?  In our project environment, we usually know the processes and best practices that should be followed (e.g. Change Management, Risk Management, Quality Management etc.), even if we don't always follow them, so knowledge is not usually the factor that limits our success.

Commitment
We now need to make a commitment with our team, that we will work together to achieve that goal.  Achieving the goal should be seen as a team responsibility and success will be a team success.

Perseverance * Action
Now this is the hard part - actually taking the actions necessary and persevering with or modifying those actions until the goal is achieved.

Here's an example of how difficult this is.  Many of us decide at the beginning of every year that we are going to lose weight, strongly motivated for reasons of health and/or appearance.  The knowledge of what we need to do is well known.  If we do even just one of three things (eat healthier foods, exercise more or eat less) and keep the others constant, we will lose weight.

We typically make our  commitment to lose weight through a documented New Years resolution, followed by signing up for health clubs or some daily regimen of exercise and dieting all supported by diaries and charts to track our expected progress.  But the follow up actions (persevering in actually eating less, eating healthier foods and/or exercising more) is where we tend to come apart.  It is easier to put off the actions for another day - what difference is one day going to make?

So if we are to be successful, we need to address and maximize every part of the formula, but particularly focus on persevering with the actions and project management best practices that will facilitate our success.

We usually know what these actions and best practices are, or can easily learn them.  We just have to do them.

What are some of the special things you do on your projects that help them to be successful?

If you are interested in learning about the project management best practices and techniques that will help you keep your project on track, sign up for our recorded webinar APM03  "How To Keep Your Project On Schedule And Within Budget" at www.alphapm.com/webinars.  Our next AlphaPM Project Management Webinar Program starts Tuesday September 4, so this webinar will also be available live at 12 noon EST on Tuesday September 18, 2012.

Sunday, July 22, 2012

Never Underestimate The Power Of A Project Dashboard




In 2003, the Virginia Department of Transportation (VDOT) introduced a web based Dashboard for their construction projects. 

This Dashboard became a powerful tool for VDOT Executive and Project Managers, showing instantly whether projects were on track, falling behind schedule or going over budget.



The Dashboard was soon made public, and citizens were invited to view the Dashboard online and share their comments.  The performance improvement achieved by all VDOT projects was dramatic.

Prior to the introduction of the Dashboard in 2003, less than 20% of all projects were on time. By 2005, this number had improved to 75% and currently, as you can see from the VDOT Dashboard above, 97% of all projects are on time - an outstanding improvement in a very complex and challenging construction project environment.  Similar improvements were achieved in the other areas measured by the Dashboard.

As you can see from the VDOT example, a Project Dashboard can indeed be a very powerful and effective project management tool.

To be effective, a Project Dashboard should follow these following eight principles:
  • Use a standard dashboard format across all projects - in this way, the performance for all projects can be fairly and effectively compared.
    Information displayed should include the Project Schedule, Project Budget, Client Satisfaction Index, Project Resourcing Index and Project Health Check Index metrics.  A summary of the key Project Milestones and Project Risks and Issues should also be displayed.  (See the sample AlphaPM Project Dashboard tool layout above)
  • Ensure the dashboard is easy to understand - it should be easy to determine the performance of the project by using Green/Yellow/Red icons to show the performance of the project through the various key metrics.  Avoid clutter, and keep metrics and information displayed to the minimum useful set.
  • Ensure the dashboard is easy to complete - the metrics on the dashboard should be easy to measure, collect and present
  • Provide background information through a "drill down" capability - detailed information (such as the project schedule, risk register, project health check detailed results, project repository, status reports and change requests) should be linked to the dashboard, so that they can be referenced as needed. 
  • Make sure all information is timely and updated at least weekly - if it is not, it will be ignored.
  • Provide maximum visibility of the dashboard to all stakeholders - this will motivate the project team to keep on track and also ensure that the Executive and all other project stakeholders know if a project is in trouble, so that they can promptly assist in addressing problem areas. 
  • Show the project's business goals and objectives -  add a short section with a few bullets on the business goals and objectives for the project.  This helps to reinforce the importance and value of the project and keep all stakeholders focused on meeting the project's business goals. 
  • The organization must have a supportive culture
    Now here's the most challenging part of ensuring that Project Dashboards are indeed successful.  The organization culture (starting with your Executive and Client Management) must be proactive and constructive in their support of projects who show red or yellow metrics on the dashboard.

    For example, say your Executive meets you in the hallway and has noticed that your project has some red metrics on your Project Dashboard.
    Bad:  Executive says to you "Why is your project in such a mess and when are you going to have it fixed?"
    Good:  Executive says to you "I see you are having some challenges on your project.  Is there anything I or my management team can do to help you get back on track?"

    Without a supportive and collaborative executive and organization culture, project managers will resent having visible dashboards, and start to fudge metrics and cover up issues and problems, thus making them even more difficult to eventually solve.

Let us know your experiences and best practices with Project Dashboards.


Webinar:  APM13 Project Dashboards
If you are interested in learning more about Project Dashboards, and would like the AlphaPM Excel based Project Dashboard tool, sign up for our one hour APM13 "Project Dashboards" webinar at www.alphapm.com/webinars


For further information on Client Satisfaction metrics and Project Dashboards, please see these previous posts:
Client Satisfaction Surveys the Easy Way
Six Best Practices For Managing Multiple Projects

Sunday, July 1, 2012

Client Satisfaction Surveys The Easy Way

Client Satisfaction is one of the key measures of success for any project.  Yet I find, too often, that project managers do not formally check with their clients on whether they are satisfied with the progress of their project.

In a couple of organizations where I have worked, I suggested that we carry out Client Satisfaction Surveys and the idea was always well supported.  In one organization, a highly detailed and overly complex questionnaire was developed, with poor results, and in the other organization the survey was still being scientifically designed when I left over six months later.

I think Client Satisfaction Surveys are absolutely necessary for all projects, but I also think they should be very simple, for the benefit of both the client and the project manager.

Here is my recommendation for a simple survey that can be completed quickly and easily with your client sponsor, yet will provide you with a valuable gold mine of information.
 
Let me walk through the various sections of the survey:

Please provide us with your overall satisfaction with the project (check one)

Notice I have kept the satisfaction levels to an absolute minimum.  Your client is either completely satisfied, dissatisfied or somewhere in between.  Don't try and grade various levels of "in between".  It really does not matter - some things need to be fixed and that's all you need to know.   By keeping it simple, you are more likely to keep up the practice of doing the survey, you make it easier for your client sponsor to pick the right level, and you can compare satisfaction levels across projects in a more consistent way.

The levels should be associated with a dashboard indicator icon (green, red, yellow) and the appropriate icon should be shown on your Project Dashboard, with a drill down capability to the details provided in this survey.
Your PMO should aggregate all individual project survey results (using say, 1 for each red, 3 for each yellow and 5 for each green), and then show the average rating for all projects.  By tracking this average on a monthly basis, the PMO can see if they are helping all projects to improve client satisfaction.


What aspects of the project are working well?

It is always a good idea to start on a positive note.  This will help to balance the survey and give positive reinforcement to the good processes being used and good work being done by the project manager and project team.


What aspects of the project could be improved?


The client sponsor should summarize here any areas they feel need to be improved, whether processes, people or results.  Bullet points should suffice.  If the project manager needs more detail, they should discuss this in a separate session.  Again, the purpose here is to keep the process simple.


Are there any other comments you would like to add?

This space can be used by the client to add anything they wish about the project, project manager or project team.  


Some Survey "DOs" and "DON'Ts"

-  DO the survey privately and in person with your Client Sponsor (for example, after a regular status meeting or during a lunch meeting).
-  DO the survey regularly (monthly is good).
-  DO make sure that you address all items raised as needing improvement before the next survey.
-  DO make the results of the survey visible on your project dashboard to all (your project team, your management, client management).  Visibility always help to make sure problems are addressed promptly, one way or another.

-  DON'T try and respond during the survey review meeting to any problem areas being raised (unless to just request any needed background information on the problem).  Any immediate defense of noted problem areas will only raise the ire of your client and serve no useful purpose.  Better to reflect on all the items raised and come back in a separate session to show your client how you and your project team  have addressed or will address all problem areas raised in the survey.

Client Satisfaction Surveys are an extremely easy and powerful tool for building your project's success.  If you are not doing them regularly, I hope you will try one out soon.

Let us know about any Client Satisfaction Survey practices that are working well for you.

Sunday, June 24, 2012

The Yin and Yang of Project Management and Leadership

Successful project managers not only have to be good managers, but also strong leaders.

Now the dilemma here, is that the skills and attributes of strong leaders are quite different from those of good managers.

It is very important to recognize these differences and maintain an appropriate  balance between the "yin" of good project management and the "yang" of strong leadership.


Let's examine some of these differences and the challenges that a project manager will face in trying to be both a good project manager and effective leader, at the same time.

Create the Plan/Share the Vision
A project manager needs to create a plan for their project and manage to that plan.  To also exercise project leadership, the project manager needs to share a broad and bold business oriented vision for the project.  For example, your project may be to provide an e-commerce capability for your organization, and as a manager, you need to develop and implement a plan for the project.  As a leader, you must  share the project vision at every opportunity, emphasizing (for example) how the project is an important component of your organization's strategy to transform its business model, increase revenue and enable further business opportunities.  

Control Change/Embrace Change
As a Project Manager it is important to control and manage change.  However, as a leader, you recognize that change is not only inevitable, but also desirable, as it generally reflects a more appropriate or more current need from your client.  So as well as controlling change with your "project manager hat", with your "leader" hat, you need to welcome and embrace change.

Be Rational/Be Passionate
Project Managers tend to be analytical and rational, which are excellent attributes for managing projects.  However, as a leader, you need to inspire and encourage your team, be very excited and passionate about your project and its business goals and constantly share your enthusiasm for the project with your project team.  Steve Jobs was famous for his "reality distortion field" whereby he refused to accept that something was not feasible, and in the process significantly raised the bar on what Apple was able to achieve.

Avoid Risks/Take Risks
As Project Managers, it is (or should be) in your DNA to anticipate and avoid or mitigate risks that could adversely affect your project.  However, as a leader you will also have to accept that great goals are  usually also accompanied by great risks, and will need to work with your team to conquer those risks with the same level of teamwork, skill and preparation that you would use, say, to climb a very high mountain.

Focus on Processes/Focus on Goals
As Project Managers, we are also trained to apply good processes and best practices in the planning and execution of our projects.  With a focus on processes, we can get mired in technical issues and debates and sometimes lose sight of the original project goals.  We need to quickly put back on our leader hat, and re-focus on the project's business goals.  This can lead us to explore alternate solutions that can often be a better path to those business goals.   

Skills and Knowledge/Values and Attitudes
In an interesting post on 10 Leadership Lessons from the IBM Executive School on Forbes.com a few months ago, the author described how when IBM were establishing an Executive School in the mid 50's, they hired a company to research and determine the skills common to executives so that they could in turn groom and train their managers for executive management.

It was discovered that unlike lower level managers, the executives they examined did not seem to share any common skills and knowledge.  What they shared were certain values and attitudes.

Whilst the project management skills and knowledge you need are fairly common (hello PMI PMBOK® Guide), the leadership values and attitudes you hold can vary quite widely, so look around and see what works for other leaders and embrace and develop those that you feel will be most effective for you.

What are some of the values and attitudes that you feel have helped you in leading your projects?

Sunday, June 17, 2012

Six Best Practices For Managing Multiple Projects


In this struggling economy, project managers are often required to manage many projects. It is usually a challenge to manage just one project, so it is inevitable that managing multiple projects will pose even more challenges.

How many projects can a project manager manage?
Now there are so many factors that affect this determination (e.g. project size, type and complexity, resources and skills available, number of clients, location and duration of projects etc.), that it is impossible to quote any useful number.  I think it will be fair to say, however, that you can manage more than you might have believed possible, if you apply the following six best practices.


Management Support
1.  Ensure the support and trust of your management and client management.
Perhaps the most valuable of all best practices is to ensure you have the support and trust of your management, client sponsor and client management.  Their proactive support is essential for the timely resolution of many activities (e.g. scope definition, project budget, resourcing, issue resolution, project prioritization etc.).  Be open about the need for their support, and take advantage of every opportunity to gain it (for example, through your project kickoff meetings, risk reviews, regular status meetings and steering committee meetings).

Resourcing
2.  Ensure you have the appropriate level of skills and resources.
This is easier said than done, but it is essential if you are to be successful in managing your many projects. Identify up front the specific skills and resources that you need for your projects, and persevere until you get them. Look for people who are team players, adaptable and willing to work in many different capacities.

Resources should ideally be dedicated to your projects and co-located.  If you cannot get fully dedicated resources, at least make sure they are co-located on specific days each week. so that you can count on their availability and support.

Performance Reporting
3.  Establish a Project Dashboard for all your projects.


Use a simple dashboard like the one shown here, to  give clear visibility to the status of your projects.

The projects can be sorted by client, so that each client sees the status for only their projects.


A Dashboard is an extremely powerful tool for soliciting the support of your project stakeholders, so ensure that the "Comments" shown for each project reflects the actions you are taking and/or the support you need to address the "yellow" and "red" areas that need resolution.  



Time Management
4.  Ensure you and your team members practice good time management.
Establish with your project team the most effective ways you can maximize your team productivity and build these into your Team Operating Agreement and practice them.
For example:
-  Keep meetings short and focused.  Take individual issues offline rather than trying to solve them at team meetings.
-  Ask your team members to let you know early if they are going to be late on an activity, so that you can take any corrective action necessary to keep the activity from being delayed.


Delegation
5.  Delegate to the max.
When managing many projects, there is quite often a tendency for project managers to take on more work themselves, since they feel their team members are already overloaded.  Wrong approach! They should delegate all activities, so that they can free themselves to work with their team leads to address issues and provide support, as opposed to being locked away trying to do activities that can and should have been delegated.
Establish a project lead for each project, or set of projects, so that you can act as the overall program manager to ensure all projects are successfully completed.


Methodology
6.  Apply a methodology that is scalable and adaptable to your project needs.
The methodology that your organization has established may not work well with your set of projects.  It is important that you adapt and scale the key elements of the organization's methodology to fit your many projects.
For example:
-  Use the simple Project Dashboard shown above for all your projects, rather than a one page Dashboard for each project.  This Dashboard can act as your Status Report for all your projects.
-  Do a combined Risk Assessment for all your projects, rather than one for each project.

Are there any other best practices for managing multiple projects that you can recommend?


Webinar:  APM13 Project Dashboards

If you are interested in learning more about Project Dashboards, and would like an Excel based Project Dashboard tool, sign up for our one hour APM13 "Project Dashboards" webinar at www.alphapm.com/webinars
   


Sunday, June 10, 2012

Keep Your Project Healthy With A Project Health Check

A Project Health Check is a very simple and effective tool that will help you predict whether your project will be healthy (come in on time and within budget).

Just as your doctor can check your health through various tests and diagnostics, so too can you determine if your project is healthy, and likely to remain so, through a variety of checks on your project.


It is very easy to build a Project Health Check tool, using a spreadsheet.  

First, establish the key areas you would like to check on your projects, and then list the processes and best practices that should be applied in each of those areas.

For example (please note that this is not a complete list):
Business Case and Project Initiation
- The project is fully aligned with the business strategies and goals  of the company
-  Business measures of success have been identified and measurement processes established
-  A Project Charter has been produced and approved, authorizing the project.
Project Planning
-  A Scope Statement has been produced
-  A detailed Project Budget has been produced and approved to cover all phases of the project
-  A Project Contingency reserve has been allocated for the project
-  A Risk Management Plan has been produced.
Project Execution and Control
-  Personnel resources are available on time to execute project activities
-  Project Deliverables are formally reviewed and accepted by the appropriate parties
-  Project Quality is controlled through the implementation of a Quality Management Plan.
Project Team Organization
-  The Project Sponsor is fully committed and available to support the project
-  A facilitative Project Management Office supports the project
-  A Project Kickoff Meeting has been/will be held for all key stakeholders at the start of the project
Project Methodology
-  A formal, documented, scalable and adaptable Project Methodology is followed by the project  team.
-  A Project Repository/Extranet is used to maintain all project documentation
-  Lessons Learned are reviewed, documented, disseminated and acted on accordingly.  
Project Performance
-  The project is on schedule
-  The project is within budget
-  The Project Sponsor is satisfied with the project and project team performance
Project Risk Management
- A Risk Management Plan has been produced
-  A Risk Register is maintained for all significant project risks, with appropriate actions, target dates and owners for each risk.


Once you have built your Project Health Check tool, you should check it at the following key points in your project:
-  Project Initiation (quick scan to confirm that you will be implementing all the best practices listed)
-  Project Planning (formally complete the Health Check before your project is baselined, so that you can ensure all best practices are incorporated in your project).
-  Project Execution (re-visit with your PMO as a Project Audit, if your project "goes red"; i.e. more than say 10% over budget or behind schedule). 


Use a simple scoring system for measuring project compliance with each best practice in the tool:
For example:
Score 5 (Green) if you are (or will be) following the best practice
Score 3 (Yellow) if there is some improvement needed
Score 1 (Red) if that best practice is not being followed at all.

A Radar Chart (like the one shown at the beginning of this post) can be produced as a summary and posted on your Project Dashboard.  The blue line in the chart represents the average score for each area, so the health of your project can be seen at a glance.

The Project Health Check is a great tool for project managers to facilitate the success of their projects by embracing the complete spectrum of project management best practices.  As noted earlier, it can also be used by the PMO to work with project managers when their projects are in trouble, to pinpoint and improve the processes that are determined to be the root causes of their problems. In this case, a joint presentation should be presented to executive management identifying the findings from the Project Health Check and the proposed actions needed to address any problems identified.

An ounce of prevention is indeed worth a pound of cure!


Let us know about your own experiences with Project Health Checks.


Webinar:  APM09 Project Health Check Workshop
If you are interested in learning more about Project Health Checks, and would like an Excel based Project Health Check tool that checks against over fifty project management best practices for your project, sign up for our four hour APM09 "Project Health Check Workshop" at www.alphapm.com/webinars.  In addition to the Project Health Check tool, you will get practical guidance and all the tools and templates you might need for each best practice.

Sunday, June 3, 2012

Ten Best Practices For Managing Global Projects


In an increasingly global economy, projects are also becoming more global.

Your project team, sponsor and key stakeholders can be spread across many continents, time zones, organizations, languages and cultures.


But while there are challenges imposed on global projects, due to all the factors noted above, these challenges often exist at least to some degree on any project, global or not.

For example, you might well have team members several time zones away, or living in your city but recently from different cultures and with English not their native language.

So here are some practices I recommend, that are especially important on a global project, but could be applied to any project.  At the beginning of your project, go through this list and pick out and apply the best practices in each area that you feel would most benefit your project.

Communications
 I hesitate to say that any area is more important than the others, but can make an exception with this one, both because I think it is the most important, and also because the issue of communications is inter-twined with most of the other areas.  How you communicate, how often and to whom and with what media will all have a significant impact on the success of your project.

1.  At the beginning of your project, establish a Communications Management Plan.  This can be a simple one pager listing all the key stakeholders and methods and frequency of planned communications.
2.  Establish a Project Repository, using a tool such as SharePoint, to make all project deliverables, tools, templates and communications readily accessible.
3.  Subscribe to a web conferencing facility, if your company does not already have one.  These can be  relatively inexpensive, with high payback and benefit, making it easier to identify and show the person talking, and facilitate the sharing of documents and presentations.  Meetings can be recorded for those who miss a meeting, or would like to replay them to ensure they understand key points made in the meeting.
4.  Early in your project hold a Project Kickoff Meeting, outlining project objectives, roles and responsibilities, project methodology and the team operating agreement.  Give all team members a chance to present a one page slide about themselves (picture, roles, hobbies, "What is the most interesting thing you have done").  Team building and ice breaker exercises will be particularly beneficial.

Cultures
5.  Accept (and embrace) the diversity of cultures on your team, but avoid any stereotyping. The best way to address this area, is to let the people on your team in each location identify what they think is different and special about their culture, and how they would like to see the team operate.  This feedback can be incorporated into the Team Operating Agreement presented at the Project Kickoff Meeting.

Languages
6.  If English is the common language to be used on your project, as is most likely, then assess the fluency of your team members in all team locations.  A good solution, to address issues of both fluency as well as the challenges of managing remote team members, is to have one senior person fluent in English act as the "lead" for each location, with the overall responsibility of coordinating all activities assigned to people in that location.

Time Zones
7.  It will be close to impossible to find a time that is convenient for all, so do not make the mistake of picking a time that is only convenient for you, the project manager.  Better to try and find a few times where no-one has to attend before 7 am or after 7 pm their time, and rotate meeting times so that everyone "shares the pain" about equally.  Again, the use of a "lead" in each location, and the availability of the project repository and recorded meetings will alleviate some of the communications problems caused by different time zones.

Travel
8.  The Project Manager should travel at least once to each location that will be providing a significant contribution to the project, and to the extent your project budget permits, each lead should also travel to be physically present for key activities and meetings. 

Deliverables
9.  Where possible, give each location an important deliverable, capitalizing on the particular skills and capabilities of that location and team.
10. Recognize the contributions from each location as they are made, and ensure they are well publicized in newsletters, Steering Committees etc.

While managing global projects can certainly be a challenge in many respects, it can also be an opportunity to learn and benefit from the diversity of cultures and the creativity and innovation that can result from global collaboration.

What has been your experience and insights on your global projects, and are there any best practices you can add?

Sunday, May 27, 2012

Three Risk Management Best Practices That Will Save Your Project



As promised in my last post, here are three very valuable Risk Management best practices that you should  apply on your project (and you should always carry out risk management on every project, whether big or small).






1.  Remove the most likely risks from your project.

If you estimate the probability of the risk occurring is 50% (0.5) or above, treat the risk as an event, not a risk.  You are predicting that the risk is more likely to happen than not, so why not build your plan and project activities assuming it is definitely going to happen.  By removing these potential risks from your project, you are automatically avoiding many potential issues and dealing with them in a more controlled and less costly way.  Think about the effort that is needed to save the Titanic before (compared to after) it hits the iceberg.

2.  Establish a Project Contingency reserve

Add up the Expected Monetary Value (EMV) for your top five to ten risks - this amount will typically be about 10 to 15% of your project budget and should be obtained as an additional "Project Contingency reserve".  You should use your list of top risks and expected impacts as justification to your management and client for the additional budget needed to establish this project reserve.  If the total EMV for your top risks is greater than say 15%, even after you have eliminated the risks with probability of occurrence greater than 50%, than you still have too many risks and should also treat some of them as events and eliminate those from your project risks.

3.  If you cannot get approval for a Project Contingency reserve, carve it out anyway!

Set aside 15% of your budget as a Project Contingency reserve and reduce the budget for all project activities accordingly.  In most cases, with the buffers already built in to most estimates, your project team will be able to complete their activities with 85% of their original estimate.  For the few cases where they cannot, as well as for all the threats that do occur, you now have a reserve to draw upon.  Without any project contingency reserve at all, your project is destined to go over budget.

Let us know your experiences with these and any other risk management best practices that you have applied on your projects.

Webinar:  Risk Management Made Easy
If you are interested in learning more about Risk Management processes and best practices, and also  would like an Excel based Risk Register that you may use for all four stages of Risk Management, sign up for the recorded webinar APM05 "Risk Management Made Easy" at www.alphapm.com/webinars.

Saturday, May 12, 2012

There Is No Such Thing As Scope Creep

A question I get asked quite often in my project management training classes and webinars is "How should you deal with scope creep".

I have a very simple answer.  "There is no such thing as scope creep.  Don't talk about it, don't write about it, don't even think about it".

What you need to talk about is scope change, and as Shrek said to Donkey in the movie Shrek 2, "Change is good".

Now this does not make sense to many project managers.  How can scope change be good?  Does this not mean that your client is trying to get some changes made to the project, without paying for them or allowing the schedule to be extended.

No it does not.  We tend to assume that is the case. Some clients may even tell us "we have no more money for this project, so just do it".

My advice is, just treat this as good input and reply,  "I understand - let us go back and examine the changes you have requested and we will let you know their impact and how we can accommodate them".

Before we go any further, let's explore why scope change is good and something to be embraced, rather than resisted. 

Scope change can be needed by your Client for a variety of reasons, such as:
-  It was missed during the Scope Definition stage
-  It is needed because of a change in business direction
-  Some project stakeholders were not involved in the scope definition and are now demanding the change.

Whatever the reason, the project is going to be much better off with the change, so we need to find a way of implementing it in a "win-win" way.

Some of the ways you can accommodate a requested change include:
-  The change is minor and can be implemented with no or minimal cost
-  The change can be easily implemented as an enhancement, or in a future phase of the project
-  The change does have a cost and impact if implemented immediately and this cost and impact should be determined.

But if the client has no more money for the project and the changes do have a significant cost, now what?

Here's a true story.  I was overseeing an important project for our company, when the project manager came to me and said "The client wants some changes".  I replied "You know our process - fill out the change request with the cost and get him to approve it".

He came back and said the client said he has no more money for the project, but needs the change.  This was an important project for us to be successful on, and even though it was fixed price, I decided we would absorb the change.  A few weeks later, the project manager came back and told me the client wants some more changes.  Again I told him to fill out the change request and submit it to the client.  This time I received an irate call from the client asking me to fire the project manager.  "He keeps coming to me asking for more money and I keep telling him we have no more money".  I said, "Don't blame the project manager.  I asked him to give you the change requests".

We went back and looked into what we could do and came up with the approach that maybe the client would accept not doing some other functions that we felt were not as beneficial, in exchange for doing the requested changes. When we submitted our proposal to the client, to our surprise he accepted it without hesitation.

So don't forget, trading scope can be a great way to accommodate scope changes without incurring additional cost.  The client benefits with the changes, and the project benefits from keeping on schedule and within budget.  Talk about "win-win".