TI2011 Spring 2020

--Originally published at The Awesome Blog

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.

--Originally published at The Awesome Blog

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.

--Originally published at The Awesome Blog

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.

--Originally published at The Awesome Blog

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.