The Neal Whitten Group

No-Nonsense Leadership and Project Management

 LinkedIn
  • Home
  • Mission
  • Services
    • Speaking
    • Training
    • Consulting
    • Mentoring
    • Our Clients
    • What People Say
  • Newest Book
  • Articles
  • Appearances
  • Power Snippets
  • About Neal
  • Contact

Contact Us

For information about the services and products of The Neal Whitten Group, please explore this site, send e-mail, or contact The Neal Whitten Group at:

The Neal Whitten Group
2791 Bud Black Road
Auburn AL 36879
Tel: 770-378-2980

Archives for 1998

Are You a Benevolent Dictator? You Should Be!

December 29, 1998

Micromanaging, consensus management and democratic rule all can be highly ineffective leadership styles.

by Neal Whitten, PMP, Contributing Editor

IN RUNNING A COUNTRY, democracy is the best thing going to date. However, in running a business or project, my experience has shown that the benevolent dictator style is the most effective. A benevolent dictator leads by actively soliciting information and opinions from team members and others—listens, then demonstrates the leadership, courage, and boldness to personally make the right decision, and stands accountable for that decision. A benevolent dictator also holds his or her subordinates accountable for their decisions and they, in turn, hold their subordinates accountable for their decisions, and so on. In other words, everyone is encouraged and expected to make the decisions that affect their own domain of responsibility.

Now, I’m not talking about micromanaging. Micromanaging occurs when a leader chooses to make decisions for anyone and everyone within his or her influence. The micromanaging “leadership” style is highly offensive; it neither teaches the importance nor capitalizes on the promise of accountability. It should only be used in rare instances, for very short periods of time.

Many organizations and projects attempt to operate on either consensus or democratic rule. Consensus, which has been over-hyped for years, is mostly an ineffective tool in managing teams and projects. Consensus is obtaining the buy-in from a team or group by adjusting the final decision to a position with which everyone can live. For other than the most-trained teams, consensus causes the most important decisions to be compromised, to be watered down. In an attempt to satisfy all team members in buying into the team’s decision, the solution is almost always non-optimal and, frankly, is often without vision and personal commitment.

What’s that? You say there is personal commitment because everyone had a say in the decision? Yes, everyone had an opportunity to speak their mind, but my experience shows that many don’t speak up or they are quick to compromise or live with someone else’s proposal—even if they feel it is weak. Many members of a group consensus don’t feel personally committed. They hide behind the facade of the team or group.

What do I mean by personal commitment? Personal commitment is when you, personally, are charged with making a decision and then you are held accountable for the outcome of that decision. Teams cannot feel this level of accountability, only individuals can.

What about using the democratic voting process? Organizations or projects that consistently reach decisions by democratic rule frequently can be more ineffective than reaching decisions through consensus. Why? Because the majority vote is usually enough to lock in a decision. Unfortunately, everyone with a vote to cast is looking out after his or her own personal interests or the personal interests of the team he or she represents. Consequently, the right business decision can easily be overlooked or dismissed.

You might be asking about now, “If the benevolent dictator concept is so effective, then why don’t more leaders adopt this style of leading?” Two big reasons: The first reason is that in the free world many of us shy away from any association with the word “dictator.” Even with the adjective “benevolent” added we still feel uneasy. The other big reason—and it’s the biggest one—is that to be a benevolent dictator means we have to make decisions that will, at times, be unpopular. Many of us have a hard time making decisions that are criticized by others. In fact, the primary reason why project managers fail is because they are too soft and have difficulty making the tougher decisions (see PM Network, December 1997, “The #1 Reason Why Project Managers Fail: Too Soft!”).

I often hear project managers and resource managers say they cannot effectively adopt the benevolent dictator concept because they have a serious shortage of project members and employees with the good business sense—the leadership skills—to make the tough decisions expected of a benevolent dictator. I strongly disagree! For most of us, I believe we do have the people we need, they just haven’t been trained properly. After all, they watch how we manage and copy our styles.

ALL OF US NEED to be trained, coached and mentored in the skills and behaviors that make for the most effective leaders. Nearly everyone will rise to the expectations that we set for them—providing we constructively nurture them along the way. If you want your project to be run like a business where decisions are made based on what’s best for the business, and you want the project members to consistently take accountability for their own actions, then teach and encourage the powerful benevolent dictator concept at all levels of a project and organization. It’s good business!

Meet Minimum Requirements: Anything More is Too Much

September 1, 1998

Commit to a project plan that only includes essential function, with a “closet plan” for nonessential function.

by Neal Whitten, PMP, Contributing Editor

Does this conversation between a project manager and a project outsider sound familiar? It’s a Y2K project, but it could be any project.
Outsider: “Will your project complete on time?”
PM: “We have no choice.”
Outsider: “I didn’t ask if you had a choice. I asked will you complete on time?”
PM: “This is an important project. There’s a lot riding on the success of this project. We must complete on time.”

(Translation: “No, we won’t complete on time. Anybody with any project experience knows this.”)

Is this a Y2K-unique problem? No—it’s common on most projects. The primary reason it’s so common on Y2K projects is that most of the project managers and other project leaders on these projects were trained on pre-Y2K projects. Let me explain.

One of the most common problems with projects is taking on too much work—attempting to exceed requirements rather than meet minimum requirements. This contributes to a plethora of ill effects, including late deliveries, budget overruns, low morale and poor quality. Attempting to cram the proverbial 10 pounds into a 5-pound sack is a common occurrence.

One solution is to build products that meet minimum requirements. You may be thinking that such a product would have low appeal to your client or customers, but it’s not what you think.

“Meet minimum requirements” means give the client what he or she needs to be successful; but don’t provide unessential function. Additional function is what future releases and future business opportunities are all about. It is important to earn the reputation for being reliable in meeting customer commitments and then be trusted to continue to upgrade on a routine, predictable basis. This is good business.

You say you always only provide essential function? For most of us, most times, that’s not true. Have you ever faced slipped delivery dates and chosen to remove some of the function originally planned? When the project began, everyone swore that all the planned function was essential. Yet, as the project progressed—and got further behind schedule—some of that essential function no longer looked so essential.

We’ll use a Y2K project as an example, because Y2K projects are at a heightened focus these days—and, interestingly enough, the No. 2 problem with Y2K projects is that they are taking on too much work (the No. 1 problem is that too many projects are starting too late). Here’s what should occur.
Let’s say you’ve identified 100 functions (enhancements or changes) that need to be made in your company’s programs. You know that all 100 functions are desirable, but you recognize that your limited resources won’t allow all the functions to be ready by the hoped-for date. You find that 40 functions fall within the high-priority category, 30 as medium and 30 as low. You build a project plan to implement only the 40 high priorities. Why? Because you don’t want to jeopardize the timely completion of these 40 by building a plan to include the other 60 functions—all of lesser importance and, for purposes of illustration, deemed nonessential.

You might be thinking that you should build a plan with all 100 functions and later, if (actually, when) the project gets into trouble, you can always back out of lesser-priority function. Don’t go there! This foolish plan requires spending valuable time, dollars and resources working on other-than-the-most-important functions. Moreover, when you back out, it costs again. What needs to be done is to build a plan that significantly reduces rework. This means the original plan must be only essential function.

What about the other 60? You carefully look these over and put work-arounds in place that, although not optimal, can get you through until more substantial actions can occur.

But there is something else you do. You decide on the most important of the 60 functions—maybe it’s all of the 30 medium functions or some subset thereof—and you create multiple, independent small projects with any and all resources you can muster. I call these small projects collectively a “closet plan.” These small projects are managed with the same care and attention to quality as the primary project. If any of these small projects can complete by a predetermined date (e.g., system test) and the risk to the primary project is judged to be acceptable, then the completed small projects are merged in with the primary project. There are many advantages to this technique: from reducing risk to the primary project, to motivating the members of the small projects to complete by a predetermined date, to setting customer expectations that are most likely to be met or exceeded.

MOST OF US have been conditioned to believe that “meets minimum requirements” is unexciting and noncompetitive. I believe it to be the opposite. Deliberately practicing meeting minimum requirements helps an organization or company to be first-to-market, earn increasing credibility from their client(s), and strongly posture their enterprise for taking on new business opportunities. Adopting the concept of meeting minimum requirements can set your organization up for exceptional performance.

Award Generously — It Costs Far More to be Stingy!

June 1, 1998

It’s far easier to retain good employees than it is to find and hire them.

by Neal Whitten, PMP, Contributing Editor

PICTURE THIS: You are a professional, salaried to get the job done. You’ve been working 10–15 hours of overtime per week over the past few months. You feel that this extra effort is occasionally expected of those who have a reputation for “getting things done.” The events that caused you to work the extra time were mostly out of your control, but you rise to the occasion and complete the job on time. You feel good about your accomplishment.

Within days, you are at a meeting when your boss singles you out and thanks you for the extra effort you have demonstrated, effort that yielded positive results. He hands you a certificate of thanks for your achievement. He also gives you a check for $150, with the suggestion that you use it for dinner for two at your favorite restaurant.

How are you feeling now? Probably great! Appreciative of the attention … Feeling good about your recognized contribution … Liking the certificate and loving the check.

Over the next weeks and months, you experience a feeling of wanting to give more. To help others more. To live up to the expectations that you perceive both your peers and management have of you. You like working here a little more than before.

Let’s examine what just happened. You received a “bonus” that amounted to about one dollar for every overtime hour you worked. And you are elated! What an easy and inexpensive method to win your continued dedication and support! Yet, many organizations—from my experience, most organizations—do not engage in this highly beneficial and cost-effective practice of quickly recognizing extra effort that has yielded measurable benefits to the organization, a client, the product … you get the idea.

Now let’s look for a moment at a more typical situation. After each bout of consistent overtime—what feels like a Herculean effort—with no tangible appreciation coming your way, you increasingly have doubts about this organization being the right one for you. You feel more and more used, perhaps even abused. You are even less motivated to spend extra time working on problems that are mostly beyond your control.

What happens? Your attitude and enthusiasm take a hit. Your productivity wanes. You begin to look for greener pastures. You find an outside offer that is too tempting to resist. You’re history.
Your leaving could cost your old company tens of thousands of dollars. How? The project will have lost a skilled resource. Schedules, budgets and even quality may be adversely affected. There may be a negative impact to the client and to the company’s relationship with the client. It may take weeks or months to find a suitable replacement—and what if that replacement doesn’t work out and yet another applicant search is required? I could easily go on with other negative ricocheting events that could come about from your departure.

The message? It is far easier to retain good employees than it is to find and hire them. A few hundred dollars well placed from time to time can save thousands of dollars. Even thousands of dollars spent rewarding outstanding contributors can easily save tens of thousands of dollars later.

Another tip: Never give certificates without also including cash or some tangible equivalent. Why? Because today, more than ever, such behavior is seen as a cheap, insincere method to patronize the employee for his or her continued best efforts. But don’t give cash without a certificate, either. After the cash is spent, there’s no lasting, tangible reminder of how much the employee is valued. Certificates can live on for years and be invaluable and recurring sources of pride.

If you are a project manager and don’t have the authority to give awards, then at least be a catalyst and work with the project members’ managers to influence fair but generous award giving. You will find that people will be more willing to go the extra mile for you.

IF YOU EVER DOUBT the appreciation a person feels for receiving a well-timed award, look at awards you received and recall how much they meant to you. Moreover, think how you felt when you worked in a stingy organization that continually overlooked awards. As I said, awarding for outstanding achievements is so inexpensive when you consider the alternative of losing the hearts and minds—or employment—of your employees and project members. Don’t risk losing your treasured talent. Award generously. It’s good business for everyone.

Ask for Help — Or Become Part of the Problem

March 1, 1998

Asking for and obtaining help is a sign of professional maturity, not weakness.

by Neal Whitten, PMP, Contributing Editor

DOES THIS SOUND FAMILIAR? You are a member of a project—project manager, team leader, team member, or manager. You have made commitments to completing project tasks. The overall success of the project is, in part, tied to you meeting your commitments. Your commitments are in jeopardy.

What do you do? Do you continue on your current path, where you know you are not likely to meet your commitments of time, cost and/or quality? Or do you ask for help? If you are like 90+ percent of project members (my estimate), you don’t ask for help. Instead you allow your missed commitments to damage the overall integrity of the project plan and project.

What? You say you would never do that intentionally? I disagree! Most of you have, by your past behavior and record, brought harm to one or more projects and did not ask for help. Instead, you waited for help to descend upon you—and often resented the attention and direction of that help.

We are all guilty of not asking for help at some time or another. To learn from our mistakes and mature professionally, we must understand the importance of asking for help as articulately and as early as possible.

It’s not easy to ask for help. Remnants of what I call the “John Wayne Mentality”—asking for help is a sign of weakness, but going it alone is a sign of strength and virtue—remains strong in our culture. Perhaps this mentality was required for survival in the Wild West. But today, as people come together as a team to pool their talents and skills to create achievements far more complex and superior than any one person could hope to accomplish, asking for help is a sign of strength. Not asking for help is a sign of weakness, and can undermine the success of the project.

Today’s best leaders and organizations encourage teaming and teamwork, and they recognize that a project’s success correlates directly with the success of each of its contributors. A great benefit of teams is that they are made up of people with a wide range of skills and experiences, which increases the potential for sharing and helping one another on a project.

When you find yourself in trouble and at risk of not meeting your commitments, seek help. However, there is a preferred approach to seeking help, particularly as you go up the corporate hierarchy to ask:

  • Clearly define the problem that you need help on. A problem that is incompletely or vaguely defined wastes valuable time, energy and funds.
  • Describe the proposed solution. If more than one plausible solution exists, list them, but be accountable and take a position on the solution you favor.
  • Be specific about what you are asking for. A vague request may get a vague response. Telling an executive exactly what you need, as clearly and precisely as possible, increases the likelihood of the executive satisfying that request. Being specific has the added benefit of helping the executive to feel that he or she is really helping.

If you question whether or not asking for help is the right thing to do, ask yourself this: If this were your own business (see “Behave As If You Own the Business,” PM Network, September 1997) and an employee of your business was faced with the same situation as you are today, would you want your employee to ask for help? Or continue on a destructive project path? This becomes easy to answer when you think of it in terms of owning the business.

When you ask for help you show your human side and also send the signal that you take pride in your work and care about the success of the project. This creates an interesting side effect: the respect others have in you typically increases over the level of respect you experienced at the outset of the project. Of course, not asking for help and endangering the success of a portion or all of the project is a quick method for losing the respect and trust of others.

DON’T RISK BECOMING part of the problem because of misplaced pride and an out-of-date “John Wayne Mentality.” We all need help from time to time. And in today’s highly competitive, fast-changing climate it is more essential than ever for project members to be honest and ask for help when it is needed. Everyone helping helps everyone win!

Copyright © 2025 The Neal Whitten Group
Terms of Service & Privacy Policy | Data Access Request