Warning: Creating default object from empty value in /home4/panthro/public_html/lessonsit.com/wp-content/themes/skeptical/functions/admin-hooks.php on line 160

Saying NO

Optimism, eager to help, over self confidence… you name it. There are plenty of reasons why people avoid as much as possible saying no. There is a very good side to it, but I’m afraid to say that the “dark side of the YES force” quite strong is, young Padawan.

It may be a cultural factor (and I strongly tend to believe it is) but, regardless of the causes, it’s important to mitigate the effects.

Beyond saying no, it’s also important to make room for the whole team to say no. Specially when dealing with younger teams, people may tend to avoid saying no, thinking that it could generate a bad impression to the management, as it could create the idea that this person is lazy, not committed enough or not capable enough. It’s your duty to clarify things, and let the team comfortable – but not lazy!- concerning what and how things are going to be accomplished.

Dealing with people near you (i.e. below) is relatively easy, in despite of the team’s size. That’s basically because the control of the process is in your hands. Problems starting to appear when you’re dealing with the client, especially when talking about sensitive topics like budget, commitments and deadlines.

The further the counterparty is from IT, the more complicated it will be to align expectations and, because of it, saying no. There are sticky situations when the project is already late and new resources are allocated onto it to match deadlines. It’s simply doesn’t work, because the train is already off track. It’s Brooks Law, nine women can’t make a baby in one month. Instead, it’s your job to accept the new resources, but clearly state that adding resources won’t necessarily make you meet deadlines. Then, make a plan to define the best way to get back to stakeholders telling them no, the deadlines the way they are set, won’t be met. If that’s the first time you’re saying no to your stakeholders, ask your manager / mentor for assistance. Don’t be ashamed of asking for assistance. Instead, your manager might get more comfortable with your candidness and realism. If your manager gets you the wrong way, think twice about this manager.

Another common problem I’ve seen several times is clients pushing to change specifications a couple of days before a release. Let’s say they realize a functionality that was designed didn’t fit properly their expectations. There are two possible root causes for it: or the project plan wasn’t clear enough and the team assumed the task in the wrong way (a requirement misunderstanding) or the client forgot / wasn’t aware / overlooked the functionality. On the former, you’ll need to swallow the problem and do your best to fix the problem. On the latter, however, you can stick to the plans. As stick to the plans I mean that you can get back to the client and agree the best way to have this functionality corrected without impacting the schedules. It’s likely that the client will still want you to ‘do a small adjustment’ for the release planned for tomorrow, bypassing tests and a lot of other important quality gates. It’s an opportunity to say no if you’re not comfortable with the change. Thus, you’ll need to agree what will be impacted: the scope (removing from this release the functionality), the deadlines (in order to have room for all required quality assurance process) or the risks (there’s a chance that the user will sign off the change even after you state that’s likely that it might cause problems). In the end, is your duty to say that you won’t take the responsibility for a problem that wasn’t caused by the team, shifting the responsibility to the client.

There are cases also that your managers may be asking you for a project status, saying “are we on track”? If for any reason, you believe that further down the road, there’s a slight chance that things may go wrong, openly advise your managers about this concern. Better safe than sorry. Always have your managers aware of the more realistic scenario as possible, as it might help you in the future. It’s frustrating to have a project off track, but is far more frustrating – and painful to everyone involved – to discover that the train is wrecked… only when it’s already wrecked. Remember that your manager might be reporting the project status to his own managers / directors, and he’s relying on your project status. And if something goes wrong, remember that’s not you being blamed, but a whole chain in your company being blamed as well.

Success!

Share and Enjoy

No comments yet.

Leave a Reply

Email
Print