There are a lot of things you will never expect, but being a leader is a natural process and gives you the opportunity to jell with your coworkers. In some cases, they might become close friends. It’s easy to become a manager, but the real challenge is to become a good manager and a leader. Of course, this path is very hard and very demanding. Time is going to be always behind your back and you’ll have to push yourself to the limits. Only to find that this is not a work for anyone.

23 Chapters are enough to express this and the author doesn’t hesitate to write about it. Tompkins, Lahksa, Belinda, Aristotle, and the other characters are awesome, they always have something to teach you.

The truth is that it’s kind of sad to say goodbye to such awesome characters, but that is what makes The Deadline: A Novel About Project Management such a nice book.

If I have to say something is that I’m kind of sad because the Deadline is almost over, I had a really nice time reading this book and I have to say that I was very surprised at the beginning of it. But let’s get down to business.

Chapter 22 is an emotional rollercoaster, of course, everything has to come to an end, but to be sincere I wasn’t expecting this kind of chapter, Tompkins has been released from its contract, as well as Minister Belok, and to be honest, I couldn’t be happier about the fact that Belok is no longer the Minister of Internal Affairs. But there’s more to take into consideration from this chapter. 

At the very end of the chapter, Belok talked to Tompkins and he said that he was going to change the company to a Lean and Mean formula, this is a formula followed by failing companies, which is the opposite to any organization’s natural goal. In other word is the result of a Failing and Frightened company. And of course Morovia’s Inc. wasn’t a failure.

Overstaffing is never a good option. Chapter 19 talks about the problems with overstaffing, in this case, we had the opportunity to learn that the problem with this is that you have to give all your staff something to do, which in some cases is not the most useful thing to do.

For example in the case of design, in this case, maybe the best thing to do is to have four to five people working on that stage of the project, but you can’t keep a hundred developers on wait until you finish the design stage, this is not useful.

In fact, in some cases, if you do this you can tear apart a team, and lead them to increased interdependence, rework, or frustration.

In conclusion, Overstaffing is not a good option. The ideal way to deal with a project is to start with a small staff and to increase it during the process.

If there is something you have to be sure about is that you always can improve your projects. In Chapter 20 we talked about how to improve your meetings. To improve them the best thing you can do is to keep them small since a humongous meeting is not a good option. All the meetings should have a ceremony and a published agenda, this way you can ensure that your attendees are going to get hooked into the meeting and to make sure they are interested/prepared for the topics that you are going to speak about.

We also had the opportunity to learn that Anger is the same as Fear inside the workplace and this is often because the manager is overwhelmed with his project.

But there’s more!

We had read 21 Chapters and finally, Minister Belok is off the table, but this doesn’t happen often in real life, the truth is that you can’t expect to cure pathology from beneath, in a lot of cases you are not going to be able to resolve problems caused by pathological politics. If this is the case the best thing you can do is to bide your time, waiting for the problem to resolve itself, or for a good opportunity for you to move on.

A thing you cannot ignore is conflict. Conflict is everywhere! and in an organization is an important thing to tackle. Since conflict can be the difference between the success of your project or its own failure.

Of course, there are ways to resolve conflicts. One way is the negotiation, but as the book says, “Negotiation is hard, mediation is easy”. Negotiate means that if you give a part, you lose another part whereas Mediation means that both can achieve something without losing.

Conflict is not an unprofessional behavior as everybody might think. Conflict is when two goals might be one against another, but this is often false since they both will help achieve a bigger goal.

Of course, if you try to resolve a conflict you need a catalyst. A catalyst is a person that can contribute to projects by helping teams to form and gel and to remain healthy and productive. A catalyst job is essential, for it helps to mediate during conflicts.

And obviously, if you are trying to solve a problem, the most important thing about it is that the parts accept you to mediate between them, you cannot force them to be jell, and of course, it’s almost impossible to act as a catalyst if you are a boss, this will pressure them and might cause more problems.

Often things are not what we like. And this applies to everything, whether you are a project manager or a programmer this will happen.

Of course, reading specification documents are not safe from this. On several occasions, you might find a lot of ambiguity in a document, this is a big problem at the time you try to read the document because this doesn’t give you insight about what to do. This problem is caused by unsolved conflicts among various system stakeholders. But even if a specification is ambiguous, you need to find sense in it. 

If you have trouble finding sense in a specification document, this might mean that the document is nonsense and it is not worth reading. To identify this kind of specification document you only need to check one thing: Check if the document has a complete census of inputs and outputs. If a document does not specify that there is a problem, it does not start to specify, and because of this, it does not specify anything at all.

The problem starts with the document of course, but if you have employees reading a specification document of this kind they will not tell you if the specification is lousy. Instead, they will blame themselves rather than the paper.

To solve the problem with the specifications, the first thing to take in place is to speak with your stakeholders, apply other techniques to solve the conflicts between them, model a good specification document and then finally to pass them to your employees, try to reduce the ambiguity the more you can.

They are lots of ideas about thinking fast. One of the most common ideas is that to increase productivity is to implement a lot of pressure over your employees, but that is not a good idea.

The Deadline: A novel about project management talks about that precisely, PEOPLE UNDER PRESSURE DON’T THINK FASTER. Actually, the more pressure you apply to your work the more likely you are to burnout, or to lose your interest in whatever you are doing.

Another common idea is to extend overtime during your project, but this is a tactic that usually reduces your productivity. The truth is that if you want to be productive you cannot be pressured or spending more hours in your work. 

Sometimes you can apply a short burst of pressure in order to focus, people and increase the sense that the work is important but extended pressure doesn’t help at all.

If the book actually said something that is 100% true, is that “Programmers are natural Cynics, Like Cats”. I personally think that in a way we all are natural cynics, but especially programmers. Since programmers are so used to pressure, they don’t usually care about how much pressure there is, and they choose to handle their respective situations in a lot of different ways.

Here lies the problem of project management for software projects, How do you handle pressure in your employees?, What can you do to be more productive?. The answer is quite simple: Work your respective hours, don’t stay overtime and maybe put a little pressure at the beginning, but certainly don’t kill your employees with pressure, this will not help their productivity.

Sometimes you really should take numbers into consideration. This chapter Mr. Tompiks had the opportunity to meet T. Jhons Caporous, described as a genial man with sparkling eyes who seemed to be running at an internal clock speed at least twice that of a normal human.

Even if they were only four and a half hours together they had a complete revelation about their project. They needed to size every single product and they didn’t have a single metric before!

The visit of Mr. Caporous helped them to get special units that allowed them to measure every single product, this metric is called Function Point.

Sometimes you can’t have all the data you need, at that moment, you could collect archeological data to see if your productivity follows the same trend as the ended products.This Points helps you to measure the productivity of your actual project, something vital for big projects.

Having a good process, or trying to improve your process is always a good thing to do. But even if it’s good you have to take into consideration lots of things. This Chapter of the book The Deadline: A novel about project management talks about it in a special way.

Actually good technical workers will focus on improving your project. It doesn’t matter if you tell them to do it or not. One thing you should consider is to use formal process improvement programs. But they cost time and money, and they are not perfect at all.

In fact, during this chapter, Tompkins discovered that the awful Minister Belok stands in his way (again) and sends the MSEI to audit the programs. During the auditions of the first building, Tompkins discovered that some of his employees were using a different approach to tackle the problem, but this doesn’t please the MSEI. In fact, several employees are using similar techniques. For example, the PS-Shop-C Manager actually used Photoshop’s manual in order to establish functional requirements, but they also applied their knowledge to write the non-functional requirements. Once they ended this process they ended up with an unorthodox form, but with excellent content.

This shows that the danger of standard processes is that people will miss chances to take important shortcuts, particularly on overstaffed projects.

The Following Chapter has the most important thing I have ever read about. During this chapter, Tompkins took the decision to talk to Prospero Menotti, the Director of the MSEI. To his surprise, Dr. Menotti was very young, and during his talk, he made his petition. It has a very unfortunate event, but Dr. Menotti was unable to do what he wanted. That caused Tompkins to go to Dr. Menotti’s superior, the Morovia’s First Programmer, Aristotle Kenoros.

Aristotle was hoping to see Tompkins and agreed to do what he wanted, with a condition, he wanted a job. Tompkins gave him the job to teach the teams a thing or two that they needed. This is where the fun begins.

Kenoros proposed a technique called Last Minute Implementation. This technique consists in spend 40% or more of the project doing an elaborate, exaggeratedly detailed low-level design, and the rest of it coding. This allows you to spend less time debugging and to end faster in consequence.

The things we can rescue from this chapter is that you can get projects to perform substantially beyond the norm by making reductions in the total amount of debugging time (this can be achieved by spending more time on design). And finally, there is one last thing I really liked about this chapter, and that is that you can’t get people to do anything different without caring for them and about them. To get them to change, you have to appreciate where they’re coming from and why.

Sometimes you have to admit that not all the people during is useful. The problem with this is that maybe the problem can be your employer. Such is the case of the Minister Belok.

He is an ambitious man that does not listen to reasons. He is not able to see the big picture, and of course a knucklehead.

This kind of person is very dangerous when they are above you in a project development. They like to establish Pathological Politics and once they do that you will have to be willing to put your job on the line any day, but even if do so, you will have problems. Often this politics are characterized for being goals of personal power and for try to override the natural goals of an organization.

The problem with this kind of politics is that it becomes unsafe to have a small development team.

An of course, as well as Mr. Thompkins you may have only one option: To do exactly like they told you. This is often a bad approach, but sometimes it’s the only way.