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.

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.

Success Starts With Motivation

I am often surprised during my project management training workshops, webinars and consulting engagements, to find that there is generally very little real interest in keeping a project on schedule and within budget. 

This is most likely because most project managers and their client and  executive management have become so used to seeing all projects delivered late and over budget, that getting projects in on-time and within budget is not seen as even achievable.

This mindset is untenable.  Unless we at least strive to manage within our budget and schedule, and work to constantly improve our skills and processes to achieve that goal, then we will never break the cycle of bringing in projects late and over budget.

Success in this area all starts with one key ingredient - and that is motivation.  Only once we are fully motivated to do everything in our power to bring in our project successfully, can we succeed.

But unfortunately it is not just the project manager who has to be so motivated.  All project stakeholders, from our clients, to our management and project team have to be similarly motivated and therein lies the challenge.  But we can certainly set the goal and expectation of delivering on time and within budget, make this goal very visible and reinforce it through our plans and actions and through a myriad of project management best practices such as Change Management, Risk Management and establishing Contingency Reserves.

Motivation is only one of four ingredients in the formula for success, albeit a key and very necessary ingredient.  In my next post, I will share the formula and remaining ingredients.

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.

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

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?

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?

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.

Don't Let The Icebergs Sink Your Project

  On April 10, 1912 the Titanic left Southampton on its maiden voyage to New York.  In spite of many warnings of icebergs ahead, Captain Edward John Smith kept full speed ahead.  He had a schedule to meet and the ship, after all, was unsinkable.  Of course, we all know the rest of this tragic story.

In my webinar on Risk Management I take a poll on whether people are doing Risk Management on their projects and find a surprising result.

Risk Management processes are only being consistently applied to projects about half the time..  How can this be?

I believe this is likely due to a combination of these factors:
-  Risk Management processes are considered to be "bureaucratic", with more effort needed to carry them out than any benefit to be gained
-  It is seen as too difficult to accurately identify project risks, their probability of occurrence or expected impact
-  A Project Manager has no time at the beginning of a project to worry about future imaginary risks when there are real problems and issues to tackle.

  If you are one of those who do not always apply Risk Management to your project, let me walk you through the steps in all four Risk Management stages and show you how easily you can apply them to your next project, big or small.

Addressing risks before they occur is always going to be easier and less costly than waiting for them to happen first before addressing them.


Risk Identification


-  Identify project risks in Risk Workout sessions with your project team, client and other key project stakeholders.
-  Use a Risk Checklist or Risk Breakdown Structure to ensure you cover all the key areas of potential risk on your project.
-  Don't forget to identify Opportunities (risks with a positive impact) as well as Threats (risks with a negative impact).
-  Use a simple Register to identify and easily manage and track your project risks through all four Risk Management stages.

Risk Analysis


-  Estimate the Probability of Occurrence for each risk.

An easy way to do this is to decide:
-  if the risk is not too likely to happen, use 0.3
-  if the risk is quite likely to happen, use 0.8
-  if you think it is somewhere in between, use 0.5 for the probability.

-  Estimate the Expected Impact for each risk; i.e. how much is it going to cost to address this risk if it were to occur.  This can be difficult to assess with any accuracy, so don't get hung up here.  Use your team, client and subject matter experts to come up with an order of magnitude estimate (e.g.  is it $500 impact, $5000 impact, $50,000 impact etc).  It is far better to come up with rough estimates like this then to do no risk management at all, and essentially be saying that all potential risks will have zero impact and zero probability of occurring.

-  The next step in the Risk Analysis stage is the easy part - calculate the Expected Monetary Value for each risk, using the formula:
Expected Monetary Value (EMV) = Probability of Occurrence x Expected Impact.

-  Now sort all risks by the size of their Expected Monetary Value, keeping the Top 5 to 10 or so for your further action and delegating the rest for review and action by the appropriate project team members and stakeholders. You can vary the number that you are going to track, but don't try and track all the risks that are identified, or you will sink in the quagmire.  The Pareto Principle will usually apply here - about 20% of the risks you identify will cause 80% of the expected $$ impact, so just focus on this top 20%.

If you use a spreadsheet for your Risk Register, the EMV can be automatically calculated and your risks can be readily sorted by EMV size.

Risk Response Planning

-  Now determine with your team a suitable response for each of your top risks.

For threats, use any of the following strategies to address each risk (and use several, if appropriate):
-  Avoid (take a different path, like the captain of the Titanic should have done)
-  Transfer (e.g by insurance, or outsourcing)
-  Mitigate (any solution that will lessen the probability and/or impact of the threat)
-  Accept (normally not a good choice, unless the expected impact is small)

For opportunities, the strategies should increase the probability of occurrence and expected benefit, so would include, for example:
-  Develop
-  Exploit
-  Grow
-  Support

Make sure each of the selected strategies and actions have a person assigned to action them, with target dates for check-pointing progress or completion.

Risk Monitoring and Control

- On a regular basis, review your project Risk Register to update the status of all identified risks, remove any that are no longer applicable and add any new risks.  This review can be incorporated into your weekly team meeting, or the action items can be transferred to your Project Schedule or Project Issues Log, depending on the nature of the planned actions.
- Major risks and related action items should also be tracked and reported on your Status Reports, Project Dashboard and at your Project Executive Steering Committee, to ensure they get the attention and support needed for their successful resolution.

In my next post, I will provide you with three very valuable Risk Management best practices, that together with the above Risk Management processes, will help you to successfully avoid those icebergs. 

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.

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".

Are We Having Fun Yet?

Somewhere between that magic time when we are very young, to becoming an adult, we seem to lose the ability to have fun.

When we are young, we take delight in the world around us.  As we get  older, we start to see problems instead of opportunities, work instead of play, limitations instead of freedom.  The list goes on, but I am sure you get the idea.

Is this a problem, or is it just reality?  I vote that it is a problem, because in the process, we start to lose creativity.  As my son so nicely points out on his own blog, we are taught to color within the lines, because it is "wrong" to do otherwise.  We ensure (at least most of the time) that we follow the rules of others, instead of our own rules.

Perhaps worst of all, we start to accept things as they are instead of as we would like them to be.

What has all this got to do with project management?   In my last post, I talked about the "one most important thing", the importance of focus on and commitment to project goals.   As Steve Jobs was fond of saying (just before he announced yet another amazing product from Apple) there is "one more thing" that we should embrace for our projects to be successful, and that is the importance of "having fun" on our project.

If you are lucky, having fun is part of the culture of your organization.  We can debate at some other time whether the reported Apple culture of secrecy and paranoia bred by Steve Jobs is something to be emulated, since it has somehow produced such stellar results to date for Apple.

But I think it is true to say that for most people and for most organizations, the ability to have fun and enjoy what you do is a better ingredient for success than living in fear of your boss, or working in an atmosphere of paranoia and secrecy  When you and your project team are having fun, there is likely to be more creativity, more trust and more productive team work then when there is fear, distrust and conflict within the team.  If your team is having fun, then your project is more likely to be successful.

So how do you make sure that you and your project team are having fun.  Is it just a matter of having more pizza Fridays, a casual dress policy and team picnics?  These may certainly help, but we need to go much deeper than this.

Ask your project team what is needed for them to have fun on your project, and I don't believe you will find that Pizza Fridays is high on their list.  You will more likely find that improving communications, better team work, and helping them achieve their personal goals and develop their technical and managerial skills will rank much higher.

As a result of making your project a fun place to work, you will also be making it more productive and successful as well.  And as Martha might say, that can only be a good thing.

Your assignment:  Do a short "Are We Having Fun" plus/delta session with your project team at your next team meeting, and please share the results with us.

• Plus:    What are the things that make our project fun to work on?
• Delta:  What are the things we (as a project team, and I the Project Manager) need to do to make it more fun to work on our project?

The One Most Important Thing

I always start to laugh when I see questions like “What is the one most important thing that a project manager should do to be successful?” posted on sites such as LinkedIn. 

There are hundreds of things that a project manager needs to do on a project, and all can be very important at a particular point in time, depending on the project size, complexity and phase.  So trying to pin down one as the most important thing is surely futile.

However, upon further reflection, I think there is indeed “one most important thing” that a project manager should do, for all projects and at all times, and that is to maintain a strong passion for, focus on and commitment to project goals.

All goals should be SMART (Specific, Measurable, Achievable, Relevant and Time-based). 

 

Perhaps the best and most concise example ever of a SMART goal, was the goal set by President Kennedy on May 25, 1961:
“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth”.

In spite of the many financial, logistical and technological obstacles encountered, this most ambitious goal was spectacularly and completely achieved with the Apollo 11 mission landing on the moon on July 20 followed by the safe  splashdown of the astronauts on July 24, 1969.

A SMART project goal could be:
“The goal of our (name project) is to deliver the committed functionality by (cutover date) within budget ($$$), so that we may meet (specify the key project objectives) to the complete satisfaction of all our stakeholders.”

Now here’s the scary part. According to studies by The Standish Group, only about one third of all projects are completed successfully.  This tells me that in spite of the generally high levels of expertise, methodologies, tools and technologies applied to projects, we still have a long way to go before we can consistently meet what should be readily  attainable project goals - goals which are usually set by us in the first place.

On any project of significant size today, there are many financial, technological and other obstacles and challenges that impede or prevent project goals from being achieved.  Without a high level of passion, motivation and commitment to project goals by the project manager, it is highly improbable that the project will succeed, no matter what resources, methodologies, tools and techniques are brought to bear on the project. 

 

The project managers who are most likely to achieve the project goals are those who ensure the goals are highly visible in every facet of their project, are passionate and excited about the goals and are highly committed and motivated to achieve them.

Your thoughts?