So we all have needs, right? Eat, sleep, pee, poo, having a relationship, to be happy… The same happens with software projects. Employees, administrative personal, protect manager, and everyone involved in the process has their own needs. Steve McConnell relates these needs or rights with Maslow’s human needs pyramid. He describes that in some way there is a hierarchy in which the are some elements more important and even necessary to reach others in the upper levels. This hierarchy can be viewed as a pyramid.
It’s actually kind of self explanatory. I just want to address a couple of things. As I said before, in order to step up in the pyramid, lower needs need to be satisfied; in almost every case… Wait, so are you saying that you can jump some elements and reach the pick directly? Oh, I’m glad you asked dear reader. This pyramid expresses specifically software project needs, not personal needs, those would be different for each case. As an example of this changes, Steve compares it with a software engineer, an employee could have self-esteem just under belongingness and love, and it make sense. If you take a minute to read each step and think of an example, you’ll find that they are designed to be applied to a group or team.
I want to focus this chapters in my experience and perspective of the book, more than explaining what the book says and everyone just read. When I was reading this chapter, I found out that we were our priorities a bit confused in Taller Vertical at Tec. Its a week in which we form teams of multidisciplinary students and work on a real life project for a company. In this project, we didn’t even have survival needs, and we were worrying for the last two needs of the pyramid. We weren’t sure if could finish the project, we didn’t plan any working schedule, leading to a total caos the las couple of days and we were hoping to end with a first place project and being actually able to continuing working with that company just after finishing the week. That would fit in the last category, but not that high, even safety promises weren’t satisfied.
Later on in this chapter and the next one, McConnell talks about rights, for the costumer and for the project teams, which I found really interesting. The costumer, in the case I just mentioned, was Centro Medico Puerta de Hierro, their rights were kind of covered since they were the ones in charge of the event and they gave the requirements. I think their lack of interest was the element that broke some needs; but it was cause they wanted, for instance, to have the project status? They just showed up once after the project definition, and we just had five minutes. In contrast, the project teem rights, were just ignored. We didn’t have clear needs, we couldn’t talk to them and ask questions at all, ignoring the five minutes at day three, by that day we had already started programming cause otherwise it would’ve been imposible to finish at deadline time; breaking the fifth right of having your effort and schedule approved.
He also proposes a set of tests for all the areas that project management relates to, tests that I found really practical, they serve as a guide for your projects, the point I want to get in is what I get from this chapters, relating it to Taller Vertical. I finally know why we thought it was a disaster. We didn’t had any of our rights fulfilled, that was the reason. And the fact that we, as team leaders didn’t even score forty at the test, that could be another reason, but oh well…
It was till the next chapter that I found another clue on the mysterious cause my team had at Taller Vertical. Steve talks about the importance of planning in a really practical and easy way. He uses some graphics explaining the actual time a software project takes planing vs the time it works makes actual process. I will try to compare them with what we experienced last week. The first graphic shows the exceptions of everyone outside the world of project administration. Trashing is a concept used for that time in which, you are not planing the actual process, that is actually the bottom bar, but neither are you making process, it could be either fixing errors, or correcting old code for instance. What this graphic wants to note is the actual misunderstood normal people have, and the reason why they sometimes choose to forget about planning in general.
The second graphic is the reality. Is true that you invest a large percentage of time planning and trashing, but only at the beginning, when you have nothing planned. When time continues and the project evolves, there is no need to invest that much in planning, and trashing will actually be reduced, due to the well organization the project had at the beginning.
Now I’ll show the graphic that explains what happens when you don’t take the time to organize (the one on the left side). Those are the actually consequences. Its self explanatory. What is not easy to understand is what happened to my team at taller vertical, the second graphic on the right was our sad story. We didn’t even planned that much, we were just trashing code that at the end we didn’t even used, but at the end, omg right!? That is how not sleeping for the last two days is represented. Did we had a good plan? Definitely not, did we finish with a super cool project? Super duper project, did we enjoyed the nights without sleep? No… Tamales? Dos rojos por favor.
Diego's Password 