Sunday, 27 March 2011 00:00

Leading Without Authority

Rate this item
(1 Vote)

Leadership is more than leading the people reporting to you. Too often, you need to lead people over which you lack any authority. 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 the direction chosen is theirs. One of the best methods of doing this is storytelling.

Listening

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 a significant amount more. 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 to design the part, who was desperate for work. As a result, they got a great deal. Unfortunately, the protocol used was nonstandard and no other suppliers knew it. When the contractor found fulltime employment, they were again without support. Version 3, the version in current 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.

Want to read more?

Projects take more than managers, they need leaders. Leading is a special set of skills that one needs to hone and develop. We have numerous white papers on the topic. One, Transforming Project Managers Into Project Leaders talks specifically about what a PM must do to become a leader.

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:

  1. Summarize the information that I had gotten, ask how they are going to achieve their aggressive growth goals, and what role the business development manager would have in that.
  2. Ask them how they were going to address the common issues any growing company would see—security, cross-training, hiring new staff, etc.
  3. Ask how they are going to continue managing a custom product development while doing this ramp.
  4. If required, list the problems with the previous versions highlighting the areas that were a result of not having an established hardware company managing and building their custom equipment.

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.

Obvious Solution

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. Replaying their 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. You simply facilitate the process.

Read 6201 times

Related items

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap