As we are well into the last half of this decade, it is time to reflect on our past and contemplate the future. With the New Year we think about our families, our friends, our successes and failures; we think about our jobs, our professions, and the world of possibilities. We must reaffirm our true north and stay the course, make corrections, or find a new destination. As project managers, we must look at the changes in the discipline and translate those into a plan for our professional development—a plan that meets our needs and the needs of the discipline.
Tomorrow's Project Manager
As project managers, we have seen significant change. Over the last couple decades, the project management field has grown to be recognized as a professional discipline and many have benefited from the changing views of how projects are run. We have witnessed or implemented processes and procedures and have seen project management offices spring up to help prioritize enterprise portfolios and manage resource loading. It has been an exciting time.
In the last half dozen years, many have seen project management become a commodity. Various organizations push their certificates as the end all of employment requirements and companies have created checklists to qualify good project managers just as one might look at the functions required from a personal accounting program. Employment firms relying on high-volume placements capitalize on this attitude, realizing how cost effective the screening process can be. Meanwhile, thousands of people clamor for their project management certification so they can jump into the resource pool.
It takes more than a certification, however, to make a good project manager. The most valuable experience is coordinating all the stakeholders to achieve a common goal. These traits are difficult, if not impossible, to acquire in a class, let alone grade on a test. Process is a vital component; however, project managers must step beyond the role of processes and aspire to be leaders. This will manifest itself in three grades of project managers.
Tier One: The Coordinator
Today's certifications equip project managers to be coordinators. The expectation is that they herd cats. They work reactively at the rear and the flanks keeping the cats all going the same general direction.
This is a comfortable non-confrontational roll where a majority of project managers feel comfortable and nearly every company requires the trait. The coordinator implements processes and procedures, monitors timelines, reacts to problems, and escalates out-of-control issues. This is the area where project management has become a commodity—if you can get projects to be proceduralized anyone can manage them.
Tier Two: The Negotiator
The negotiator has a different set of skills—they run with the cats and apply reason getting them to head the correct direction. This requires that the project manager understand the stakeholder's needs and values and can mediate a compromise.
Once the portfolio develops past the point of repeatable projects, there is no longer a single possible goal a project. The project manager has to coax people to compromise and develop a mutual endpoint that provides value to all stakeholders. This is the first level of leadership.
All negotiators understand there is a process to follow—planning how to approach the negotiation, exploring options, proposing and bartering a solution, and executing the plan. However, few question that the majority of negotiation is art. The way people support their viewpoint, handle their demeanor, show confidence in their beliefs, and deal with rebuttals make or break a successful negotiation.
By managing a team in this manner, they begin to self-correct and adjust their course realizing the power of the team and ineffectiveness of running off on a tangent.
Tier Three: The Leader
The project manager that walks in front of the herd, the cats following, is at the highest level of aspiration. Leaders understand their mission, mold and maintain a vision aligned with the strategic goals of the organization, communicate the direction to the team, and inspire people to achieve that vision. The team becomes self-directing.
Leadership can be learned, but not from a book or class. It is acquired from understanding the tools and applying them. It requires experience and an open mind.
The opportunity to enter into a leadership role presents itself to nearly everyone. We need to recognize that situation and know how to step in and lead the team to success. Our biggest obstacle is the courage and confidence to move in that direction—to know when the cats will follow. The first few attempts often lack the polish and finesse of the accomplished leader, but experience brings it rewards.
How to Get There
The key to the future is acquiring the soft skills to aspire to new levels of management. Minimally this requires education in organization development, sociology, business management, and leadership. However, the cornerstone is real-world experience. As with any discipline, education pales in the shadow of experience. Moving from a reactive to a proactive approach where identifying and addressing problems prior to them becoming issues is critical. This requires a calm, methodical approach and open communication channels with all stakeholders. The result is a high-performance, self-directing team that drives any project to its appropriate goal.
What Are Your Thoughts?
How do you see project management changing over the next five years? Please let us know.
Leadership is more than leading the people who report to you. As a project manager, you need to lead a team which you rarely have any authority over. The absence of hierarchical advantage adds a challenge, but is ideal training on how to deal with managers, customers, and difficult people. The key is making them feel that they chose the direction. One of the best methods of doing this is storytelling.
To start, you need to listen non-judgmentally. Too often, we jump to conclusions, share observations, blurt out solutions, and fail to give others time to assimilate information from our point of view.
A few years ago, I was talking with a potential client that had a very successful data analysis company. The problem they were having was with a custom piece of proprietary hardware they had designed and built to collect the data. The business development manager, who loved hardware design, was managing the product development and was relaying the current situation. I asked for the history on how they got to their current disheveled state. He sighed and told me his tale of woe.
The first release was a success, but after short time a key supplier of one of the core components, a small company, went out of business. This made him look for a new supplier. Adding to the frustration was that all the other suppliers charged significantly amount. We talked about the functionality and a few other particulars on that version. He continued by saying that about a year later they created a new revision and changed that same component's functionality to use firmware so reprogramming would be easier. They contracted with an individual, who was desperate for work, to design the part. As a result, they got a great deal. Unfortunately, the protocol used was nonstandard and no other suppliers used it. When the contractor found full-time employment, they were again without support. Version 3, the version currently use, had another component losing support and they needed to find a new vendor.
The present problem was on a contract with a new company, started by a recent college graduate, to supply a subset of components. He was running into multiple problems, various vendors were arguing that he had designed the interfaces incorrectly, and now he had taken another job out of state. The business development manager was left with money invested in an unusable product. He insisted the problems were unavoidable and the company's strategy was prudent and fiscally conservative.
Building The Story
I returned to my office to determine how to approach telling them that they needed to focus on gathering and analyzing data, not building hardware, and the business development manager's pet project should be given to a company that specializes in developing custom hardware. I sent them an email asking about their growth plans for each business unit and clarifying a few other points from our conversation. From this information, I outlined the following agenda:
As I replayed what I had been told, they started filling in the answers, arriving at the conclusion that they should focus on their core business of collecting and analyzing data, rather than building hardware. I never had to mention bullet 4, they came to that conclusion on their own. Investing time in building a trusting relationship with a reputable product development group, whose responsibilities would include architectural design, building, and supplier management, would free up time of the business development manager to... well... develop new business. It would also insulate the company from problem in the hardware supply chain.
I could have told them in the first meeting that product development was not their forte, and that the business development manager's pet project of managing all the vendors was costing them dearly, but I would have not been invited back. As obvious as some answers seem, when situations have evolved over time the people in the middle are unable to see some of the most obvious answers. Playing back words in a different context is the key to shedding light on the proper direction and draws them to the conclusion using their own words. Your job is to simply facilitate the process.
Back in the eighties, I was working for a large aerospace company cutting my teeth as a systems analyst. My bosses were a little older than I am now, and they loved talking about the days before cubicles, pontificating on how personal computers were inferior to mainframes, and reminiscing about the days of the BOMARC missile. It was their way of telling us thirty-something kids that they were in control and we needed to respect their position. Then, as now, information was king and these lumbering ligabuesaurus were not letting it go. To earn your stripes, one had to partake in the tribal rituals, smoke cigars during three-martini lunches, and attend your boss's parties. They saw no value in email let alone the boondoggle shop floor automation project I was part of. In two words, communication sucked.
The Peanut Enters Stage Left
The office was split between the people that ate their lunch at their desks and those that drank their lunch offsite. It was a very different time with ashtrays still a fixture in all conference rooms. I was content eating the lunch my wife had packed in a nondescript brown bag and being pleasantly surprised at her occasional little additions. One day, she threw in a small bag of peanuts. For some reason, I offered them to my three cubicle mates by quietly placing them on the communal table in the center of our shared space. It was not long until Bill, our boss, missiled past our cubicle's entrance on the way to one of his ever-critical planning meetings. With hardly a glance into our workspace, he made an instant course correction to the coordinates of our peanut-laden table. He sat his papers next to the peanut bowl, freeing both hands for the delicate job of shelling peanuts. He focus was suddenly on shelling, eating, and, most importantly, talking. We heard about his upcoming meeting (which would fall into dismal disrepair without him, so he must hurry) as he carefully extracted the meat, dutifully depositing the shells in the dustbin, and slapping their contents into his mouth as one might knock back a shot of cheap whiskey. We sat in amazement of his openness. Within a few minutes, he depleted the peanuts and vanished. My cubicle mates and I stared at one another in shock—communication.
Refining The Process
Over the next few weeks, the small bags from my lunch grew to five-pound bags of Hoody's unshelled salted peanuts stored under my desk. The baggie and trash can were replace with two nice bowels—one for peanuts and another for the empty shells—both of which my wife had found at a garage sale. We discovered that shelled peanuts were ineffective—people would just grab a handful and run. Unshelled peanuts required two hands, a place to conveniently dispose of the waste, and, most importantly, time. Shelling produced only two peanuts, not enough to quench your appetite or impede conversation. It was the perfect combination of lack of satiation, effort, and tending to addictive traits to create the proper dwell time for conversation. We were exploiting people's weaknesses and manipulating our bosses' behavior.
Don't Talk With Your Mouth Full
Information flowed, people understood the goals, and anxiety waned. All for peanuts. In later years, I have found that cherries, grapes, and crackers and hummus all have the same effect. Variety of fair brought the curious. The key was to partake required two hands, or maybe pit, and cannot fill the mouth. Eating one must only whet the appetite.
The task is: do not act too curious. Let them divulge a little. Ask some small question. Then just shut up and listen. They will not be able to tolerate the silence. Splat, here comes a bunch of stuff you never would have heard in a meeting. The challenge is that we never listen enough. Those old bosses never did, they still don't, and, I have news for you, neither do we. Let people ramble and you will be surprised at what you learn.
The Peanuts in Reverse
There is more to learn from this than how to get information from superiors. Hidden in it is the value of unstructured spontaneous communication. This is at the heart of the age-old form of "management by walking around." Walk into a subordinate's office and simply asking how they are doing. The first few occasions bring skepticism, but as it becomes the norm, people open up and tell you what actually is going on. The two key ingredients are:
Let's Hear From You
What tricks do you have to boost communications?
Does your boss only seem to stand in your way? Is he or she fearful of accountability, grossly indecisive, and never providing enough information to understand their objections? It is more common than most of us would imagine. In fact, this behavior is central to every sales interaction. Even though you may be repulsed at thinking of yourself as "selling" to your boss, that is exactly what the action you are doing—selling your concept. Therefore, it makes perfect sense to employ the same techniques used to sell large systems. If you think this is rubbish, as one of my esteemed readers once eloquently said, I will posit that you are already using sales techniques, just the wrong ones—the ones car dealers use. Changing your approach will subdue your unruly boss
The Answer Is Questions
Normally, when asking we ask our bosses to make a decision, we present them with a list of benefits and then ask for a decision. This is identical to the methods of the car lot's stereotypical slimy salesperson. They list numerous features (whether they are important to you or not) and go for the close—"Would you like me to draw up the paperwork so you can drive it home today?" That technique might work if you were buying a multifunction calculator or some new inexpensive widget for your computer, but it falls woefully short in higher stakes decisions where money, reputation, or both are on the line. Instead, decision makers want to understand the value based on the key benefits to them. In the case of the car, what might be a cool feature to the sales person (a remote control rear window sunshade), may be useless to the buyer. On the other hand, additional backseat legroom may be critical for comfortably transporting clients to lunch. A salesperson will have a much easier time selling the latter.
The simple solution is to ask your boss what is important to him or her. For these questions to be successful, they must be the right type of questions. Author Neil Rackham's research shows that when selling any "big" items, four types of questions must be asked—situation, problem, implication, and needs-payoff. These conveniently condense to the salesy term SPIN questions.
The first level of questioning is situational. These questions determine the authority of the person to make the decision, who is involved with the making it, and so forth. These are the most basic of questions, and seem too inconsequential to focus on. Although they appear to be trivial and may be annoying to answer, they have an insightful impact on the outcome of the decision. Questions in this category are similar to ones that determine whether there is a preference on make/buy, in-house, or outsourcing. Assuming what these answers might be, though, can have a profound negative effect on the decision maker's reception to your proposal. Many of us have been in the embarrassing situation where suddenly the option of buying a COTS (common off the self) solution was the unspoken preference.
Problems are in the eye of the beholder. Even though you and your boss work for the same company, each of you may identify problems very different. Problem questions elicit your boss' view of what is important. Your view of the problems is irrelevant when justifying his or her decision. To find out the decision maker's view, ask questions about specific problems and their weight on the organization. Always add the question "Are there any other big problems?" Knowing there is a problem is not enough, executives must have an explicit need for a solution. The following two sets of questions determine the explicit need based on these implicit problems.
When describing problems we are intimate with, we tend to think that everyone understands the gravity of them. It is obvious to us since we have worked with the issues so long. We need to layout out questions that will guide others down a path of discovery so they may internalize the problems' scope. As the name implies, implication questions drill into the ramifications of the problems. They help the decision-maker comprehend the problem's consequences. For instance, if you are trying to resolve a problem with untimely production throughput reports, then implication questions could address whether late or inaccurate reports cause:
It is not the problems, rather the implications that arise from those issues that creates the sense of urgency. These questions help the listener understand the breadth of the problem and sets you up for the final set of questions—the needs-payoff questions.
The structure of needs-payoff questions shows the listener the need for your solution and its payoff. These questions, as opposed to the earlier questions (which are negative by the fact they are exploiting problems), are termed in a positive tone. Instead of saying that an implied problem is costing a certain amount, the questions take on a positive form focusing on how much would be saved if an explicit problem is resolved. For instance, "Eliminating the accidental scheduling of overtime would save you how much money?" and "How much would you save in rework costs if you could catch issues a few hours earlier?" These questions provide the final piece of data that you and your decision maker need—the cost justification. If the cost savings outweigh the cost of implementing the solution, the decision becomes much easier.
The sequence of questions has two significant benefits of:
Will some still object? Of course. In fact, some will realize that you are trying to corner them and will stop answering questions. You may need to resort to asking the questions over weeks in casual conversation and keeping meticulous notes. In the end, you will have an extremely convincing case for supporting a fact-based decision.