———–

Summary: If you can identify the one or two things you’ve been trying to avoid, such as a particular difficult conversation you know you need to have, and do that today, you will become more valuable than you are today, even if you’re using all the latest time management and process optimization tools. Effectively confronting the “elephant in the room” once a day, or even once a week, will make you indispensible to your client and team.

———–

Recently I have been doing some thinking about simplifying. I’ve been cleaning out a couple years’ of checklists, notepads, emails, and clutter. It’s been a helpful process, and I have been thinking about where else I can apply it, beyond my cubicle, my truck, and my basement. In this context, I remembered this bit of wisdom (I forget where I heard it) and think it has some merit with regards to project management: if you can just identify the one or two things you’re trying to avoid, such as a particular difficult conversation you know you need to have, and do that today, you will become more valuable than you are today, even if you’re using all the latest time management and process optimization tools. Simple, right?

When I look at project management in general and the management of risk in particular, I think that this principle is especially useful. Often we know where the risk lies in our projects. We can more or less identify, even if we don’t know how to deal with, the “elephant in the room”. As project leaders we have seen many of the same challenges before. But the same types of challenges do come up again and again across multiple projects, clients, companies (managing change, managing risk, managing conflicting personalities, just to name a few). Sometimes they cripple our projects, even though “we could see it coming”.

Here’s my proposition: if you can find a way to deal effectively with the “elephant in the room” once a day, or even once a week, this will contribute greatly to your project success and make you indispensible to your client and team. It’s easy to hide in issue logs, risk assessments, action item lists, and all the latest tools and processes. It’s not easy to confront head on the one thing that you realize as crucial but are uncomfortable putting squarely on the table for resolution.

That brings me to “difficult conversations”.  Why are they difficult? Why do we procrastinate having them? In what ways might our life or our project be better if we could find a way to have them sooner? How could we make this a reality?

Why are “difficult conversations” difficult, and why do we procrastinate having them?

At the risk of stating the obvious, we have to say things that are uncomfortable for our clients / team members / stakeholders / etc to hear. That in turn makes us uncomfortable. Maybe your client’s decision (or decision making process) is the issue. Maybe you believe your boss is making a mistake, but are afraid to tell her. Maybe a team member is performing poorly. Our culture in some way teaches us to sugar-coat the truth, to avoid possible offense at all costs, to save face and live to fight another day.

Sometimes we procrastinate because we don’t have the answer completely worked out in our own mind. This can be a dangerous spot to linger for too long; it’s actually a bit arrogant to think that we have to be able to solve every issue on our own before talking about it. If we are to be our best as a team, we have to be willing to be a bit vulnerable and reach out for help.

In what ways might our life or our project be better if we would have the one most important “difficult conversation” today?

Often the most uncomfortable part of difficult conversations is the anticipation. So, for starters, if we had the conversation sooner we would have a decreased duration of painful anticipation, regardless of outcome. This alone would be a logical reason to get on with it and confront the issue.

More importantly, the key principles of risk management apply. Identifying and dealing with issues or risks sooner is much less costly, by several measures, than waiting. Waiting gives the issue longer to go down the wrong path. Waiting allows good effort to be wasted, allows precious time to elapse without a solution, and often allows a project to move from definition (where a solution would be a change on paper) to development (where a solution would involve throwing away expensive code and creating new, also expensive code). Solving the big issues sooner has a real, financial benefit to our projects.

How can I stop procrastinating and do the right thing today?

1. Right now, write down the names of one or two critical topics you are avoiding, that you know need resolution. Don’t try to identify or solve every open issue right now; just identify the top one or two.
2. Think about why you are avoiding these topics. Today, write down the key reasons so you see them. Seeing the reasons in writing might help you overcome them.
3. Imagine the likely result of doing nothing. Can you state or even guess an impact?
4. If the impact of doing nothing is likely to be worse than your reasons for procrastination, schedule a conversation. Could be a formal meeting with a deck; could be a short phone call, in-person conversation over coffee, whatever. Often a one-to-one conversation is the best place to start.
5. Acknowledge at the outset of your meeting that this conversation is difficult for you, and why. This should take some of the tension out of the conversation, and may actually help you to collaborate in finding an answer. It will keep a human element at the forefront, and help the other party realize that you care enough to do something that’s uncomfortable for you. Also be willing to acknowledge that you may not know the full answer, but that it is important to recognize the issue and work to an answer together.

The bottom line? You likely know the one issue or risk that your project is facing and that is most important to deal with. If you just do one thing today, take the next step to deal with this issue. Despite some discomfort, it will make you an indispensible project leader.

This is the second of a two-part series that discusses how creative thinking and problem solving can impact the way projects are managed.  Part one examined the project delivery process.  We will now continue the discussion by exploring the ways we can change our behavior for the better within the existing processes we already use each day.

2. How can project managers work the principles of a creative thinking process into our roles?

All day every day we are called on to solve problems. We have status meetings to identify issues. We have status reports and issue logs to document issues. We have client calls to discuss and resolve issues. We have escalation processes to remind us that we occasionally let an issue get out of control and need help to rein it in.

But what if there is a better way to think about the issues themselves? What if, in addition to tracking issues and talking through resolutions, there are some ways we can better think through solutions to our clients’ problems, both the stated ones and the unstated ones? Here are a few ideas that I found most useful, valuable, and relevant to my life as a project manager. I hope I can remember to put them into practice.

-          When trying to solve ANY problem or challenge, ask open ended questions, and ask your team for as many answers as they can imagine. What are open ended questions? In short, they are not “yes or no” questions. They are questions that start with phrases like, “How might we…?”, “What are all the ways in which we could…?”, “What would it look like to you if we were to…?” Use these questions in many contexts:  while gathering requirements or defining scope-critical decisions; when you’re up against the triple constraint and need a way out; when none of the obvious answers work; when your client or your team isn’t cooperating with the way you think things should be unfolding; and when you can’t imagine by yourself what to do. I’ve been surprised how this single approach has given some brilliant and unexpected results in the weeks since I took the training.

-          Use the PPCO format (Praise, Potential, Concerns, Overcome). It might be just a fancier version of sandwiching bad news between good thoughts on both ends, but I’ve watched it work and gotten really positive client feedback when I’ve used it. The idea is pretty simple. When responding to an idea or a question, use a specific order and format for your response. First, praise the idea. Say something good about it. This is a bit disarming. Second, identify the potential benefits of the idea, when implemented well. This follows up the praise with some specific thoughts showing you’ve considered the idea in detail. Third, identify some concerns that may be relevant. Use open ended questions to express the concerns. Instead of saying, “My concern is we’d never be able to do it in time for launch” say something like, “In what ways might we be able to implement this feature and still meet aggressive timelines for first phase launch?” or “What are the tradeoffs that might allow us to implement this feature now?” Lastly, be ready with some suggestions to overcome the concerns. Brainstorm the ideas with your team. Ask them for the answers that occur to them if you can’t think of them, or even if you think you’ve already thought of all the good solutions.  Present these possible solutions back to the client along with the concerns you identify.

-          Get comfortable with disagreement or opposing points of view. Learn to put all viewpoints in a context and build a picture that you, your team or your client can use to make a better decision. Don’t assume you have the right answer from the start, even if you think you do. Be willing to let your thinking be challenged. Be willing to acknowledge an opposing view. The PPCO (Praise, Potential, Concerns, Overcome) framework can be a great way to practically frame opposing viewpoints.

-          Allow those around you to see (visually) the thinking process you’re going through. Help them to see visually how their words and ideas are shaping and influencing that process. This can be as simple as projecting in real time the notes you’re taking on your laptop, or writing key comments down on Post-it Notes and putting them on the wall in the place you’re meeting. It might involve attributing the good ideas that are captured in your meeting minutes. Letting the team and the client see their thoughts impacting the outcomes of a meeting will go a long way toward having them buy in to the eventual recommendation or solution.

-          Continually question whether you are solving the right problem. Often as project managers we get locked in on answering the question we are asked, without taking enough time to consider if we are answering the right question. “How fast can you add this feature?” “Why did this decision get made a year ago?” “Why does X cost so much?” The list goes on. The client changes, the project changes and the context changes but the questions are always the same. If we can get to a correct problem statement, we will have won at least half the battle. If we can get the […] filled in most accurately, within the following sentence, we’ll be on our way to success… “It would be great if […]”. If we stop to help our team or our client or ourselves ask the right questions, we can be more confident that our efforts are being expended in an effective way. While there are several ways to look at the question to see if it’s the right one, a constant awareness of seeking the right problem statement is a great start.

In summary, the training in creative thinking and problem solving showed me ways in which I can make both major and minor modifications in the way I manage projects. I probably wasn’t the most likely candidate to get this training. It certainly took me outside of my personal comfort zone. We didn’t use an Excel spreadsheet or talk through a project status anywhere in the course. It didn’t directly cover any topics from PMBOK or help me to limit and manage my project’s scope. But it did present some ideas that challenged the way I think about and solve problems, and in the short time I’ve had to try it out, I’ve seen it be effective.

Recently I participated in a training seminar focused on creative thinking, brainstorming and problem solving. I was the only project manager in attendance at the training, along with a full complement of experience design, creative and strategy types. I thought maybe I’d get a couple days of relaxing and lying on a mat in a dimly lit room, listening to new age music and thinking deep thoughts. It turned out to be rather different than that… in a good way.

First, I don’t intend to use this forum to describe the specific creative thinking process itself, since that information is easily transferrable through existing training documents. What I hope to do is describe the impression the training made on me as a project manager, and present a few thoughts on how the principles taught can influence my day-to-day work of delivering projects for clients more effectively.

No crazy ideas allowed

What I found interesting about an intentional “creative problem solving process,” as a project manager, is that it really challenges the way I often behave in my job. I often feel my unstated role is to limit what gets added into a project, make sure the list of activities and deliverables is finite, and make sure that all crazy new ideas are immediately relegated to a Post-it Note in a “project parking lot” in such a way that they are sure to never see the light of day.

For better or worse, we usually do some form of requirements definition at the very beginning of the project, when stakeholders are least sure of what they can even hope for, and don’t fully know what they need. Once those requirements are written down, it’s my job to stick to them—or bury the client in an annoying paper blizzard of change requests. But I can’t believe products such as the iPhone or the light bulb came about through such a rigid linear process of thinking.

So, how can a project manager take full advantage of a creative thinking process and yet not completely throw the realities of scope control and timeline and budget management out the window?

The following post is the first of a two-part series that will discuss how creative thinking and problem solving can impact the way projects are managed.  Part one examines the project delivery process, and will look to answer the question, should my existing project management process change at all as a result of what I’ve learned about an intentional “creative problem solving process”?  In part two of this series, I’ll explore the ways we can change our behavior for the better within the existing processes we already use each day.

1. Should my project management process change at all?

In short, yes. At a bare minimum, we should plan for and budget against a brief internal session (partial day or full day) designed to stretch our thinking about potential solutions to the business problem. This session should occur before the real requirements gathering work starts, in any medium to large project. Beyond this bare minimum, we should aim to do a client version of an intentional “creative problem solving process” as well, also prior to the start of locking in formal project requirements. Usually enough initial data has been gathered in the sales process that there is at least some idea of what the project involves, and this data can provide the initial insight for an internally-facilitated creative thinking session. But too often we jump straight from the sales process into a stodgy set of stakeholder interviews or a “canned” facilitated requirements definition workshop and miss a huge opportunity to understand what the project could be if implemented optimally. Let’s look at one example from the training.

Putting it into practice

The class was asked to look at a color photo of the stairway between floors in an office building, and come up with ideas to improve them. Well, I am guessing that a client-generated RFP for a project to improve the stairway would have listed several standard items like repainting, making a safer and less slippery step surface, and improving the lighting in the stairwell. If I, as the project manager, had taken that level of insight into a requirements gathering session, I could probably quite accurately scope a boring, low-risk, low-reward project.

Once we went through a 15-minute exercise in the training, however, we had about fifty to eighty unique ideas for ways to improve the stairs. Some were a bit outlandish, which is fine and is part of the creative process of stretching our thinking. Some were practical, inexpensive improvements that were unexpected and which probably never would have been considered in a more “normal” requirements definition process.

This exercise made me very uncomfortable for the following reason: if we hadn’t taken the time to think a bit creatively (for well under an hour), we would never have come up with about 90% of the ideas we generated. It both scared and encouraged me to think it might be that easy to improve the pool of potential solutions we bring to our clients. Scared me because I’ve been managing big projects for a long time now, and might have missed out on recommending a whole lot of great ideas… I might have missed an iPhone opportunity somewhere in there. Encouraged me because with a little effort and minimal cost, we can at least make some real improvements in our thinking.

Quality out of Quantity

One of the principles of a good creative thinking process is that quality comes out of quantity, at least in the realm of idea generation. An intentional creative problem solving process gives us a framework to generate a ton of ideas without worrying whether they are good, bad, neutral, crazy, expensive, offensive, or perfect. It strives to get a high quantity of thought onto paper, and gives us a way to bring some informed thinking into the requirements definition process.

Intentionally forcing some unconventional brain activity at the outset might radically alter the expected outcome of the project, but if it happens before requirements are gathered, so what? On one hand we might quadruple the scope of the project; on the other hand, we might decide the project we had in mind isn’t even necessary and there’s a better way to solve the client’s real need.

In any case there is a real possibility – even a likelihood – of discovering something valuable and unexpected, and that’s what our clients will find sets us apart and makes us valuable to them, especially (but not only) in this uncertain economy.

How this fits into a project delivery process

As a practical process matter, the change I would contend is needed is to consistently hold at least an initial / internal version of an intentional creative problem solving process before we ever hit the “record” button in a stakeholder interview or build version one of a client-facing scope document.

I also think the client version of this exercise should come well before the end of the requirements definition process, so that there will be the most openness to building the right scope, timeline and budget expectations at the outset. It takes a lot of work on the client side to overcome organizational inertia and get a project going, and if we force our clients to do all that work twice (once for the project we initially define requirements for, and again for the improved project we creatively imagine), we may have cost them valuable capital or even credibility inside their organization. This is the main process area that struck me as necessary, having gone through the training and considering it from a project manager’s point of view.

I suspect there are additional areas where we could add a valuable level of more detailed change to our project delivery processes, as a result of using the intentional creative problem solving process in the best possible way. This could involve doing small internal workshops at key project milestones, in an effort to identify and problem solve around the key project issues particular to each phase. This type of change, however, may not even need to be built into our formal process.  Stay tuned for part 2 of this post where we will look to answer the question, how can project managers work the principles of a creative thinking process into our roles?

Back in 2004 the Project Management Institute (PMI) went on a quest to understand and quantify the value that project management provides to organizations. At the time, the actual value resulting from investment in project management was hard to define and measure. Studies conducted in the past struggled to provide credible evidence of the value that project management provides to the organizations.

The PMI commissioned the researchers at Athabasca University in Canada, who conducted a 3-year study in order to find unequivocal evidence of the value organizations provide when project management is appropriately implemented. After conducting 447 interviews, reviewing 418 project summaries, and looking at more than 60 case studies from a globally dispersed array of industries, they concluded that project management has the ability to deliver significant value to organizations. Janice Thomas, PhD, and Mark Mullaly, PMP, documented the three years of global fieldwork and cross-disciplinary analysis conducted by the team in their book, Researching the Value of Project Management.

To investigate the value of project management, the researchers adopted the value model that consists of six principal components:

• Satisfaction (degree to which stakeholders are satisfied with the project management implementation, including project manager satisfaction)
• Alignment (the degree to which organizational practices support and are consistent with the need of projects within the organization)
• Consistent Practices (the degree to which the project management practices within the organization are aligned and consistently adhered to)
• Process Outcomes (the degree to which projects deliver specific process improvements in managing projects within the organization)
• Business Outcomes (the degree to which projects deliver improvements in organizational outcomes)
• Benefits Realized (benefits realized from the project management implementation, such as cost savings, revenue increases, customer retention, etc.)

The researchers used these six components to identify and describe the types of value being realized by the organizations participating in the case studies. The following six value types emerged:

1. Aligned project management practices, improved process outcomes, and overall business outcomes. The case study organizations reported significant improvements in overall processes and process capabilities, with high level of value being placed on the role of process in creating transparency and improving project collaboration. These organizations also demonstrated improvements in overall performance, including increases in revenues and the ability to attract new project work based upon previous project success.

2. Good Project Management practices, effective Human Resources and no desire for change. The organizations in this group reported extremely high satisfaction with their project management implementations with the desire to sustain the current level. They placed greater emphasis in their project management implementations on the cultural and human resources aspects of project management that resulted in improved human resource effectiveness, improvements in overall quality of life, and attainment of better work-life balance for their employees.

3. Better project results, aligned organizations and corporate culture. The organizations reported that their project management implementation has had a positive influence on the overall culture and effectiveness of the organization.

4. Good project results, absence of process, lower customer satisfaction. The organizations reported satisfaction with their ability to deliver projects successfully. These organizations also reported absence of process capabilities and lower customer satisfaction than other organizations within the case study.

5. Good Project Management, lack of consistent process, high customer satisfaction. The organizations reported good project results with few consistent process capabilities in place. Their customers reported satisfaction with the projects and services provided.

6. New services, staff retention and growth. The organizations reported increases in value associated with the project management services, including ability to either charge for their project management or increase their revenues associated with project services. They also reported the ability to secure additional projects as a result of improvements in their reputation for delivery or successful delivery of previous projects.

The value observed within the framework of this study was further categorized into two groupings – Tangible (defined as the value that can be measured) and Intangible (defined as the value that is much more difficult to quantify).

The following value was observed within the Tangible category:

• Cost savings
• Revenue increases
• Customer retention
• Increased customer share
• Greater market share
• Reduced write-offs and rework

The delivery of intangible value included the following dimensions:

• Improvements in the decision making
• Enhanced collaboration and communication
• Improvements in effective work cultures
• Alignment of approaches, terminology and values within the organization
• Overall effectiveness of the organization and its management approach
• Improved transparency, clarity of structures, roles and accountability.

In the course of the research, it was discovered that tangible and intangible value is being realized to a different degree by the case-study organizations. First of all, not all organizations participating in the case study reported tangible values. Consulting, construction or engineering firms were more likely to demonstrate tangible values. The researchers found little correlation between tangible values and the level of maturity of the organizations. Even organizations with relatively low levels of maturity were able to achieve high levels of tangible value that involved minimal and superficial project management practices.

On the other hand, most of the organizations reported evidences of intangible value. The level of intangible value being observed does appear to be tied to increasing levels of maturity.

Conclusion: “What clearly emerged from this study is that value appears to increase in proportion to the maturity of the project management implementation that is encountered. Tangible value can be attained at almost any level of maturity, and is primarily a result of the nature of the organization and the delivery of customer projects. The attainment of intangible value requires a base level of capability and a reasonable level of robustness to be established for it to be realized. As well, continued increase in maturity of the project management implementation appears to lead to greater levels of intangible value. “

Back in October, I had the opportunity to attend the Project Management conference in Denver, Colorado. It is an annual conference organized by the Project Management Institute (PMI).  Every year PMI holds four conferences in four locations covering most of the world – North America; Latin America; Asia Pacific; and Europe, the Middle East, Africa.

This is the second time I attended this conference. What was different this time, besides the record participation of over 4,000 program and project managers, was the variety and selection of topics. Past conferences have focused primarily on the project management standards and guidelines, known as PMBOK (Project Management Body of Knowledge). This year, a number of presentations explored other aspects of project management, with several focusing on new trends.  Agile project management continues to be a hot topic, with presentations ranging from agile project management in the changing business environment, to application of hybrid agile project management methods.

The presentation by Global Project Design’s Patrick Murray and Susan Thomas on “Designing Complex Projects” stood out for me because it offered an innovative way of thinking about complex projects. While you may find these ideas too revolutionary and forward looking to be considered for immediate implementation, they provide an outline for some future trends in the project management, particularly when viewed in the context of recent developments in the area of agile project management.

The main premise of their presentation was that the business environment and projects are increasingly complex due to the use of the remote teams and multi-cultural business relationships. As a result, some of the project management principles considered the industry norm need to be re-examined and adjusted. One of the areas requiring re-thinking is project initiation and planning. It comes out of a need to design a project in such a way that it allows accommodating for the unknowns.

With projects becoming more complex and global in nature, the amount of coordination increases as the project manager has to deal with time, culture and possibly even language differences. These global factors can increase the amount of coordination required two or three times over. However, coordination often goes unrecognized, resulting in optimistic schedules and budgetary overruns. Even when coordination effort is acknowledged and accounted for in a project budget and schedule, it is challenging to accurately forecast the required level of effort.

So how can you account for coordination?  First, there is a direct relationship between coordination effort and project complexity. The following factors contribute to the project complexity and signal that a significant coordination effort will be required:

·         Project size

·         Teams from different time zones, work cultures, and abilities

·         Complex dependencies between activities/tasks

·         Concurrency in activities/tasks

·         Relationship between projects

·         Complex decision making process

·         Stability of Requirements  (expected results difficult to predict )

·         Maturity of Technology

·         Process Maturity

Once a project manager concludes that a project requires some coordination effort, he or she can predict the amount of coordination effort required to effectively complete the project by using the following formula –

Coordination = Dependence X Distance, where

Dependence is demand for coordination between the teams and

Distance is team’s ability to coordinate with others

To predict Distance, the following criteria should be considered:

·         How large is a project team? Are the members in the same building?

·         How many time zones separate the teams?

·         How many projects have they worked together before?

·         Do they share the same native language?

·         Do they share the same profession/function?

·         Do they share the same direct boss?

The formula, along with these indicators, helps the project manager recognize project complexity and estimate coordination effort. However, to accurately predict the level of coordination, the authors propose a more complex approach that leverages methods typically employed in product development, such as building prototypes and running simulations to identify and select the most optimal project plan. Identifying and analyzing several possible project approaches during the planning phase helps the team to be more flexible in the implementation phase.  The ability to rapidly switch to another project approach helps teams address internal and external changes, such as changes in the project requirements, stakeholder priorities, or earlier delays. 

For more information about Project Model and Simulation, please refer to “Designing Complex Projects” (designing-complex-projects).

Mark Shuttleworth, of Thawte fortune and Ubuntu fame, has some (IMHO) neat ideas on how to manage software development efforts that may be interesting to spend a few human processing cycles considering.

http://lwn.net/Articles/292031

Despite the article being written for Free Software and Linux, I think it’s incredibly relevant to all development efforts – read it as if he’s talking about Molecular projects, and not Linux distributions.

Here are two key paragraphs:

One of the key requirements that Shuttleworth sees is the need to “keep the trunk pristine”, by doing integration on the trunk and feature development on branches. Along with this is the need for more and better tests. While not necessarily believing in test-driven development, he certainly leans that way. In any case, all the tests should pass before committing to the trunk.

Many projects do not yet have an extensive test suite, but this needs to change. He quoted a Chinese proverb that “the best time to plant a tree is 20 years ago, the second best time is today”. He mentioned that he is working on a robot that controls the trunk of a development tree. Developers will request it to merge from a branch, so the robot merges the branch and runs all the tests. If the tests pass, it commits, otherwise it gets kicked back to the developer.

This approach sounds pretty good to me.

This month I have been interviewing some of our colleagues and researching tools for a bug tracking system to be adopted as our standard. What became salient is that the tools are important but irrelevant if we don’t have the necessary processes and disciplines to support it.

Coincidentally this week I was reading the Harvard Business School Working Knowledge newsletter and came across a very interesting article, which made me think about the other incredible important factor on this equation: human resources! We can have the best tools, the best processes and methodologies, but finding testers is still very challenging, and that is because people are challenged by novelty and can’t stand doing the same task over and over again. It is common knowledge that after a while testers get burned out and start making mistakes.

According to the article – summary and link below – a Danish company found the perfect fit for the function. It employs people with a form of autism, that have the characteristics needed for the testing process: high intelligence, precision-oriented skills, deep concentration, and patience to be checking and rechecking outcomes, documenting test plans, and maintaining follow-through.

I think one of the lessons here is that when thinking about QA we need to think about documentation, stress the need of having very detailed test plans to be able to rotate testers and to outsource parts of the process.

Executive Summary:

Software analysts and programmers live to innovate—but hate to run tests. Yet top-notch testing saves many a company money when bugs are caught early. A new case coauthored by HBS professor Robert D. Austin describes the secret behind a Danish consultancy’s success: The majority of its testers have Asperger syndrome or a form of autism spectrum disorder. Key concepts include:

• Techies tend to be idiosyncratically talented. The case “Specialisterne: Sense & Details” is about putting diverse talent where it will be most effective.
• Software testing requires superb powers of concentration combined with tolerance (even preference) for routine tasks.
• Seventy-five percent of the software consultants in the Specialisterne case have Asperger syndrome or some form of autism spectrum disorder.
• Some software testing may be offshored, but mission-critical testing must be done near the client.

For the whole article: http://hbswk.hbs.edu/item/5869.html

]]> http://molecularvoices.molecular.com/2008/qa-process-design/feed/ 0 http://creativecommons.org/licenses/by/3.0/ http://molecularvoices.molecular.com/2008/what-is-the-secret-to-project-management/ http://molecularvoices.molecular.com/2008/what-is-the-secret-to-project-management/#comments Fri, 18 Apr 2008 13:04:05 +0000 Peter Marci http://molecularvoices.molecular.com/?p=284

As the director of the project management discipline for a leading Interactive Agency, I interview quite a few people. A standard question I ask during a typical first interview is “What do you feel is the secret to project management, in other words, what separates good project managers from great project managers?” It is a pretty open-ended question and there is no right answer but it is a great question to gain better insight into the depth of the candidate. The most common answer I get is “communication, making sure everyone knows what is going on”. While this is not incorrect, I think there is a much deeper and truth-seeking answer beyond this stock response. My answer to this question “emotional intelligence”. In his book, “Emotional Intelligence for Project Managers”, Anthony Mersino, PMP states the following:

“PMP certification does not in itself make a PM more capable; it simply proves that you have the requisite project management experience and can pass the multiple-choice certification exam. To be truly effective you need to be able to implement projects and work well with your team. Emotional intelligence will help you do that”

I could not agree more. The concept of Emotional Intelligence (EQ) was first popularized by Daniel Goleman in 1995 with his book, “Emotional Intelligence: Why it can matter more than IQ”. In his follow-up book in 1998 entitled “Working with Emotional Intelligence” Goleman presents an Emotional Intelligence framework for the workplace. Similarly, Mersino presents an Emotional Intelligence framework specific to project management. Both frameworks include a subject I would like to discuss and describe in greater detail. That topic is empathy.

I’ll define empathy as the ability to accurately interpret the thoughts and feelings of another individual. This is a skill that if practiced and applied is incredibly powerful if used in a positive and solution-based manner. This is also a skill that I preach (and try to teach) to the project management team at Molecular. It is also a skill that can be counter-intuitive to the mindset of the project manager. As project managers we are taught to control expectation, control scope, control budgets and we are measured on how well we do so. However, it is my perspective that through the use of empathy a project manager increases his/her ability to communicate in a manner that oftentimes guides the client or team member to the best solution for the project given project constraints. For example, let’s take a very common project situation. A project manager is leading a facilitated meeting. There are tight timelines and budgets (as always). The customer gets an idea that in his/her mind is a fantastic idea will enhance business success that is out of scope based upon an agreement that was previously signed. Let’s approach the response to this situation two different ways:

The PM responds, great idea but that is not in scope we have tight timelines and we need to get this project completed by the end of the quarter…let’s move on. While I’ve exaggerated this response to make a point, the message received is probably not too far off.

Let’s take a more empathic approach to the response:

The PM responds, I think that is a great idea can you tell me more about how you see it working? Starting with an open-ended question invites information to flow that leads to a response based upon an accurate interpretation of what the individual is trying to communicate. The idea could be something that fits within the timeline and budget established and it may not. If it does not, it might be an idea worthy of changing the budget and scope if it possesses the business value warranted. If true, the latter situation would benefit both organizations in the sense that greater business value is being delivered in exchange for greater investment in services (a win-win). If the business value is not there, more times than not the originator will arrive at that conclusion on their own through an open discussion and the idea is deferred to a future release. This can also position the project manager as a trusted advisor and someone who can engage in strategic thinking versus someone who squashes the thinking and creativity of the group.

Keys to expressing empathy:

1. Ask open-ended questions – let the other person speak first by asking open-ended questions. Open-ended questions invite information versus a close-ended question that introduces a power-play leaving the respondent wondering whether to disagree or agree with the answer contained in the question. Don’t say “are you not getting that deliverable done because you disagree with the approach”. A better approach would be to state: “I noticed we are running behind with this project deliverable, is there a reason that we need to discuss?

2. Tailor your response – after working to understand the perspective and mindset of the other individual, tailor you response to fit the perspective. Instead of launching into a pre-meditated agenda, first understand and acknowledge the other person’s perspective before introducing a differing point of view. Let the story unfold. Don’t listen with your mind already made up.

3. Control your emotions – in the heat of the moment, often times the emotions of the situation boil over. If the discussion becomes emotionally charged and it is preventing or hindering a solution-based conversation, look to de-invest, let the emotions cool and try again later. Say “we’re not communicating well at this time, let’s table this conversation until a later time after we’ve had time to think about it some more”.

4. Avoid snap judgments – form judgments based upon the facts of the situation, not hearsay or other indicators which may be false or only partially true. If you’re very familiar with the other individual you are working with there is a natural tendency to assume based on past interactions. Work to avoid this tendency as every interaction is different regardless of familiarity. When you begin to say to yourself “I know where this is going…” work to stop yourself and continue to listen.

5. Put yourself in the other person’s shoes – work to put yourself in the shoes of the other person. Ask yourself, what would I feel like if I were in that position? This will create a better understanding of the other person’s perspective as well as create better self-awareness within you. Imagine being the person who feels their idea has been invalidated by a scope-mongering project manager

In applying these elements to your daily interactions with customers, colleagues and project teams your relationships will grow stronger and you will develop and gain greater respect and trust as a project manager. Whether you’re trying to communicate a scope change to a customer or trying to understand why your team is struggling with a specific task of a phase of a project, the power of empathic listening will guide your interactions and separate you as a project manager.

So, the next time someone asks you what the secret to project management is, go beyond simply saying ‘communication’ and discuss the importance of emotional intelligence and empathy. While it is not the secret, it is a way you can differentiate yourself from your PM peers.