Tag: DEADLINE

--Originally published at Meeting the Deadline

For me, this chapter is special, because it gives us a perspective not many people have, or at least one that many ignore or doubt the truth behind it. And it is important because it applies to the real world and to our very lives.

As the title of this post says, ambiguity implies unresolved conflict. But what does this mean?

It means that, instead of resolving conflict (regarding projects, among people, or even in oneself) people paper over it with ambiguity; because ambiguity evades commitment, responsibility. It’s like a patch that “works” for political reasons, or just for making a deadline. But there is no real value to it, and when the time comes to really understand the situation, one can only get confused.

That’s the case with documentation the gang is analyzing and reviewing about a very important project that never saw the light of the day.

The documents are large, they say nothing, and they are supposedly specification documents.

In reality, a specification is a statement of how a system (a set of planned responses) will react to events in the world immediately outside its borders. It is basically a set of inputs, outputs and the reasons behind that transformation.

Sometimes, people can enter conflicts, of interests, ideas, you name it. When that happens in a project and a specification must be delivered, ambiguity is the most used tool because it allows the creators to avoid being specific and technically “get the job done by not disagreeing with nobody”. But his is dangerous.
Not only the documents are useless, but the whole project; that ambiguity can lead to failure, in both project management and the real life and real relationships.

For that, one must avoid it. How, you could say? Continue reading "“Ambiguity implies unresolved conflict”– Chapter 16"

--Originally published at Meeting the Deadline

It is what it is. People can’t think faster, wait faster, or work faster, even if pressure is applied to them.

(Did you hear me, stupid Belok? You’re crazy for wanting people to work all 7 seven days a week with overtime! So selfish)

This is not only obvious or trivial, but it was modeled by Mr. T and Belinda. With data recovered by Waldo (Mr. T’s assistant) from older projects done in Morovia, they could uncover and prove that higher pressures or impossible work conditions can’t accelerate a project’s speed or efficiency.

On the other hand, they found something rather curious:

Overtime makes people work less!

Funny it came out, because this very thing is happening to me right now in my job.

Turns out people who do overtime tend to say “Meh, I can do it later at night, it’s okay”.

But no, it isn’t. By doing this, the work done in regular hours is of less quality and/or quantity due to the “flexibility” that the new added hours present.
Instead of the goal that is really work the paid hours and deliver something of value.

So, what’s the alternative here?

Send people home. For real.

All managers should state that employees should not stay up late doing work. They should turn off the lights and say “everybody OUT”.

Maybe they usually apply pressure and overtime because they don’t know better, or they’re afraid of the difficulty that other methods present. But reality is one must do what’s right and what’s best , for the employee, for the company and for the project.

So, no more overtime and no more slacking.
From now on, I’ll only work on the designated hours. Afternoon hours won’t be used as overtime no more.

Thanks Continue reading "“PEOPLE UNDER PRESSURE DON’T THINK FASTER” – Chapter 15"

--Originally published at Meeting the Deadline

I love being at peace the most.

With ongoing projects following their track, things being taken care of, enjoying the early results of good work. And even more if I reflect about this surrounded by nature?

Who doesn’t enjoy a peaceful walk in the park? A quick stroll perhaps?

Anyways.

That’s how this chapter started. Right in the middle of a peaceful reflection and tasting success as it develops.

Then sh*t got LIT.

After Mr. T was at peace with the decisions made, he encountered a mysterious and nasty figure in his office. Turns out NNL and Hoolihan are in a business trip in the USA, and all that’s left to “run” the country is Minister Allair Belok, NNL’s emissary.

He discusses (and by discuss I mean yells and gives a stupid monolog with a horrendous agenda) with Mr. T the deadline he set for all the projects to be delivered. It appears Belok will cut it in almost half and will dismember without care the 18 teams Mr. T formed just to unify them under one humongous team for each of the 6 projects and dismantle the Project Management Laboratory. Mr. T rage intensifies with each word Belok says, but ultimately agrees to his demands (in order to keep his head in place).

After that, Mr. T discusses with his star team their chances of keeping the lab running AND keeping his head on place while doing so.

With that conversation, one of the most important lessons of work-related content that I’ve learned arose:

“If you’re not willing to put your job on the line, your job is not worth having”

Mr. T said.

I know that’s some serious and Continue reading "“You don’t accomplish anything by standing in front of a train” – Chapter 11"

--Originally published at Meeting the Deadline

This chapter felt like an extra episode of a running tv series, one where the main character goes off the main course of the story arch to achieve some goal or check on someone who can give her/him some insight about something, and then on the next episode they return accomplished and triumphant.

Or maybe more like a The Legend of Zelda mission in the same way. Where link goes on a mission and finds valuable intel or a new tool that will aid him in the rest of his adventure.

It was like that for sure.

Mr. T travelled far (not that far really) to attend some business when he met a friend of a friend (that’s all I have to say about mister I-came-out-of-nowhere) that gave him a tool that could aid him in his business venture (see? Just like Zelda).

Turns out the friend of a friend of Mr. T was developing and testing some new innovative tool that could model project management processes, but he needed some input data (it was funny when mister new guy made Mr. T angry with his comments about irrational management decisions. It seemed necessary though in order to force Mr. T to give the correct data).

By modeling processes based on the hunches of an experienced manager such as Mr. T, they arrived at important conclusions about how to improve certain processes and model even more, and discussed some of the following:

The manager must be concerned every day about the trade-off between people and time; about the possible productivity a team of n members can produce and how it can be affected by team members coming and going.

Continue reading "“Modeling hunches” – Chapter 10"