Author: George Bridges

The PMBOK Guide ® – Is it Enough?

Written by George Bridges on March 20, 2012. Posted in Articles. 4 Comments on The PMBOK Guide ® – Is it Enough?

There have been some changes to the PMBOK® Guide in the Fourth Edition. Since the PMBOK® Guide is an ANSI standard, PMI must assess it every 4-5 years to determine if an update is needed” (Cyndi Stackpole).

The increasing acceptance of project management indicates that the application of appropriate knowledge processes, skills, tools and techniques can have a significant impact on project success. The PMBOK Guide indicates that subset of the project management body of knowledge generally recognized as good practice” (PMBOK Guide ®3^rd Edition, 2004).

It is clearly stated that the PMBOK Guide® is a subset of the project management knowledge and the field of project management, like many other professions is too vast to be captured in a single book or guide.
Project Management is like Venturing into Deep Water

Is the Project Management Body of Knowledge enough to build and sustain a rewarding career in project management? Over the past 30 or more years, we have seen the increase in the number of Certified Project Management Professionals (PMP). As of the writing of this paper, PMI reports that there are over 300,000 people who are now PMPs. Many professionals have been thrust in the arena of project management either on their own or by a push or nudge from their managers or others. Project Management has been referred to as the “accidental profession” because in the past no one has set out in their early career choices to become a project manager.

Let me explain how getting into project management sometimes happens. Professionals from marketing, finance, sales, and engineering are asked to lead or manage a project. They have had no or very little formal training in project management. After working on a few projects they begin to learn more and more about the profession of project management.

Getting involved in project management is a lot like learning how to swim, ride a bike or learn a new sport. Let me compare learning project management to learning how to swim.

I learned to swim at around ten years of age and have been swimming all my life now. I am by no means an expert at swimming, but I received enough training and experience to work as a lifeguard for a few summers.

When I first learned to swim, the instructor gave all first-time swimmers an orientation of the pool. Every new swimmer learned about the “shallow end” of the pool and the “deep end “of the pool. The “shallow end” is about 2–4 feet of water and the “deep end” is about 5–10 feet, depending on the size and shape of the pool. All beginning swimmers were instructed to stay away from the “deep end” until you passed a test to certify that you could survive in the “deep end.” So as a beginner, even though you could see the “deep end” and perhaps go near it, you dare not venture into it until you have gotten the appropriate instruction and training. There were many other safety practices that were taught, but knowing your environment (the pool) was critical and could mean life or death if you valuated this safety principle.

Learning project management is very similar to learning how to swim. Those that are new to project management are like those that are learning how to swim for the first time. The new project manager can accomplish and manage new and small projects; they have to stay in the “shallow end” of the environment where they are applying project management. They learn to do and perform more as they practice the profession of project management. The new project manager applies the practices they learn and become skilled at project management.

However, at some point, the project managers are called to handle larger and more complex projects. Just as swimming in the “deep end” of the pool, much more is at stake with these large projects and they cannot be managed in the same way as the smaller projects. In order to handle the larger project, more training, coaching and experience is needed. The PMBOK Guide ® becomes the foundation of project management knowledge that is needed to transform the new project manager to a more seasoned project manager that can take on the challenge of leading and guiding a team of people on an extensive project assignment.

The PMBOK Guide is used to prepare the project manager to go into the large complex and complicated environments. This is very much like preparing and learning how to swim in the “deep end” of the pool.

Note that as a swimmer, once you have been qualified to swim in the “deep end,” this does not mean that you can now go diving in the Atlantic or Pacific Ocean. Similarly, the PMP Certification will give you the foundation to handle and manage the larger projects successfully, but more training and skills are needed to maintain and sustain success on future projects.

The PMBOK Guide is enough when you think of it as a starting point for your career in project management.
The PMBOK Guide is enough when you use it as a launching pad for bigger and more challenging assignments in your industry.
The PMBOK Guide is enough when you recognize that it is a subset of the project management body of knowledge and it represents the best practices from a cross-section of professionals.
The PMBOK Guide is enough when you recognize that it is a standard that is now part of a collection of standards in the PMI Standards Library. In fact, just recently, PMI has made an announcement about its Standards Navigator. Here is what they say about it:

“PMI’s new Standards Navigator offers an innovative way to get the most from our library of global standards, especially for organizations.”

As you can see here, the PMBOK Guide is now a subset of the PMI Global Standard, which includes OPM3, the Program and Portfolio Management.

The PMBOK Guide is enough if you consult with the other project management standards. As a PMP, we are required to keep our certification current, by maintaining and contributing to the project management knowledge. We can do this in a number of ways as required by the Project Management Institute. Our individual contribution to the field of project management will ensure a continuing evolution and growth in our profession. The PMBOK Guide ® is enough if we can continue to add our new ideas, new concepts, new approaches and new project management skills. Local, global, international, multinational companies are all requiring those that practice project management to gain both the PMI Certification and internal certification as well.

Don’t forget to leave your comments below.

George Bridges is a Director of Business Analysis with more than 25 years of experience in business systems analysis, business process modeling, operations research and Information Technology. George teaches business analysis and project management to hundreds of seminar and class participants every year. He has participated in the analysis and development of business systems for major corporations, such as Ford Motor Company, Unisys Corporations, and for a large church in the Metropolitan Detroit.

How to Manage the “Bad Apple”

Written by George Bridges on March 6, 2012. Posted in Articles. 3 Comments on How to Manage the “Bad Apple”

Hanging_Fotolia_4097682_XS Every fall, my family and I plan a trip to visit one of the many apple orchards in southeast Michigan. Our day is spent on a tractor, going to the many fields of trees to pick some of the finest apples in the world. We fill our basket full of good, fresh apples. In choosing our apples, we generally will pick the best-looking apples. These apples are mostly on the tree and in some cases they have already fallen to the ground. Any blemished or bad apples we will not pick.

After carefully picking our apples, after a few days we discover some apples are going bad. If a decaying apple is left in the same position and allowed to stay with the other apples, it will affect the apples around it and they will start to deteriorate. If not careful, you could end up with a bunch of bad apples.
The principle of this fact, as we know, is that one bad apple can spoil the entire bunch. This fact is true on project teams in many organizations. Project Managers acquire people who are characteristic of bad apples. They are not “bad,” but have developed bad attitudes. A person with a bad attitude can be disgruntled, could be having a bad day or simply have reached a point where their bad know-it-all attitude prevents them from getting along with team members, project manager and stakeholders. What do you, as a project manager, do when you encounter a “bad apple” on your team?

A “bad apple” team member may not always be obvious. But, they will usually show up somewhere during the life of the project. As a manager and project manager, the “bad apple” has to be dealt with properly, promptly and swiftly.

John Maxwell in his book, Seventeen Laws of Teamwork, suggests that a leader, before dealing with a person with a bad attitude, should do some self-reflection and check their own attitude. The person that is leading needs to make sure they are not the problem.

A few simple steps in dealing with the “bad apple” are as follows:

First, document the problem or symptoms as they begin to reveal themselves.
- Make sure you have all the facts and have completed an inspection of the problem areas. In other words, find out the facts and write them down.
- Look for and isolate areas that may be the cause of the poor behavior, i.e., life changes, health challenges.
- Has their attitude changed during the course of the project?
The next step is to meet one-on-one with the “bad apple” to provide counseling and advice on how to improve the problem that has been encountered.
As a Project Manager, you must try to get to the root of the problem and find out what can be done to correct the situation.
Once you are assured of the problem, a correction plan or course of action to solve the problem should be initiated. As a Project Manager, you should document the course of action discussed and you and the team member should sign off on this plan.

Finally, after these steps are completed, the team member will need some time to make the necessary agreed-upon changes to correct the problem. Visible results should be seen, documented and praised. However, if no change is observed and the behavior continues, the Project Manager must start the process of removing the team member. It is obvious to everyone on the team that the bad attitude can and has affected the project. The team members are waiting for the Project Manager to take the lead and make corrective action.

A person with a bad attitude has to be dealt with; either correct the problem or remove them from the team. The behavior cannot be allowed to continue because it can result in permanent damage to the deliverables of the project as well as project failure.

Dealing with difficult people is not a new problem in management. Many authors have written books about how to deal with difficult people. John Maxwell has included “The Law of the Bad Apple” as one of the Seventeen Laws of Teamwork. John points out that not everyone who starts with a team or starts out on a journey will be there until the end. This is important for a leader to recognize. Some will leave voluntarily and others will have to be let go.

A Project Manager should keep the lines of communication open with the functional managers where the people resources originate. Letting the functional manager know the problematic issues with the employee can facilitate the negotiation to remove the “bad apple” from the project team.

A few years ago, as Director of an Information Technology team, I experienced a “Bad Apple” on our project. The person was consistently going around the chain of command and created a lot of confusion on the project. The person was eventually terminated. After a few years, the IT manager asked me if he should re-hire this person. I was against the idea, but the manager hired him anyway. The manager had the same type of issues with this person. After much time and frustration, the manager had to release this employee again. Sadly, the bad behavior and bad attitude of this person did not change after many years.

In closing on a positive note, when a team is free from the negative nature of a person with a bad attitude, the team will rise to new heights and the performance will be notice by everyone.

In my thirty years of experience in the managerial industry, I have had experience with teams that have accomplished and succeeded the objective of the project. It is a rewarding experience for all members of the team.

Deal wisely with the “Bad Apples” and watch your team soar to new heights!

Don’t forget to leave your comments below.

Ten Reasons to Trash your Risk Management Plan

Written by George Bridges on February 15, 2012. Posted in Articles. 4 Comments on Ten Reasons to Trash your Risk Management Plan

GB_Feature_Web Do you have a Risk Management Plan (RMP)? If you do not, then this article is not for you. If you are managing a project of any size and you have not developed a Risk Management Plan, then your project is most likely already in trouble.

If your answer is yes, then you may want to continue reading this article. Many people talk about and also attempt to develop a Risk Management Plan but either give up on it or place the effort in the low-priority to-do list. Others have a risk plan that does not actually provide the guidance and value that is needed to be effective.

Because the maker of the RMP did not give it the attention it deserves, it is usually thrown together without any real in-depth research, just to say that it was done. Like the son that was told to clean his room. When his mother checked it, the room was cleaned. But she later discovered that everything was piled high in the closet, out of sight and out of mind. It is important for the project manager and team to view the plan as something that can provide lifelong project value. All too often, project teams develop a Risk Management Plan because everyone says they should. It may be part of a methodology or a requirement within a Project Management Office (PMO) and is given cursory attention, something like punching a ticket or checking something on a list. Or they may have just passed the Project Management Professional (PMP) exam and know they need to have an RMP. So they do one! Why? To report that they have one and they can now tick that off of their checklist.

So, if you have an RMP, I give you my top ten reasons why you should trash that plan. Take a look at these and reflect on them.

Risk management is one of the nine knowledge areas of the Project Management Body of Knowledge (PMBOK®). Every management template includes an area to provide information about risk. Several books and articles have been written on the subject of risk management. Here are a few good books on risk management that you may want to read or add to your library:

Risk Management, Rita Mulcahy
The Practice Standards for Risk Management, PMI
Project Management a Systems Approach, Harold Kerzner

From a global perspective, more organizations are putting emphasis on risk management to assist in reducing the number of reported project failures. A well-developed Risk Management Plan should mitigate the risk for project failure.

For example, listed in the table below are the results of a poll from our project management website, allPM.com. In that poll, we asked for the top five documents needed for project success.

GB_Table_1_web2

As shown in the table above: The Risk Management Plan and Log is one of the top five documents needed for project success. Having a Risk Management Plan for your project is not optional; it is a necessity for the overall project success. The guideline and methodology we recommend for risk management is derived from the Project Management Body of Knowledge (PMBOK). In this article, we discuss some of the concepts regarding the creation and management of a Risk Management Plan.

Here are some ideas for creating and maintaining a good Risk Management Plan (RMP). You should start developing your Risk Management Plan during the early feasibility study. The RMP should be elaborated during the business case development process. Highlights of the RMP should be included in the development of the project description document and the project charter. The final RMP should be a part of the overall Project Management Plan.

A good Risk Management Plan and execution of that plan requires most of the team members to be involved. Collectively, the team will identify, analyze and develop the components of the Risk Management Plan.

A good outline of the PMBOK’s Risk Management Plan structure is shown in Figure 1.

GB_Table_2_web

I recommend a risk management plan be developed and acted on throughout the life of the project.

Here are the Top Ten Reasons to Trash Your Risk Management Plan

1. You should trash your RMP if you have not spent enough time or effort in developing the plan.

2. You should trash your RMP if your project is large and complex and you only spent a few hours developing the plan.

3. You should trash your RMP if the right people were not involved in creating the plan.

The project team can have the most brilliant people involved. However, if you missed a key stakeholder when identifying risk, you may have overlooked a key element in the plan that will cause the project to fail.

4. You should trash your RMP if the plan has been on the shelf for more than ten days.

A good plan must be reviewed on a regular basis. A Risk Management Plan should be reviewed every week and be a permanent part of every project management status meeting.

5. You should trash your RMP if you never talk about risk in your project meetings.

Every Project Manager (PM) should make it a part of their daily and weekly schedule to talk about risk. You cannot ignore this subject; the stakes are too high.

6. You should trash your RMP if your management only thinks of risk in terms of losing money.

Risk can be thought of as positive and negative. Management may need to be educated on the positive risk and how they can be managed.

7. You should trash your RMP if you have not done an exhaustive identification of all possible risks.

Rita Mulcahy, in her book, states that you should ID hundreds of risks in the early stage of your project. Not all risks will be part of the plan, but the exercise of finding and documenting as many as possible can benefit your project.

8. You should trash your RMP if you don’t know who to talk to about a risk.

There is a people side of risk management that we cannot ignore. Subject Matter Expert (SME), stakeholder and sponsors must engage in the conversation about risk.

Risk, issues and problems are discussed in the same context.

Risk and issues are different; they should be tracked and managed separately.

9. You should trash your RMP if a budget to handle risk is not established.

Your risk plan should be supported by a budget for risk response and contingencies. As PM, you limit your risk budget issues during the course of the project. The budget needs to be settled early in the project.

10. You should trash your RMP if you don’t know when to use quantitative methods to access the risk.

Risk Management may not include a quantitative analysis. Only in special circumstances will you need to invest the time and money in doing a quantitative analysis of your risk.

Summary

Are you doing risk management or are you just going through the motions? Risk management is just one of those things to do in your busy project environment. You know you need to do it right, but the urgency and priorities of other areas of the project do not allow you to allocate the time and resources to manage your risk properly. Therefore, you may want to trash your RMP and seriously do what’s necessary to manage the RMP correctly. I realize that it is hard to break away from day-to-day priorities. But if the RMP is done correctly, it will add value to your project. In the words of Nike, “Just Do It.” You will enjoy its benefits.

Don’t forget to leave your comments below.

References:
1 – Risk Management – Tricks of the Trade for Project Managers, Rita Mulcahy, 2003
2 – The Practice Standard for Risk Management, PMI
3 – Project Management – A Systems Approach, Dr. Harold Kerzner