Saying No in Your Personal Life

In my last article I talked about saying no in the context of a project. Quite frankly this is much easier to do than saying know in my personal life. In a project I am answerable to higher authorities and must weigh how a "yes" will affect others. In my personal life a yes or no most likely just affects me - or at least affects only me in the immediate time frame.

Gender notwithstanding, the song from "Oklahoma", "I'm Just a Girl Who Can't Say No" has always been my theme song! It's just so hard for me to refuse any request. As I analyze this behavior I find there are three reasons this is so difficult for me.

1. It's rude to say no. I was raised to be a polite young gentleman. Everyone from my parents to my grandparents to aunts and uncles took an active part in this piece of my education. One just didn't say no - of if you did you were likely to get smacked. The goal in life was to be polite and accommodating - to everyone.
2. People won't like me if I say no. This is a logical conclusion to number one. I am polite and accommodating so people will like me. If they like me then things will go better for me.
3. My priorities aren't as important as everyone else's. There's a horrible saying I grew up with, "The definition of joy is: Jesus first, Others second, Yourself last. While perhaps teaching the importance of priorities and reducing the likelihood of the deadly sin of pride, it instills a horrible perspective of self worth and self image.

Saying no in this context is very difficult and so the path of least resistance is to just say yes. But what happens to me when I don't say no?

On an emotional level I feel rude. This is counter to how I was raised and goes against deeply ingrained behaviors. It's uncomfortable and I find I feel like I don't really like myself. Internally I cringe each time a say no - or even entertain the thought of saying no - and cower expectantly for that smack upside my head.

Additionally I risk disappointing people and if I disappoint them they won't think highly of me and my reputation will suffer, and they won't like me anymore. Remember that I want people to like me! I have this belief buried deep within me that if they like me they will respect me and things will go better for me. But just because people like me doesn't mean things will go easier for me. Fact is, the more I say yes, the more I will get asked.

When I don't say no I risk putting myself last and I won't get things done that I need to get done. The affects of these build over time; the more I put myself last the more "normal" that feels and the more comfortable I get at it - it gets deeply ingrained in my psyche and habits. As a result of putting things off that are important to me I build the habit of procrastination. This is a pernicious little habit and one that can take a lifetime to break.

I've also discovered that not saying no builds resentment. I've been polite and accommodating to these people - they should like me now, right? And if they like me then they should respect my needs - even if I haven't expressed them. Yet they keep coming to me with requests on my time and priorities - how dare they! They should like me enough to know better! Thus is the thought process rattling around in my head as the resentment builds. Oddly enough this resentment grows most strongly against those closest to me.

Saying no in our personal life mirrors the same constraints found in project management. First and foremost you must have a clear picture of your priorities and goals. Just like a project your life is hemmed in by the triple constraints of time, money, and scope. Only this time these constraints aren't affecting a client or corporation, they are affecting you!

There are three categories of people that we continually say yes to - or rather, refuse to say no to: those who have some control or power over us, those we feel beholden too, and myself.

Each group requires different ways of saying no. For those that have some power over us you have to be very clear what's at stake - just like on a project team. Saying no will have repercussions so you have to take the time to explain the effect of their request and possibly to establish proper boundaries.

To facilitate saying no you have to be clear about what you are doing and how an interruption will affect you. Is it going to be a five minute thing or a 50 minute thing? Can you schedule it for another time? Is it even a task you should be doing? (If not, then perhaps boundaries need to be set.) Will saying yes adversely affect your income? Will saying no adversely affect a relationship - either with the requester or someone else in your life?

Once you begin to answer these questions you can formulate your answer. In responding, here are some things to keep in mind:

• Don't let yourself be pressured into an answer - you have the right to think it through and make an educated reply.
• Be polite. You can be firm if you need, but you should always be polite.
• Don't feel guilty about what you have planned.
• Don't be afraid to set boundaries or limits.
• Look for alternative schedules. Can this be done later?

Saying no doesn't make you a bad -- or mean -- person! It focuses your energies onto what's really important to you in the "now".

Saying No in a Project Environment

"No" is never an easy thing to say whether at work or in our personal lives. Some of us are more adept than others, but regardless of your skill level it still is not an easy thing to say. In these next two articles I will explore the "when" and "how" of saying no in the contexts of Project Management and in our personal time management.

When it comes to managing a project all sorts of stake holders will be making requests of you, the Project Manager. These requests may range from deadline extensions (time line) to modifying the end result (scope creep), and everything in between.

To manage these you have to be very familiar with the concept of the "triple constraint" in projects. Every project you undertake is hemmed in by these three constraints: scope, time and money.

Say for example your project owner decides, for valid business reasons we hope, that instead of 12 months the project must be completed in six. Unless you have just really over padded your project then this really isn't going to be doable given the resources you've allotted and the defined scope. In order to meet this new deadline you're either going to have to reduce the scope of the project or throw significant chunks of money at it to hire more resources.

Or say the project owner comes to you and says, "I know that this project will do A, B and C, but I think it should also do D and E." It's possible that with only minor tweaks this could be done and there would be little or no effect on the other project constraints. The more likely answer, however, is that in order to do this you would have to extend the due date of the project and/or spend more money on resources.

This latter example is called "scope creep" and can come from many sources. Scope creep presents a major risk to a project. This risk can be a positive risk (as in it actually enhances the product and could present little to no effect on the time line and budget) or a negative risk in that it could greatly over extend the time and budget or worse yet, bring the project to a screeching halt. It is your job as the project manager to evaluate these risks.

Armed with the knowledge and full weight of your project's triple constraints you will be able to work with the project owner to come to a good decision. Perhaps you will lead her to a "No" with the realization that the department or company can't afford the impact to the scope, time line or budget. It's also likely that the new outcome outweighs the risks and the decision can be made to move forward with the changes.

When these types of requests come to you from above you don't want to stand there with your feet firmly planted and a "just say no" attitude. You have to educate these key stake holders of the risks and then let go of the outcome - because ultimately they are responsible for the project. Your job is to present all sides of the issue, complete with risks and benefits, and let them make the best decision. You also need to make sure that proper sign off is gained so that should it all go south you have a paper trail that shows who made the decision and when. Otherwise it could all land in your lap!

More often than not the requests come from other stake holders - such as project team members, customers, etc. Depending on who the requester is and what you feel the impact will be you will have a bit more authority to say yes or no. I have found that the majority of these types of requests come from two stakeholder sources: project team members and customers.

The requests from team members are those that usually affect scope or time. Often someone working closely on the project will come up with an idea that could significantly increase the usefulness of the product (scope creep). These are the people who know the product best and their ideas should be taken seriously. If you are too quick to say no then you risk alienating them and possibly losing a great enhancement to the final product. Try to bring them into the evaluation process so they get a fuller understanding of the risks and benefits.

More frequent, however, are the requests from a project team member that affect the time line's due dates directly. These are usually in the form of requests to move out a deadline. My personal approach is to address these requests right at the start of a project. I tell my team that if they find themselves approaching a missed deadline - either because they have hit a road block, they don't know how to do something, or they've become overwhelmed in some other area and have just not gotten to it - they need to tell me well in advance of the due date. If they come to me the day before it's due, or worse yet, the moment it's due - well, let's just say you don't want to have that conversation with me because at that point there's nothing I can do to help you. If you let me know early on then I can get you the assistance you need, divert it to someone who can get it done, or at least alert the project owners that this part will be behind schedule for a bit and devise a plan to make up the time.

The requests that come from the customers usually affect scope, but if they are from a customer that is controlling the budget line then you might have to deal with the budget constraint. The customers are the people who are going to be using the product and before the project is over it will have to pass user acceptance testing. It pays to keep these people happy and in the loop - they can make or break a successful conclusion to the project.

Simple requests like, "Can this be bold face instead of a red highlight?" might seem too simple to even consider and worthy of a quick dismissal. But what if there is a customer that is red/green color blind? All your pretty color schemes are now out the window! It might have paid off to listen to this customer.

Again, the best approach is to hear them out and weigh the cost and benefits with them. If they see the full effect of their request they might reconsider it. If they are insistent then you can bring it up to the project owner for consideration.

Saying no in the context of a project is much less emotional than it is in your own personal life. You have others you can point to and who will back you up. The "trick" is to try and bring the requesters into the decision making process with you as much as is feasible. This lets you say no with out really saying "no".

In my next article on saying no we will take a look at saying no in your personal life and in the context of your time management.