Tag: Communication

A Question of Credibility: Why are Project Managers Afraid to Stop Projects?

Written by Steven Starke on February 22, 2012. Posted in Articles. 4 Comments on A Question of Credibility: Why are Project Managers Afraid to Stop Projects?

In a recent study, the Accept Corporation and the Association for International Product Marketing and Management (AIPMM) found that more than 60% of executives say they struggle making kill/go decisions.[1] For some reason there is a tendency to continue projects and activities even when most people involved realize it’s not an optimal use of their time. Organizations generate a cultural momentum that, like a battleship, won’t turn easily or quickly even when the product team is aware of the issues. What causes this culture to develop? Are poorly aligned project incentives causing a proliferation of this behavior?

Let’s look at some additional data to help shed light on this issue. In another recent study, The Study of Product Team Performance, 2012, [2] Actuation Consulting and Enterprise Agility found that:

Only 33% of product teams have daily priorities that are “strongly aligned” with the organization’s business strategies
Only 12% of respondents report on-time, on-scope, on-budget performance
Only 28% of respondents report “hit or miss” or “miss more than we hit” performance

This study also discovered that critical gaps exist in many organizations. These organizations lacked elements such as a multi-year product strategy and product portfolio management.

From these findings, one could infer that most product development teams are working on projects that are not strongly aligned with their organizational strategy and have a strong likelihood to miss expectations. Can part of the reason be that teams are working hard to deliver projects but do not truly understand the nature of those expectations?

So often, after being assigned to a project, project managers try to run before they walk. This is especially common when the project is already in progress. You can quickly get caught up in the momentum of work and forget to question whether the work is justified. If this is truly the case, shouldn’t more projects be stopped? Aren’t project managers in the best position to go against this grain and make the recommendation to stop a project even when it’s not the most popular decision? Maybe the question should be: Would a project manager be afraid to stop a bad project even if it was the “right” thing to do but it meant losing his/her job?

What About the Project Management Code of Ethics?

It’s well documented that otherwise ethical individuals can be enticed to “bend the rules” because of poorly structured incentives. We’ve all probably seen some form of this behavior playing out in our organizations and product development projects. Whether it’s the business unit head who pushes an inadequately prepared team to reach a project go-live date in the interest of receiving a very large bonus, or a product manager trying to meet a roadmap item date but only delivering 50% of the customer’s requirements because incentives were linked to the delivery date and not the scope. Most of the time, this behavior is not meant to be malicious, but let’s face it, poorly aligned priorities linked to financial rewards can encourage individualist behavior in even the most ethical person. I honestly don’t think project managers are any more or less susceptible than any other profession to this type of behavior.

However, as a credentialed project manager, our behavioral conduct is governed by our Code of Ethics and Professional Conduct. Our code should provide us the clarity and direction we need when situations get confusing or conflicted — and projects need to be stopped. Let’s look deeper into our project management code for guidance.

Chapter four, Fairness, specifically states the following: “Fairness is our duty to make decisions and act impartially and objectively. Our conduct must be free from competing self interest, prejudice, and favoritism.

4.2.2 We constantly reexamine our impartiality and objectivity, taking corrective action as appropriate.

Comment: Research with practitioners indicated that the subject of conflicts of interest is one of the most challenging faced by our profession. One of the biggest problems practitioners report is not recognizing when we have conflicted loyalties and recognizing when we’re inadvertently placing ourselves or others in a conflict-of-interest situation. We as practitioners must proactively search for potential conflicts and help each other by highlighting each other’s potential conflicts of interest and insisting that they be resolved.[3]

And Chapter five, Honesty, states that:

“5.2.3 We provide accurate information in a timely manner.

Comment: An implication of these provisions is that we take appropriate steps to ensure that the information we’re basing our decisions upon or providing to others is accurate, reliable, and timely. This includes having the courage to share bad news even when it may be poorly received. Also, when outcomes are negative, we avoid burying information or shifting blame to others. When outcomes are positive, we avoid taking credit for the achievements of others. These provisions reinforce our commitment to be both honest and responsible.[4]

One could argue that our code doesn’t explicitly say “stop a project when it is bad” or that in certain cases the code is too aspirational — a topic for another day. But clearly it’s in our code of ethics that we, as project managers, need to make these tough recommendations to our stakeholders. So, why aren’t more projects being stopped?

What criteria do project managers use to determine if the project is off the rails with no sign of recovery? What happens if the project delivery is sound but the overall product strategy is flawed? Is it the job of the project manager to stop the organization from making this investment mistake even if he or she can deliver the project on time, scope, and budget?

If the reason that the project is “bad” can be attributed to tangible areas where the project will not meet stakeholder requirements (e.g., cost, time, scope), then it is the responsibility of the project manager to alert the sponsors so that the scope/requirements can be changed or the project cancelled. This, in fact, is one of the reasons you’re hired into the role of project manager.

However, in the case of a sub-optimal product strategy, some may interpret our loyalty mentioned in our code of ethics as loyalty to the project and the project charter, not necessarily to the common good of the organization. Some might argue that a great strategy executed poorly will almost certainly lead to failure; whereas a poor strategy, executed properly will likely have some measure of success. Once a project has been commissioned, the project manager’s focus is to execute according to the project charter. Presumably the sponsors (organizational management) are aware of strategic alternatives and, for better or worse, have chosen the project you’re working on. The current mantra is to accept this charter and execute it to the best of your ability.

As a project manager, you should be brutally honest when the viability of a project is in question, even if the concerns are regarding the product strategy. The reasons for this are important. For example, if the project no longer aligns with the strategic objectives of the organization, continuation will lead to wasted financial and human resources thereby undermining the organization’s credibility in the market. In this case, look for alternatives that could leverage the investment already made and provide value through a different, better-aligned project initiative.

So How Do You Define Success?

When creating, developing, and delivering a product to the market, we seek to maximize its value. In product development projects, the project manager typically collaborates with the product manager to construct detailed statements (success criteria) that are clear and measurable, focused around the areas of scope, schedule, and cost. Then, during the course of the project, the project manager forces the product manager to make decisions and tradeoffs against the three, but based on what? Does the product manager really understand what they’re being asked to trade-off against? The answer should be value.

Project Managers need to adjust their perspective around scope, schedule, and cost and relate it back to what the overall value is of the project. When you make this adjustment you realize that the balance of scope, schedule, and cost is more of an equation based on deriving value. I call this the project management value equation. It’s designed to give context to “scope, schedule, and cost,” ensuring that you’re weighing all that you do against the overall value of the project and keeping your product manager and product team focused on the prize. Said another way, it’s an equation meant to quantify and assess the value of a project and identify — if value has been decreased — whether the project should be stopped. The equation is (working model identified in book):

Value = Scope ÷ (Schedule + Cost)

By understanding this concept, you bring more depth and meaning to what you really need your product manager to trade off against. By assigning a value to each of your success criterion, you in essence are quantifying the value of the project. Remember, good project managers know that project success is not whether it’s delivered on time and within budget, but whether it delivers value and meets the defined success criteria.

Our project success criteria should then be evaluated using our code of ethics. Ask yourself, “are the intentions of the project feasible and ethical?” “Am I willing to act in an ethical way, to complete the project — even if completion means stopping it?” It’s likely that the project sponsor views this recommendation as a personal attack and the result turns out to be a career-ending move. In a tough economy, stopping a project becomes an extremely difficult decision. However, I still hold the position that, based on our code of ethics, the answer to the question…should a project manager stop a project even if it means losing their job…should be YES! When managing a product development project, our Code of Ethics is the backbone to our credibility — and sacrificing our credibility should never be an option.

Don’t forget to leave your comments below.

[1] Accept Corporation and Association of International Product Marketing and Management (AIPMM). PPM is Dead. Long Live Portfolio: Q2-2011 Study – Portfolio Management Priorities. June, 2011. Retrieved from accept360.com.

[2] The Study of Product Team Performance, 2012, Actuation Consulting and Enterprise Agility, March 2012

About the Author:

Steven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Thomson Reuters and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development.

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.

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.

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

Tangoing Your Way Through the Executive/PMO Relationship

Written by Curt Finch on February 6, 2012. Posted in Articles. 7 Comments on Tangoing Your Way Through the Executive/PMO Relationship

“It takes two to tango.” This idiomatic expression, which originated in a 1952 song by Pearl Bailey and was later popularized in 1982 when President Ronald Reagan quipped about Russian-American relations, is an accurate description of the relationship between a project management office (PMO) and an executive. At the end of the day, success for either of them is dependent on the other. Executives depend on the work accomplished by project management offices for their own success, just as project management offices depend on executives for their success.
In a provocative 1999 article in Fortune magazine that addresses why executives fail, the authors get directly to the point and state that the number one reason for executive failure is “bad execution…as simple as that…not getting things done…not delivering on commitments.” The article also states that executives who do not deliver are three times more likely to get fired than their counterparts who are delivering. Think about it. What is the dominant purpose of a project? Getting things done! Projects deliver products and services, and they do so according to a schedule. Projects deliver on commitments. Executives need projects so they can deliver on commitments, thus avoiding the number one reason for executive failure.

The opposite is equally true. Projects need executives. The scope of projects and the judgments made about their success have expanded over recent years to the point where project success is almost always beyond the sole control of those running the project. Project success is highly dependent on the availability of resources typically not under the direct control of the project manager. Similarly, the project manager does not have direct control over the networks and systems that their project must fit into. Really, the project manager doesn’t have direct control over much of anything upon which the project’s success depends. The days of the small, relatively simple, stand-alone project are mostly over. These dependencies, which are essential for the success of the project, are less often in the domain of the project manager and more often in the domain of the executive. The project manager must establish a PMO that is run with a direct two-way supportive relationship with the executive.

A Real Story
To illustrate just how pronounced the dependence between executives and project management offices is, and needs to be, let’s consider the following story. This story illustrates just how effective a strong co-dependent relationship can be. Prior to the creation of the PMO with a co-dependent executive relationship, trouble was the norm. After the creation of the PMO with a co-dependent relationship, the situation improved. The story is associated with responsibilities that the co-author of this article, Michael O’Brochta, had when he worked as an employee of the Central Intelligence Agency (CIA). He spent decades there managing hundreds of projects, managing project managers, and leading efforts to advance project management within the organization. The story begins with a strategic need within the organization and an executive who recognized this need and made a commitment to take action. Note that this is not a unique story. In a 2009 book by Brian Hobbs, PhD, PMP, titled “The Project Management Office (PMO): A Quest for Understanding,” he highlights a global study of project management offices and describes the PMO best practice of tailoring the PMO function to match the needs of the executive, just as happens in this CIA story.

“I don’t understand it; I have staffed my new organization with hundreds of highly-skilled project managers, yet even after our first year in business, we can’t seem to deliver enough projects on time or to the satisfaction of our customers.”

These were the words that O’Brochta first heard when the director of the organization asked for help. He went on to describe the gap between his vision for his organization and the current reality: “I’m confident that running this organization as project-based is the way to go, but I never thought it would be this hard,” said the director. “I periodically review project schedules, and find them to be ever changing. No one is happy about a moving target — not me, and least of all, not the customer. Quite frankly, I do not see why anyone would come to my organization if they had a decent alternative.”

The project-based organization described here was formed to advance the mission of the CIA. The best engineers, the best information technology professionals, and the best project managers were combined into a single organization focused on delivering new and better intelligence analysis systems and capabilities. One of those systems, named Fluent, was described a decade ago in a Reuters article titled “CIA Using Data Mining Technology to Find Nuggets.” This was cutting-edge technology focused on critical CIA mission needs at the time.

Finally, the director got to the point of the conversation: “Will you come and help?”

During the following year, O’Brochta built and ran a strategic-level Project Management Office. Although the published knowledge associated with successful project management offices was rather limited at the time, enough was known for him to select a couple of starting points. O’Brochta started with one initiative focused on the project managers and one initiative focused on the executives. For the project managers, he led the building of a standardized project life-cycle methodology complete with milestones and documentation tailored specifically for the nature of their work. For the executives, he led the building of a standardized governance system complete with reviews, decision-making criteria, and change management strategies tailored specifically for their work.

Previously, the role and actions of the executives and the project managers were out of sync. Project managers were doing their best to draw upon their extensive backgrounds to create and follow project plans, but no two were the same. Likewise, executives were doing their best to support the project managers with resources and decisions, but inconsistency and unpredictability were common.

O’Brochta routinely met with executives and others in the management chain to ensure that decisions about the PMO’s focus matched its needs; he did the same with project managers and the various PMOs. Both the executives and project managers learned that each group performed equally important, but different, roles. The executive’s role included supplying a standardized project life-cycle methodology for the project managers to use and holding them accountable for using it. The project managers’ role included tailoring the provided life cycle methodology and putting it into practice. The executives established and followed a routine for project reviews and associated decisions. The project managers prepared for each of the project reviews with the information needed to support the scheduled decision-making. Predictability and consistency became the norm. Effort that had been directed toward “figuring out what to do” was now directed toward more productive activities associated with running the projects and meeting mission needs.

Initial Reaction
Because of the success of the initatives, the value of the project management office was established. Other initiatives followed, all targeted at the co-dependent relationship between the executives and the project management offices. These initiatives included training for both the project managers and the executives. They reflected the maturing of project management within the organization and the value of strengthening the co-dependent relationship between executives and project management offices. It was learned that this relationship is, in and of itself, a project that can be planned and managed within a PMO for the strategic long-term benefit of the organization.

What’s Next?
As satisfying as it might be to establish a successful PMO, the question arises about how to keep them going. This is a serious question. It appears that keeping a PMO going is not so common. A 2007 PMI-sponsored report titled “The Multi-Project PMO: A Global Analysis of the Current State of Practice” states that PMOs are frequently closed or restructured with only about half of them surviving for two years. That’s a grim statistic. Executives need projects, project management, and PMOs. Yet, the PMO often struggles to survive. Why? According to the same study, the successful PMOs were the ones that responded to and adapted to the ever-changing needs of the organization. In other words, the successful PMO’s performance was matched to the needs of the organization. Key performance indicators were established and achieved. And not just any key performance indicators were achieved, but ones that were relevant and meaningful to the executives with whom the PMO had a co-dependent relationship.

Coming up in Part 2: Specific key performance indicators that a newly-established PMO can use to measure itself to ensure alignment with the needs of the organization.

Don’t forget to leave your comments below.

Michael O’Brochta,PMP, has been a project manager for over thirty years. He is an experienced line manager, author, lecturer, trainer, and consultant. He holds a master’s degree in project management, a bachelor’s degree in electrical engineering, and is certified as a PMP®. As Zozer Inc. President, he is helping organizations raise their level of project management performance. As senior project manager in the CIA, he lead the maturing of the project management practices agency-wide. Since his recent climb of another of the world’s seven summits, he has been exploring the relationship between project management and mountain climbing. Mr. O’Brochta’s papers and presentations at PMI national, international, and regional conferences have consistently been popular and well received; his last three PMI Global Congress presentations have drawn the largest audiences at those events.

Curt Finch is the CEO of Journyx. Founded in 1996, Journyx automates payroll, billing and cost accounting while easing management of employee time and expenses, and provides confidence that all resources are utilized correctly and completely. Curt earned a Bachelor of Science degree in Computer Science from Virginia Tech. As a software programmer fixing bugs for IBM in the early ‘90’s, Curt found that tracking the time it took to fix each bug revealed the per-bug profitability. Curt knew that this concept of using time-tracking data to determine project profitability was a winning idea and something that companies were not doing – yet… Curt created the world’s first web-based timesheet application and the foundation for the current Journyx product offerings in 1997.

Facilitation Top 5

Written by Andrea Brockmeier on February 6, 2012. Posted in Articles. 9 Comments on Facilitation Top 5

As any instructor will tell you, one of the best things about teaching is learning from your students. It happens in some way, big or small, every time you get in front of people who are expecting to hear how to do it “right.”

Of course, there is no “right” a lot of the time. In my classes, for example, I instruct and inform, but I also facilitate discussions about the options, and the students decide what’s going to work for them.
This brings me to the recent Facilitation Skills Workshop class I taught. In this class, we learn about different facilitation techniques and then the students do the work; they actually facilitate each of the 12 sessions throughout the class.

Maybe you are like many of the students in this class who are terrified of speaking in front of groups. Their hands shake, they sweat, and some have a hard time breathing. This fear is not unlike other fears and there is often a visceral response.

It is amazing to watch those folks who are terrified of facilitating get up in front of a group and, with some preparation, tools, and guidance, actually help the group accomplish a goal. It is enormously validating- for them, the participants, and me.

The last session of the 12 sessions is one in which the facilitator brings the class to consensus on the top 5 characteristics of a good facilitator. My last class came up with the following Top 5 Characteristics of a Good Facilitator:

1. Neutrality
The facilitator cares that the group achieves their goal in the session, but they don’t care what the results look like specifically.

2. Preparedness
A facilitator needs to be prepared for their session. Facilitation might look easy, but it is hard work. Taking time to understand the group and issues, as well as practice the skills and techniques to be used make for a far more effective facilitator and one who will be much more likely to help the group achieve its goals.

3. Energetic
A facilitator needs to be neutral, but that doesn’t mean they should be comatose. Bringing some energy to the session helps keep people focused and engaged.

4. Clear idea of Purpose/Agenda
A good facilitator needs to start with a clear understanding of the goal of the session and the tools they might use to achieve that goal. In short, be flexible, but have a plan.

5. Positive
An effective facilitator makes the participants want to achieve the session objective. Even if it’s addressing a problem, a positive tone will encourage participants to own their part of the outcome.

It wasn’t necessarily the list I would have come up with, although those are certainly things we talk about in the class. As I sat in the back of the room watching them come to this conclusion together as a group, facilitated by one of the students, it was an interesting and, in some way, a teachable moment for me.

Don’t forget to leave your comments below.

Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning. Andrea is a PMP® as well as Certified ScrumMaster. She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP^® certification, as well as influencing skills. She has long been involved with the PMI^® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

How Do We Market & Promote a Project to Ensure Success?

Written by Lisa Anderson on February 1, 2012. Posted in Articles. 4 Comments on How Do We Market & Promote a Project to Ensure Success?

As important as project teams, project tasks, and critical milestones are to project success, they do not compare to the importance of marketing. To succeed in today’s new normal business environment where sales are lackluster, cash is tight, resources are scarce and customer service expectations are high, project execution is no longer enough; instead, you must also be an expert at marketing your project to ensure it gains the right amount of attention and traction to accelerate project results!
The challenge is that project managers aren’t typically skilled marketers. We can block and tackle with the best of project leaders; however, when it comes to marketing and promotion, we pale in comparison. In my 20+ years of experience in working with project teams across a multitude of industries, geographies and project scopes, I’ve found a few simple marketing tactics to make a significant difference: 1) Communicate the value. 2) Use multi-media. 3) Word of mouth.

1. Communicate the value: Undoubtedly, the #1 key to success in marketing your project is to communicate the project’s value. How does it provide value to the company? Does it tie in with the company strategy? Will it free up cash flow? Improve service levels? Increase profitability? Have you updated your project team? Your boss? Your mentor? Any leaders who might be impacted by the project? I’ve found that there is no quicker way to ensure the speed of progress than to continually communicate the value to each person affected or impacted along the critical path – and preferably each person’s manager as well.

For example, in an ERP implementation, we had to rally the troops around the implementation of a piece of functionality. This critical path step would affect the shipping and receiving function in a way that would increase the workload temporarily. The only way we gained enough commitment to increase workload with an already short-staffed and overworked team was by not only communicating the project’s long term value to the logistics team members (and their contribution to it) but also by communicating the team’s impact to the project success to the manager responsible for the increased workload. The key was that the critical milestone was no longer a project team success; it was a combined logistics and project team success.

2. Use multi-media: Communicating the value once is not enough. However, even communicating it 10 times isn’t enough. In order to break through the barriers so that all related parties and company leaders understand the value of the project (and would be willing to support the project even when it becomes inconvenient), it is vital to communicate via multi-media. It’s much easier to ignore a simple conversation than it is to ignore multi-media.

There are countless ways to promote your project leveraging multi-media. First, utilize the company’s newsletter and promote your project – why will it add value, who is on the team, what accomplishments have been achieved, etc. If you do not have a newsletter, create one. I’ve yet to see a tasteful newsletter turned down by business leaders as it helps to rally the teams. And who wouldn’t like to read about their achievements in the news? Next, leverage the intranet. Create a section for the project. Utilize social media. How about a brown bag lunch session to talk about the project and ask for input?

3. Word of mouth: I’ve found that there is nothing more powerful than the word of mouth. Simple yet extremely effective. Create a buzz about your project. Soon you’ll have folks asking how they can help the team!

How do we create a word of mouth? Start talking about the project. Ask the project team to talk about the project. If each person finds 1 or 2 target people to communicate with about the project and its value, it will spread quickly. Make sure to include at least a few executives and leaders. Ask each of these folks if they would share a highlight with their team or someone with a related interest in the project or its results. Ask them for feedback. There is nothing more powerful than referrals. Soon, your project will be in the limelight. Remember, make it interesting, show enthusiasm and appreciate their ideas and feedback. The rest will follow.

The power of marketing is immense. Do you think it will be easier and quicker to ensure project success if just the project team is committed or if you’ve involved and engaged not only the project team but their key influencers and colleagues?

Don’t forget to leave your comments below.