A Project Manager's Diary

I remember that once a team member asked me to go home, sit in the balcony and have a cold drink till they finish the deployment and then call me! I was really offended by this thought and attitude because I really care for both my teams and my projects. Other teams I dealt with refused to listen to me even before knowing me, just because they hate PMs! As previously explained and recommended to managers, there are reasons for which they shouldn’t listen to their PMs . These same reasons constitute a solid base for teams not to listen to their PMs too… “ A PM cares about his projects and is keen to develop them as per the planned budget, time and scope. ” Well… here’s why teams should not listen to their PMs in more details: 1. PMs are Time Wasters PMs use the help of their teams to study projects, their feasibility and estimates to produce plans. All these activities are time wasting from some team members’ perspective… Many teams think they can start coding right away to produce

Who are Pretenders? Simply these are the people who Pretend … Pretenders can pretend anything in the world. They pretend they understand and they claim they are experienced. They think they are superior when compared to others and they want everybody to obey them blindly. Most of the people I met falling under this category were consultants or acting as consultants. Pretenders are characterized by the following: Think they know everything in the world Think that books contain everything Have faithful beliefs in theory and nothing but the theory Use theoretical definitions heavily Believe in all best practices Use the word should a lot… they believe what books say, no what facts prove Have an amazing superiority feeling, which may be coming from studying definitions by heart or from hiding behind their many certificates They are Theory Relatives I guess… otherwise, they might be breathing theories! Also, they: Are logical but not reasonable, while others may be r

Usually a PM cares about his projects and is keen to develop them as per the planned budget, time and scope. However, managers should not listen to their PMs for the following reasons: 1. PMs are Time Wasters PMs plan… They study and mitigate risks and project issues in proper ways to guarantee the smooth execution of the project. Planning is a bad practice that PMs should stop using and referring to whenever they discuss a project related issue. Plans are not really needed and in most of the times they are useless because no one follows them (all gratitude and respect reserved for PJs). Also, it is preferable to face risks when they fire. Anyways, who really cares for risk mitigation and contingency stuff! Let’s face surprises when they arise and use panic mode to push on teams to solve their issues! 2. PMs Forecast PMs track their projects and use trends, issues, project and client historical data to forecast project status and use corrective actions properly to maintain thei

Software is by far different than tomatoes! Software development depends heavily on the following factors: Requirements clarity Business complexity Client maturity Team understanding for the requirements Team experience Team productivity People mood Technology Aiding tools availability Company processes and strategy Any of these factors or the combination of these factors can heavily impact the project and its estimate. I am not saying that we cannot estimate projects, I am saying that we cannot estimate accurately, and even if the estimate is accurate, given other circumstances, the same estimate may not be accurate. The major difference between Software and other merchandises is that Software cannot really be measured. There were and are many efforts and theories trying to quantify Software and measure it, yet there is nothing accurate. Software can be measured by complexity, lines of code, effort, features, points… too many theories and models, yet none of

“ We need a piece of software ”… “ ABRACADABRA ”… “ Et voilà, votre software est prêt * ”… A perfect Software is up and running in no time! Is this possible? Till now, I haven’t seen this in custom development projects, specially that most of the projects I worked in varied between medium and large sizes projects (we’ll talk about projects’ sizes in details later). The majority of clients believe that Software is Magic , they think that developers just dream about the program code and then it comes to life with no effort… We all wish we can reach this stage, but unfortunately, the production of new software still takes time, effort and money… Software is maturing… People are not I remember when I was a kid and I started learning programming, I invented a language of my own and I used it to write my diary. The language was simply a set of symbols very similar to the Latin character set. People around me thought “ She is writing Computer ”, this is the exact sentence they used to descr

Who are Project Jeopardizers? As the name implies, these are the people responsible for jeopardizing your projects and accelerating their failure! They gracefully and confidently push projects to drift from their track to the disaster track. Project Jeopardizers (PJ) AKA Project Monsters are people who have authority and who, for some odd reasons, have a say in your work, and can destroy it completely by the directions they give and the decision they make. They usually help driving projects to their catastrophic ends or in the best cases they lead projects to disastrous situations only! These people run afterwards and disappear from the picture. They also exist in the background of every team project photo. In most of the cases, PJs think they are doing this for the benefit of the project. They are also the first people who panic in stressful situations and leave everything for others to save. They are also very professional in transferring the blame to others, and they are the one