"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.
No comments:
Post a Comment