A Project Manager's Diary

I once used a very weird technique with my team to get things done in a short duration in a project that was very far away from being on schedule… For a while I’ve been asking my team for their progress, following up heavily and on daily basis, staying late with them in the office and sometimes staying till the next morning (online from home), trying to dig deeper by developing and testing with them…. And still we were very late in achieving any of our internal milestones… By time, I was empathizing them and I was trying my best to reduce the effect of the pressure under which they were put for a long time. We started a weekly game competition with some funny yet work-related rules, amongst which was “ each member in a sub-team should finish his work before the day of the competition ”… it went fine for about 3 weeks, then the situation became worse… and we all stopped participating in the competition… I then tried another technique… I started buying them either lunch or dinner in

That is the question! As implied by its name PMP (Project Management Professional), to obtain such a certificate you should be a professional in the field of Project Management… To my surprise, almost 95% of the people I met holding this certificate know nothing about Project Management!! They think that studying for this certificate and obtaining it means they are professional, although they should be professional to deserve such a certificate. I understand that one of the prerequisites to get this certificate is to have some practical experience in the Project Management field. But for some odd reason, I discovered that the people I am talking about, which are a majority in the field now, don’t really have experience, some of them are even fresh graduates… I once had a very aggressive argument with a “ kid ” in my team, and by the word “ kid ” I am referring to his age and his attitude in despising my knowledge and experience due to his ignorance, he was very aggressive and arrogant

Sometimes referred to as the Triangle of Horror… where the PM tries his best to maintain his balance while walking on the very thin project rope between this triangle and the Project Constraints Triangle (time, cost & scope). The triangle sides represent: The Team, The Client and The Management Every side of this triangle is obsessed by the sole idea that the other two sides want him dead, i.e. the team thinks that the client and the top management want him dead and vice versa. Usually a good PM gets lost while trying to maintain this triangle in good shape to keep all parties satisfied and happy while making them think they are his first and only priority to get out what is needed from them for the sake of the project. From my perspective, this is a much harder balance to keep rather than maintaining and managing the Project Constraints Triangle… It highly depends on people, their culture, maturity level, and on the PM’s ability to understand this and deal with it in a

They took some time to plan for the trip… They drew the road map, bought some food and beverages… and got equipped with the necessary tools… They were going to travel through the woods to draw the magnificent scenes which were observed by their neighbors early this year… This wasn’t their first trip together as a team, though they were all excited… The bus driver was in charge for making the big decision in the trip while taking care of the travellers’ team while of course driving the bus and communicating daily with his supervisor in the station. The map was clear, the weather was very well studied, though the bus driver expected to pass by some pitfalls in the road as there were some reparation in the way. He reported this to his supervisor and requested to take some more supplies just in case they have to camp one or two days more, but the supervisor refused “ the trip has to be completed on time and the painting should be ready for sale by the end of the week ” Anyways,

By experience -the bad one of course- I discovered that the famous Project Management triangle is missing a very important containing circle… The Strategy Circle . The Strategy Circle is my simple explanation for many of the catastrophic situations projects end up with. I totally believe that this should not happen and that Strategy exists to set goals and directions for the benefit of organizations and accordingly for the benefit of projects and teams. Unfortunately, I witnessed many cases where it was exactly the opposite. I was an eye witness of the failure of many projects and sometimes companies because of misunderstanding the meaning of Strategy and how to use it to bring companies to success. Some companies bankrupted because of this! De-formation Effect The Strategy Circle is sometimes surrounding the Project Management triangle and thus imposing pressure on it and suppressing it and some other times it is pushing on the triangle from the inside and thus inflatin

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

In addition to the very well-known techniques/lifecycles for project management, I found out that a new technique emerged lately. This new technique highly depends on performing project tasks and phases in a reverse non-organized order! This is known as the Project Baxecution (Project Backward Execution) concept. It embraces the following practices in addition to the Surprise factor which is a common factor at the end of each stage: Deliver the project before getting the requirements (because it is not important!) –> Client is surprised Test the project after receiving some of the requirements –> Testing team is surprised Develop the project after reviewing bugs –> Development team is surprised Plan for the project –> Top management is surprised Gather the project’s requirements –> Client is surprised again Restart the project in the same order, kind of Spiral Development model –> Everyone is surprised!! Just to clarify, this is a stand-alone technique that

A friend of mine used to classify projects into 2 mutually exclusive categories: Strategic or Political projects Profitable projects At first, I thought this classification was a joke, but after some contemplation, I found that it is very true… Most or almost all of the projects I worked in fell under the first category (strategic). This means that I was either always chosen to work in such projects or that all projects are strategic non-profitable ones!! Which of course cannot be true, so, let’s stick to the first assumption! Strategic Projects Characteristics First of all they are… Strategic! Either start with quick-wins or are major-projects Non-profitable Low or no price quotation offered with pleasure to clients Very tight in time Killer teams are allocated on them Strategic importance and priority only apply on the team who works in the project, i.e. not on other needed helper functions such as IS, DB or Operations teams Teams working in them are burned o

Everyone asks for a strong project manager... When they get him they don't want him! By definition, a manager is “ the person responsible for planning and directing the work of a group of individuals, monitoring their work, and taking corrective actions when necessary ”. The Project Manager in the field of Software Development is a very special type of manager… I mean this when I think about the people who really care about their work and carry it out as it should be… From my point of view, I think these people are very rare to find. They are always put under the stress of delivering successful projects despite all obstacles related to pleasing their clients, top management and teams. Super Man-ager Or in other words, the Invincible Hero known as the Project Manager should possess a countless set of qualifications… He should have the: Wisdom of Confucius Brilliance of Albert Einstein Courage of Gandhi Endurance of Jacob … The PM should also be able to contain all

The more you know, the more you know there will be more to know! I found that in practical life, a project is a group of upside-down events and tasks. It is as much as if you are walking in Wonderland… People’s knowledge, way of thinking, decisions and behavior are countless and weird, accordingly, projects -which I consider kind of living creatures- follow people… and the results are well known in such cases! I discovered that bad practices usually take 2 years to be moved from the frustration memory to the experience memory. By time, the 2 years period -based on some self-extensive training- can be eliminated. It is also proportional to the duration of the bad practice itself. I used to believe that everything I see in a project is the utmost extreme of all what I saw and that there will be no odder situations to face, though this thought was proven wrong by time… I keep meeting and seeing new Wonderlands and new project management adventures! I was thinking about naming the blo

Some people consciously choose to fail! Usually people write about their success stories… Well, I decided to write about what I call my failure story . You can consider this blog as part of a documentary book on the quickest steps and worst practices to attain failure smoothly! From my point of view, a good and very fast way to failure starts with having to deal with uneducated not willing to learn people who reinvent the wheel in everything they do while thinking they are making great achievements for humanity, which is of course by going many steps backward! Such people highly rely in their work on the concept of pretending to be smart and on applying theories in very wrong ways. This always ends with catastrophic failures in projects accompanied by huge financial losses. In our contemporary life, these people are not rare, I think they invaded and dominated the fields of Software Development and Software Development Management, though there are still many many good people who

My awareness with the field of Software started in my early childhood. Engineering Symptoms Some engineering symptoms started appearing on me when I was a kid… At first, I was staring at things for hours without talking… My father told me that he was always wondering “ what’s going on in her mind! ”… Sometime later, I started disassembling things, starting from toys and ending with electrical appliances (radio cassettes, washing machines…) and using the spare parts to build something else. I sometimes just disassembled machines just to rebuild them after a great exploration phase. I was kind of danger, but my folks liked this. I also used to sketch weird drawings for images in my mind till I was introduced to my first PC at the age of 11. When I saw it, new ideas started formulating in my head, I was reading a lot, and I wrote my first computer game at the age of 12, it was kind of strange for people around me but I liked the idea a lot and I decided to be an engineer, a computer’s

I am a Project Manager and I love my job… I am a project Manager and I love doing my work! I am nothing more but a Project Manager amongst many others. I got married to my work (not job) after a great love story which started from early childhood ( coming soon ). I started my career as a Software Developer in the late 90s, then held many positions in the field of Software Development, some were promotions and some were kind of additional assignments due to my performance. Among the positions I held are Developer, Team Leader, Project Manager, Project Leader, Senior Project Manager, Senior Project Leader, Program Manager, Business Analyst… though I was dreaming about becoming an Architect! But seriously the job I loved the most is Project Management. The things I hated the most in my early years were politics and economics/finance, which both became the core of my daily work for some years now! 94% of my experience was built by working in Software Houses as a vendor/provider and