A little something about Project Management
Daily tasks, no matter if they are from work or class or home, necessarily need to be manage somehow. The main reason for this, is basically because things could go wrong if they aren’t managed. From the regular task of preparing breakfast in the morning (yes, it can go wrong; it has happened to me), all the way to developing a web platform for a big company, they need to have a clear process involving several stages of preparation, development and evaluation.
The brief introduction of Scott Berkun’s book, “Making Things Happen”, made me recall about my daily activities and how I’m able to manage them, most of the times, of course. Probably, the most important ideas from this chapter are making clear that (a), project management is not exclusive of software development or engineering, and (b), everyone manages something, at some point. I felt myself immediately identified with these aspects, because, even though I do have managed some software projects (alone or in team), I have also had the luck (for good or bad) of managing several events, design projects and social entrepreneurship projects as well. Looking at them now from a broader perspective, I have encountered myself with interesting insights when comparing them. These insights do match a lot from what Scott talks about in chapter 1, so in the following paragraphs, I will highlight the most relevant and related ones, particularly, focusing myself on what he describes as paradoxes, as well as for the involvement of a PM.
Paradoxes
The most common paradoxes I have encountered myself in PM situations, are regarding 4 particular ones from the list: Ego/No-ego, Autocrat/Delegator, Impatient/Patient and Courage/fear. I will compare both sides of the paradox briefly on situations I recalled when reading the chapter.
The first one is probably the hardest to learn, at least in my experience, and one of the most dangerous one. About 3 years ago (Jan. 2015), I was leading the ACM student chapter at my university. At the beginning I was not sure of why I was the head of the team at all, but as time went by, I managed to do stuff correctly. The team was working amazing as a whole, we were growing in number (like no other year, from 8 members all the way to 30, which I also learned was not necessarily good, but anyway) and the events/projects we were developing were having nice results. But, of course, it did not ended the way I would have planned at all. In comparison to when I started, my confidence was way better than before, maybe too much, and that became a problem. I guided the team to develop a greater scale and ambitious project (a “big” event, called Overflow), but at the same time, I also encouraged us to get involved with some other stuff that was not so relevant to the group, and I somehow forced the team to manage this even though they did not wanted to do it. Long story short: this lead to the team stop working as a whole, and the motivation felt drastically, leaving me alone trying to conquer a monster or, as Fred Brooks describes, we felt into the tar pit. Of course the event was a complete failure in terms of response from the student community but, on the bright side, I learned quite a lot from this experience. I would say is definitely one of my greatest failures in my not-so-long career as PM.
Regarding the other aspects, I will share a story that somehow talks about them all. Last semester I was working on a social entrepreneurship project for a class, which somehow lead me as a PM not by decision, but maybe because I was more experienced than my colleagues (who actually became close friends). It was an interesting mix between a software engineer (me), an architect, an internationalist and a biotechnologist. All of us were really polite and fomented the democracy in our decisions, but there were times where hard decisions needed to be made, and when I mean hard, I meant all the way to the point of changing the whole project. Here is where the courage/fear issue comes, we took the decision to change the whole idea of the project, 3 times! And every time this happened, it was harsh for the emotional status of the team, but I always tried to motivate them to go on, leading to the third issue about patience. Everytime something like this occurred, I always told them “Todo sale”, which meant something like “Don’t worry, everything will come out for good”. Fortunately, with time, they realized that hard work did actually payoff, and that this statement was true, for most of the situations; and, most importantly, they start relaxing but also focusing more on what needed to be done. We still had fear that things could go wrong, but we were certain that we took the decision for the best, as a team. In the end, the project was a real success (for the goals of the class).
As one might noticed, both examples are not-related projects to software engineering, but they do share a lot in common, from a more abstract point of view. Going back to the domains of computer science, I would like to finish this text by talking a bit more about the first chapter of Brook’s legendary book (The Mythical Man-Month). For most of the cases, the joys of software development overcome the woes that it involves, as long as we find rich and deep learnings from this counterpart. Because, as the book mentions, two of the main reasons of why programming is fun are that through coding we craft brand new stuff, and even better, people can benefit of it, of our creation. Of course, this necessarily will have obstacles in the way, but as long as the process (and its issues) do not overcome the goals, it will remain that way.
The brief introduction of Scott Berkun’s book, “Making Things Happen”, made me recall about my daily activities and how I’m able to manage them, most of the times, of course. Probably, the most important ideas from this chapter are making clear that (a), project management is not exclusive of software development or engineering, and (b), everyone manages something, at some point. I felt myself immediately identified with these aspects, because, even though I do have managed some software projects (alone or in team), I have also had the luck (for good or bad) of managing several events, design projects and social entrepreneurship projects as well. Looking at them now from a broader perspective, I have encountered myself with interesting insights when comparing them. These insights do match a lot from what Scott talks about in chapter 1, so in the following paragraphs, I will highlight the most relevant and related ones, particularly, focusing myself on what he describes as paradoxes, as well as for the involvement of a PM.
Paradoxes
The most common paradoxes I have encountered myself in PM situations, are regarding 4 particular ones from the list: Ego/No-ego, Autocrat/Delegator, Impatient/Patient and Courage/fear. I will compare both sides of the paradox briefly on situations I recalled when reading the chapter.
The first one is probably the hardest to learn, at least in my experience, and one of the most dangerous one. About 3 years ago (Jan. 2015), I was leading the ACM student chapter at my university. At the beginning I was not sure of why I was the head of the team at all, but as time went by, I managed to do stuff correctly. The team was working amazing as a whole, we were growing in number (like no other year, from 8 members all the way to 30, which I also learned was not necessarily good, but anyway) and the events/projects we were developing were having nice results. But, of course, it did not ended the way I would have planned at all. In comparison to when I started, my confidence was way better than before, maybe too much, and that became a problem. I guided the team to develop a greater scale and ambitious project (a “big” event, called Overflow), but at the same time, I also encouraged us to get involved with some other stuff that was not so relevant to the group, and I somehow forced the team to manage this even though they did not wanted to do it. Long story short: this lead to the team stop working as a whole, and the motivation felt drastically, leaving me alone trying to conquer a monster or, as Fred Brooks describes, we felt into the tar pit. Of course the event was a complete failure in terms of response from the student community but, on the bright side, I learned quite a lot from this experience. I would say is definitely one of my greatest failures in my not-so-long career as PM.
Regarding the other aspects, I will share a story that somehow talks about them all. Last semester I was working on a social entrepreneurship project for a class, which somehow lead me as a PM not by decision, but maybe because I was more experienced than my colleagues (who actually became close friends). It was an interesting mix between a software engineer (me), an architect, an internationalist and a biotechnologist. All of us were really polite and fomented the democracy in our decisions, but there were times where hard decisions needed to be made, and when I mean hard, I meant all the way to the point of changing the whole project. Here is where the courage/fear issue comes, we took the decision to change the whole idea of the project, 3 times! And every time this happened, it was harsh for the emotional status of the team, but I always tried to motivate them to go on, leading to the third issue about patience. Everytime something like this occurred, I always told them “Todo sale”, which meant something like “Don’t worry, everything will come out for good”. Fortunately, with time, they realized that hard work did actually payoff, and that this statement was true, for most of the situations; and, most importantly, they start relaxing but also focusing more on what needed to be done. We still had fear that things could go wrong, but we were certain that we took the decision for the best, as a team. In the end, the project was a real success (for the goals of the class).
As one might noticed, both examples are not-related projects to software engineering, but they do share a lot in common, from a more abstract point of view. Going back to the domains of computer science, I would like to finish this text by talking a bit more about the first chapter of Brook’s legendary book (The Mythical Man-Month). For most of the cases, the joys of software development overcome the woes that it involves, as long as we find rich and deep learnings from this counterpart. Because, as the book mentions, two of the main reasons of why programming is fun are that through coding we craft brand new stuff, and even better, people can benefit of it, of our creation. Of course, this necessarily will have obstacles in the way, but as long as the process (and its issues) do not overcome the goals, it will remain that way.
*Warning: excuse the simpleness of my post, it is intended for fellow students.
Comentarios
Publicar un comentario