Creating An International Culture Of Success

The International Business Dimension

Multinational teams present new challenges for the International manager. There are logistics problems: How do you coordinate teams that work in different time zones? What kind of collaboration can you create in a team that rarely sees one another?

As well as the logistic problems come cultural problems. For example, successfully creating a culture of innovation can be a challenge. Honeywell experienced this, according to a November, 2013, Time article, when Rameshbabu Songukrishnasamy began working as general manager of the company’s R&D centers in Shanghai and Beijing. He found his employees were not innovating. They weren’t tinkering or inventing on their own — not a positive sign in an R&D lab! “They were happy just doing what they were asked to do,” Rameshbabu says. The problem is, R&D is about doing something new.

A project manager for a large corporation in Brazil recently told me that the PMI Book of Knowledge is used infrequently at best inside Brazilian projects. He also warned against assuming that someone with a PMI certification has extensive experience, as is the case in the US. — Moore, Brandi, The Little BRIC Book.

Rameshbabu found that his Chinese workers had a fear of failure. They worried that the company would be upset if their work did not yield positive results, so they didn’t experiment. Another problem is that some Chinese engineers “tend to shy away from critical questioning,” a process that is fundamental in R&D. “The reason they are able to make so much innovation in Silicon Valley is that people question the status quo and find alternative ways,” says Rameshbabu. But he found that Chinese culture and education focused on rote learning, not critical thinking.

Creating A Culture Of Success

Creating successful International programs requires understanding and adapting to different business cultures. Applying Western management practices in Asia will fail, just as surely as transplanting Western employees into an Eastern environment. Imagine an independent, critical thinker from Silicon Valley landing in Foxconn, Shenzhen — where challenging the status quo is forbidden.

Team dynamics play a huge factor in management style, objectives, and capabilities. Building a culture of innovation is just one example of where these dynamics become complicated. Power distance will affect everything from goal setting to how problems are socialized. Communication style can quickly lead to misunderstandings. Differences on the fluidity of time can mean completely missing the mark with customer deadlines. And differences in identity and engagement style can lead to initial confusion, bad first impressions, or distrust.

This is why understanding business cultural practices is so important. Hyrax International LLC has a program that explores each of these five preferences. The program examines each of 27 different management disciplines, such as goal setting, risk management, change management, and assessing outcomes. The affect of business culture on each discipline is explored and explained, providing a road map to success on the International management scene. The company also offers many free resources to explain and explore International project management, and is also sponsoring Successful International Project Management, an in depth book that maps project management processes to cultural preferences.

We’ll be posting five more parts to this article (read Part 2, or see the entire series right here) in the coming couple of weeks. Each post will look at one of the five business cultural preferences, and briefly introduce how that preference impacts and affects the 27 management disciplines.

Hyrax International LLC’s Global Project Compass™ is the only visual map that clearly shows the connection between business culture and business process. This is what makes Cross Cultural Management™ so much more effective than traditional management.

The Compass maps 27 project management disciplines directly to business cultural preferences, and shows how these preferences affect business. The goal of the Global Project Compass, and Hyrax International’s associated management program, is to show how culture affects businesses worldwide — and to provide a clear map on how businesses can adapt successfully.

What you won’t get out of your certification

When it comes to project management certification, there’s no doubt quite a few options available. The real question is, do you know what you’re getting with a shiny new certification (such as PMI’s PMP, or IPMA’s Level A through D)?

Certification programs are more about demonstrating your competency than about learning how to manage. Consider this: PMP and IPMA certification takes you through a process guide and an examination that you can easily enough prepare for in a few weeks. The process guide itself is a valuable reference, a great way to organize all the possible areas of knowledge in a project — but it’s just that. A process guide is largely a checklist, giving you a tool to make sure all the right pieces of a project are in motion.

The other part of the certification process is the exercise of documenting your experience, as a project manager, and having the certifying organization vet your experience (although the vetting process is often cursory). It’s supposed to show the world that you have a certain level of project management competence. It is explicitly not going to teach you that competency. The real theory behind PMP certification is that by achieving it, you have demonstrated relevant competency as a project management professional. There’s a good bit of debate regarding the value of this certification: How well does the PMI do in vetting experience? Is there any qualitative distinction in the evaluation? I’ve seen a few terrible managers get their PMP by documenting their management of projects that were miserable failures.

For the most part, deciding whether a candidate’s PMP or IPMA certification (or lack thereof) is valuable lies with the employer. For the individual, I always recommend learning the bodies of knowledge, so long as you are fully aware of what you’re getting. Here are a few of the things that either program won’t prepare you for:

  1. Project management is more about management, and less about process. Most of the certification programs out there tend to emphasize the latter, the process, and spend little time on the “soft and fuzzy” bits: People. The fact is, this is where you’ll succeed or fail. It often comes down to how good you are at picking up on subtle (and not so subtle) cues between team members, sponsors, and stakeholders. There is no certification program in the world that will teach you how to be a great manager — that requires experience, more than anything else (but if you have a degree from a top management school it’s bound to help).
  2. The rosy project you just inherited is actually completely out of touch with reality. More often than not businesses will commit to a project that can’t be met (often establishing budgets and schedules in the process). Studies by Standish and KPMG bear this out, pointing at 70% of projects failing to meet cost, schedule, and quality goals.
  3. Identifying all the right pieces of a project is just the beginning. For example, knowing who the stakeholders are (an important step in the PMBOK) is the easy part. You’ll spend far more time motivating them, coordinating their schedules, dealing with stakeholders that want your project to fail (or just don’t care about it), responding to impossible demands, and figuring out what everyone’s secret agenda is all about.
  4. You’ll need to be good at managing other people’s anger and frustration. Part of being a strong manager is knowing how to evaluate the project dynamics, and then make the right decision. Most of the time, you won’t find a rosy world where everyone agrees about what has to be done. You’ll be stepping inside someone else’s world, and messing with it. You’ll have to tell people to do things they don’t agree with, or don’t want to do. You’ll have to step in and change everything, and people don’t like change.
  5. Your certification didn’t warn you about some of the important bits. There is no such thing as a comprehensive process guide or methodology that gives you all the answers. Some guides are really good in some areas, and horrible in others. The PMBOK, for example, spends precious little time talking about quality assurance and risk management — so little, in fact, that without turning elsewhere you won’t have any idea what these two things are, how important they are, or what to do about them.
  6. You are actually not ready to manage a large scale project simply because you’ve earned your PMP/IPMA/PRINCE2 certification. These certification programs document your past experience, and your basic knowledge of the relevant process guides. Unfortunately, splashy advertising sells certification, so I’m sure we’ll keep seeing claims such as “everything you need to manage complex projects!” It’s a lie.

Deciding whether obtaining a certification is worthwhile or not is a personal decision. I definitely recommend learning the reference material — and after all, if you learn the PMBOK, it’s not much more work to get a PMP certification. Just be honest with yourself about what it means. Being a good project manager means having the experience to guide an organization toward success, not just recite the process guide. I always recommend starting small and finding out what your personal aptitude for management is.

Your key to success as a project manager is going to hinge on your ability to listen to others, learn from others, and always be open and ready to support your team. You’ll need to turn to other people and other sources of information. Be humble, never let obstacles derail you, and make sure your team knows they can rely on you for support. These are the things you don’t find in the process guides.

The good (and bad) about Project Management School

I’m frequently asked what I think of certifications such as the Project Management Institute’s PMP, or its other programs. Generally I’ll say that programs such as these (including those offered by IPMA, and the UK’s PRINCE2) are valuable tools to know. They represent bodies of knowledge that any project manager should be aware of. In fact, I’ll go so far as to say that any project manager that is serious about their career should be well versed in more than one body of knowledge, able to recite the encyclopedia of information offered, and above all, be aware that neither will teach you to be a good project manager.

There’s a host of information you won’t get in school (not even from a top tier management school, let alone a certification program you can cram for in less than two weeks). And that leads me to the value of the certification itself. Here I’ll generally weigh in saying “it’s up to you.” If you feel going through the certification process will be a helpful learning experience, then by all means do it. On the other hand, getting the certification will neither teach you to be a good project manager, nor will it have a great impact on your career.

It’s important to realize that the Project Management Institute (or PMI) is not a standards body. PMI is a for-profit company that sells several products, and those products are all essentially based in the PMBOK (for example, you can seek certification as a Project Management Professional, or PMP, through PMI’s certification process). This imposes a couple of limitations on the concept of the PMBOK being a robust standard:

  1. Successful standards bodies are international in nature, and the best of them are completely unbiased — something that usually requires forming a body that is not motivated by profit attached to its own products. PMI is, ultimately, concerned with corporate profitability, and this has led to some debate regarding whether the PMBOK has evolved first-and-foremost as a leading project management standard or as a product that PMI can easily sell.
  2. PMI tends to be very insular in its thinking. By this I mean that it does not extensively rely on third party standards — quite the opposite, in fact. The PMBOK is almost exclusively a self-contained work. It does not reference the 50 years of decision management theory that constitute strong risk management practices. Nor does it reference other standards, such as the ISO’s work on quality management. This, naturally, tends to keep people more involved in the PMI’s products, as opposed to moving into other standards.
  3. The PMBOK standard is unquestionably a solid reference volume with extensive project management knowledge — however, it also has startling weaknesses. For example, it’s coverage of risk management and quality management is largely negligent, and it’s strong focus on technical knowledge completely ignores the human factors addressed by methods such as Kanban.

The PMI’s Project Management Body of Knowledge (PMBOK) represents a strong reference guide, and one that I turn to when appropriate as a process guide — but its very strength as a reference text also makes it a poor companion for someone looking for a comprehensive project management methodology. It lacks the practical, hands-on information needed to apply much of the knowledge it presents.

That tends to mean that novice project managers turn to the PMBOK far too often, hoping that it will solve management problems (it won’t). Experienced project managers recognize that it’s a process guide, and nothing more — which means it’s a provides a great checklist to make sure all the right pieces are being executed, but it does little to tell you how to execute those pieces. That comes from experience. The experience of managing people, learning how teams work together (and often don’t work together), how to motivate and communicate, and how to see problems coming before they hit you.

The bottom line is simply this: No school, and especially not one offering a short certification program, can teach you to be a good manager. That’s what project management is all about — it’s not the technical process, more often than not, but the personal factors and the management skills that make or break a project. So yes, get familiar with all the standards, bodies of knowledge, and process guides you can. Learn what you can from each, and use that knowledge as a reference when deciding how your project will be run. But don’t ever assume that this encyclopedia of knowledge has taught you how to manage successfully. That’s going to take management training and experience — more the latter than the former, in my opinion. A lot of it, most likely.

Training versus development

Mike Myatt, Chief Strategy Officer N2growth, recently posted a very savvy article regarding the difference between training (a typically rote, stale process) and development (more dynamic, needs-based, and effective) in the context of leadership. What I really liked is his point-by-point comparison of the strengths and weakness of training versus development:

  1. Training focuses on the present — Development focuses on the future.
  2. Training focuses on technique — Development focuses on talent.
  3. Training adheres to standards — Development focuses on maximizing potential.
  4. Training focuses on maintenance — Development focuses on growth.
  5. Training focuses on the role — Development focuses on the person.
  6. Training indoctrinates — Development educates.
  7. Training maintains status quo — Development catalyzes innovation.
  8. Training stifles culture — Development enriches culture.
  9. Training encourages compliance — Development emphasizes performance.
  10. Training focuses on efficiency — Development focuses on effectiveness.
  11. Training focuses on problems — Development focuses on solutions.
  12. Training focuses on reporting lines — Development expands influence.
  13. Training is mechanical — Development is intellectual.
  14. Training focuses on the knowns — Development explores the unknowns.
  15. Training is finite — Development is infinite.

I couldn’t agree more. When it comes to leadership development, you can’t “train the leader.” Training on technical, procedural topics is of course highly effective, but leadership requires too much contextual differentiation, too much innovation, and frankly relies much more on innate skills that can only be developed over time, not absorbed from a short training course.

Tackling the global project problem, part 2

In my last article on preparing for global project challenges, I addressed a few of the more soft skills oriented issues such as cultural differences and basic mismatches in business environments. For this second installment, I thought I’d share a few concrete ideas for tackling some of these issues — things that can make a real difference, and aren’t that hard to put into play. To keep on a theme, I’ll focus on strategies to tackle the common, core issue raised in my first article: communication and execution problems.

Recap: Face up to communication problems

Last month I pointed out that we have to deal with a lot more than language barriers with global projects. For example, in some cultures, speaking openly is not to be expected, in any setting. Furthermore, communication is often strongly augmented with non-verbal cues that simply don’t come across the telephone or email channels. The very method someone uses to communicate often carries an important message in and of itself — “reading between the lines” and picking up on the myriad of non-English, non-verbal hints is critical. It takes time and often a great deal of experience on an individual level.

Doing everything we can to remove ambiguity from project communications can be a huge help. One of the first things I generally want to take a close look at are the techniques and processes used to manage a project. Most of the time, they are not adequate for one reason: They weren’t designed to support a global, multi-cultural organization.

Tools do help

Let’s consider some of the common problems stemming from communications issues:

  1. Assignments don’t get handled correctly
  2. Nobody seems to know what’s going on
  3. There is no single place to go to find out how well (or how poorly) things are going
  4. Sometimes people don’t seem to be working effectively
  5. Things that aren’t important get attention, while things that are, don’t

These are problems that almost every organization has dealt with at some stage in its life. The typical global project almost always faces them, and often, fails to address the root cause, and then keeps right on stumbling over the problem. Making a few strategic changes to your process, and your tool set, can help dramatically.

Use the right tool for the job

I’ve seen many organizations use email inappropriately. Email is easy to fall back on as the main communication avenue when everyone isn’t in the same office building. For example, I’ve seen engineers jump in response to a new product idea from the CEO. This leads to circumventing the project management effort, often misdirects the lead engineer, and easily puts a project off-track. After all, what’s an engineer going to do — tell the CEO to go through channels and keep working on today’s mundane task, or jump on a new, exciting idea straight from the top?

Equally damaging is responding to every customer “fire drill” that comes up. Email invariably leads to rapid-fire emergency drills, often at a very high cost. Customer service sends an email to engineering, and engineering jumps to respond — in the process, putting current tasks on hold and upsetting schedules (not to mention the engineers themselves).

Stop using email for project communications, requirements, design and, above all, assignment of work. Email is a fantastic communication tool — but it’s not the right job for communicating work items on a project. It has a poor audit trail, as you never know who did or did not read it, emailed tasks cannot be prioritized or captured in a work management system, and at the end of the day, they’re just unreliable.

Instead of trying to stay on top of a dynamic, changing organization with email, use an appropriate work management system. There’s great news here: In today’s market there are fantastic systems available to handle requirements management, task management, project planning, customer communications, resources and more. In fact, probably the most daunting challenge is simply getting enough information to make an informed decision and choose the right tool. Cost is always a concern, but make sure adequate due diligence goes into analysis of the tools. Picking the wrong product can easily create problems. For instance, some tools may work well with your project management process, whereas others may not fit smoothly. In this latter case, people end up working outside the system — and that usually means sending emails to each other.

Use the right estimation methods

Also critically important in a global project context is taking a long, hard look at the techniques you follow for project estimation. Make sure that your estimation methods take into account the complexities of a global team — this means accounting for inefficient communication and dramatically variant resource cost.

Be wary of estimation methods that focus only on the short term. “Burndown” estimates that provide visibility into the next thirty days are a leading source of project overrun and schedule slippage. An appropriately planned global project needs to communicate the goals of the project throughout the team. This includes setting very real objectives and milestones. If the milestones are variable and tend only to establish goals in the short term these become the only measures of success for the team — in other words, hitting the thirty day goal means success, because other yardsticks have not been established.

Wildly variant resource costs must also be accounted for. It’s one thing when every engineer gets paid more-or-less the same salary. When facing a dynamic, global team where costs can vary by a factor of ten, cost overruns become a very real threat. Simple estimation methods such as burndown estimates neglect these issues on two fronts. First, they don’t establish an adequate project baseline, and second, they don’t measure resource cost and progress against the baseline.

Make sure that the estimation methodology you use is adequate to the project at hand. Keep “burndown” estimates confined to projects that are either free of cost constraints, or at least operating on reasonably small budgets — so that cost overruns won’t hurt the organization.

Pay close attention to metrics — and metrics tools

Metrics tend to be a sore point with many teams. Mostly, at least in my experience, this comes from the assumption that measuring and keeping on top of project status requires a lot of work, and requires capturing a lot of data that nobody wants to capture. This is just plain wrong.

The fact is, almost every organization I’ve worked with is already capturing the data they need. It just isn’t being used right. The basic information needed to estimate tasks and monitor progress of the project as a whole is usually already in the system — it’s just a matter of getting at the data and building the right kind of reports. For example, most popular project management tools that tout themselves as being “agile” tend not to bundle reports for EVM metrics, baseline comparison, and project cost overruns. This is certainly the case with Atlassian’s JIRA, an excellent product that I’ve frequently put to use on large scale projects. Fortunately, the data recorded by systems such as JIRA gives us everything we need to perform more advanced metrics analysis. We know the original task goals, it’s planned schedule and it’s actual schedule, and can derive planned cost. That’s all we need.

Staying on top of the metrics and measuring against original project baselines translates into a very tangible return: You know your project health at any point in time. You know if you are slipping the schedule, if project cost is increasing, if too many changes are being made, or if too many defects are being discovered. If you can’t answer these questions you aren’t on top of your project.

Prioritize and balance dynamically

Finally a note about traditional, static project planning. Project plans are out of date before the ink is dry. Make sure that your project management process and your tools take this into account. Whatever tool you are using, it needs to generate the supporting project artifacts for you — not the other way around. In other words, if you find yourself wondering “how can I keep this Microsoft Project file in-sync with the project,” you’re looking at the wrong end of the equation. Instead, your project tools should be constantly in-sync with the actual state of the project — and if you’re favorite view of the project happens to be a Gantt chart, then your project tool should spit out an accurate one at the click of a button. Let the computer do the number crunching and formatting. You need to concentrate on managing the project, the people, and the global organization challenges that your team faces on a daily basis.

Creating a truly collaborative, communicating team cannot be accomplished with tools alone. While the tips I’ve offered above are sure to help, they won’t address all of the challenges a global project team faces — but they will give you a starting point.

Tackling the global project problem

Launching a global project presents many problems that are completely foreign to most project leaders and managers. The global community offers an incredibly diverse landscape of culture, language, social interaction, and business preconceptions. In most situations this varying landscape leads to conflict or, at the very least, misunderstandings and miscommunication.

Each project reveals something new, sometimes subtle, sometimes much more obvious. While writing Outsourcing in the BRIC: Being successful in global projects with Brazil, Russia, India and China, understanding each situation and turning it into a tangible, applicable lesson was often a complicated exercise.

In this article, the first of several, I’ll present a few of the lessons learned — not necessarily the most prevalent or the most important, but lessons that I think most teams will run into pretty quickly and could derail you from the start.

Face up to communication problems

By far the most common, most glaring misstep U.S. employers make in foreign markets is to assume that people, by and large, aren’t that much different. It’s a mistake I’ve seen in almost every situation, whether the global team is Russian, Indian, Asian, or South American.

In the U.S. we have become very insular, expecting behavior from our workforce that simply doesn’t exist in other cultures. For example, we take for granted that employees will be outspoken and even downright vocal about anything they aren’t happy with. “The squeaky wheel gets the oil,” as the saying goes. But as it turns out, that saying doesn’t apply to many cultures. In fact, the global project manager needs to recognize that in some cultures, speaking out is not to be expected, in any setting. This has come up with almost every outsourcing effort I’ve managed throughout Asia: People will contribute extensively or not at all, depending on the culture.

One strategy to begin overcoming this problem is to initiate collaboration up-front. This can be a particularly effective tool for establishing peer relationships early in the game. While speaking out is not a given, it’s almost universally true that people open up to their peers before opening up to managers. Initiate your project with a two-day collaborative session to drive interactivity. Be sure to stage the session appropriately. It has to be at one location, the entire team should be present, and the environment should be tailored to create effective, collaborative conversations. Remember, it’s more about building the team than about making real progress on the project.

Be sure to continue facilitating collaboration once the exercise is over. If you don’t work to break down barriers constantly, they’ll crop up again — probably the day after your exercise ends. Make sure the team has the right tools to establish effective communication. Try to arrange team schedules that facilitate frequent communication. Develop an on-going staff rotation plan to make sure the team is constantly getting “refreshed,” and working together on a regular basis.

Beware differences in business fundamentals

Just as varied as individuals are the business environments. Consider, for example, the complexity of developing a product in a foreign market, with most of the team speaking a foreign language, with common business knowledge rooted in a foreign business environment. Many of the assumptions that we take for granted are simply missing, or interpreted differently in other countries.

Often a good starting point is to look for regulatory and risk management profiles that will identify potential differences of understanding. Compliance requirements are often taken for granted in one market and completely missing in another (think of COPPA, the Children’s Online Privacy Protection Act, a U.S. law that dictates certain standards for any system storing information related to a minor). Many such standards, laws, and policies exist and are well documented — particularly in Western nations — but are never explicitly communicated to foreign teams where such laws do not exist.

Another common problem: People who understand the technical aspects of a project, but not the application of the product itself, often work “blind” to project quality goals. For example, I once worked with a client developing a legal work product in the United States, but most of the work was performed in India. None of the Indian team members had a solid business or legal background, and even if they had, it would have been based on Indian business law. As a result, most of the team had only a vague idea of what the product would be used for, and none of them understand the target customer.

Be ready to reset perceptions

Depending on your market, your product, and your overall goals, don’t be surprised if there are a few false starts. Engaging a global partner is not something that will succeed or fail in less than 90 days. Having a short-term perspective and focusing on the tactical, rather than the strategic, will doom the effort to failure. Because of the multitude of barriers — from culture, to language, to geography — expect to take time to develop a lasting, successful relationship.

Likewise, when developing a product in the global marketplace, don’t be surprised if it’s necessary to restart the project once your client or partner really begins to articulate what they need. If the project was initiated in the U.S., its inception was probably isolated, initially developed in a silo. Assumptions regarding foreign markets, realistic business objectives, and misconceptions about global performance are likely to be re-examined.

Monitoring a global project is clearly much more complicated than a domestic project or one that runs entirely out of a single building. Make sure the right key performance indicators are being measured, and stay on top of them. Keep a careful eye on communication throughout it all. Once the gaps have been closed and a collaborative environment built, successful, frequent communication will drive creativity and results from foreign markets — while failing to have good communication will create isolated, poorly performing teams. Even though you operate as a global business, try to remember what it felt like when everyone was in the same building, and keep that feeling alive as much as possible.

Is Scrum Master Certification Hurting Our Industry?

Having created a methodology that tightly integrates Scrum concepts, I tend to be a strong proponent of Scrum. But being a strong proponent doesn’t extend so far as to promote all the hype — I’m also a very strong believer in the value of formal education and the need for experience. After seeing the negative consequences of Scrum Master Certification, I’m hard pressed to see any benefits to it.

I’m not challenging the value of Scrum as a practice. I’m challenging the value of Scrum Master Certification. In fact, I’ll go so far as to suggest the certification program is hurting our industry by attributing competency where there often is none.

For example, the Scrum Alliance web site proclaims that Scrum gives you the tools you need to “manage complex projects.” This week I met someone that just joined an established technology company. She’s well spoken, bright, and just got her Scrum Master Certificate. She also just graduated college — and with both of those glowing credentials in-hand, landed her first job: As a Project Manager.

She has no experience. Yet, her employer has hired her to manage a group of people, executing a technical project, largely on the basis that her Scrum Master certification gives her that qualification.

What’s the value in a certification program if it inaccurately represents the capability of the people it certifies? Most Scrum Master certificates are earned after attending a two day seminar, sometimes with interactive exercises. There is no examination, although there is an “assessment” of about 25 questions — but without a pass-fail score, you get certified regardless of how poorly you do. There is no review of relevant experience. There are no requirements of past performance. You can get a Scrum Master Certificate without relevant professional experience or training.

Let’s compare this program with PMI’s PMP certification process. The PMP requires at least — even for an experienced project manager — years of experience and education, and weeks, if not months, of preparation:

  1. The application requires detailed validation of years of project management experience, and even more experience and exposure to relevant work.
  2. While PMI doesn’t audit every student they do audit, and experience must be vetted and verified.
  3. The examination is 200 questions and typically requires weeks of study (most PMP preparatory courses are 13 weeks in duration, as an average).
  4. The examination is administered in a secure environment, with no supporting materials. If you don’t know it, you won’t pass.

Even more stringent requirements exist for PMI’s Program Management credential: Included in the vetting process is a 360 degree review by 12 of your peers. As with the PMP certification process, if you fail any one part, you don’t get certified.

PMI requires that certified practitioners maintain their credentials with ongoing education annually. If you don’t demonstrate an effort to stay current, you lose your credential.

All of this earns you the right to put “PMP” (or “PgMP”) after your name. But if you don’t have the past experience (or if that’s too much trouble), you can drop in on a local Scrum Master course and walk out certified tomorrow. But certified to do what?

Scrum is not a project management methodology. It’s a process control structure that only works when combined with a methodology, such as PMP. It says so right on the first page of Ken Schwaber’s Scrum textbook. In that context, Scrum shines because it brings efficiency to a potentially bulky project management methodology. Scrum can be wonderfully useful, when used right.

So, here I sit, inwardly aghast as I meet Ms. Project Manager, with her freshly minted college degree, a Scrum Master Certificate, and no experience to her name, and I wonder: Is the Scrum Master certification program misleading an already beleaguered industry? According to KPMG and Standish, our success rate over the past 10 years was only 30%. Maybe this is part of the reason.

Does a two-day seminar and mandatory certification in a professional-sounding credential hurt, more than it helps?

Taking a seminar on Scrum is definitely a useful exercise. I think the Scrum Alliance needs to stop misrepresenting what Scrum certification really means to its practitioners, and the business world at large. I’d like to see Scrum professionals coming out of the seminar saying, “Wow! I sure learned what a long way I have to go before I’m ready to manage a project on my own!”