As an IT project manager, recent events have led me to rethink who and when a PM is needed, wanted, required, necessary. I had almost always believed that the addition of a PM in a large project could only be good. There are exceptions to this, as I recently learned.
Get along with the Customer at all costs: During the collection of requirements, scope writing and understanding timelines, there will be times where you may not 100% agree with your customer. For their long-term benefit you negotiate an agreement. The customer should understand that this negotiation is for their benefit.
This is not always the case. You can always agree with your customer and never have a disagreement. However, for their long-term benefit this is not always good. Customers pay you for your advice and if you withhold it for the sake of getting along, you do them a disservice.
Customer has no Set Budget or Timeline: I usually work in an environment where there is a set budget and a set timeline. It is the PM’s job to ensure that neither of these are exceeded. Change management is used to handle unexpected changes to scope and new requirements.
If your customer has not set a budget for the project, has no expectation of how much the project will cost, or does not mind paying more for no additional functionality or utility, you do not need a PM.
It will get done when it gets done. Just send me the bill.
If you have a very trusting relationship with your customer this may be very workable. When the customer grumbles you can smooth it over with happy, relationship building talk.
Managers that do not need to know a project is going south, until it is inevitable: This is almost always not the case. Managers do not like surprises, particularly surprises that cost money or extend timelines, which usually costs money.
If you know of a manager that likes the odd surprise that a project will overrun its budget, and likes being told this at the deadline of the project, please let me know.
Requirements are Extremely Exploratory: You may find yourself in a situation where your project can go in any number of directions and it is very difficult to even comprehend writing down requirements. I am sure there are some rare situation where this occurs, but for the vat majority of projects this is simply not the case.
The Job of a PM: As a PM, it is my duty to look after the long-term well being of my customer. I try to look beyond the present and try to predict what could happen in the future. I assess risk and try to mitigate them. Projects almost always have a budget. In many companies you are not allowed to even start a project if you do not have a budget. Timelines are almost always set so that the manager knows when to expect some functionality to be ready. Maybe business requirements can be done more efficiently. I look at all these things.
These checks and balances are fiscally prudent, and meant to reduce wasting precious resources such as business analysis, development, testing and rollout. If you are concerned about efficiency then a PM is your friend and best person to help your project.
In rare circumstances a customer may request to do a project on a piecemeal basis, writing requirements if and when they are discovered. These projects are what I would call “time and materials”, where you bill by the hour. There is no start and end dates and no real scope. I have experienced such projects on rare occasions, and they all have ended badly. The customers of these projects believed they had the methodological rigour to keep the project on track and the dedicated resources busy. Most of these projects fail to achieve their desired outcomes, have finished prematurely after going way over their budget, or both. The past project of this nature ended 400% over the initial estimate. From experience I believe that these projects simply do not work. IT people are trained to methodically assess a statement of work, to tidy up ambiguity and to find the most efficient path to a solution. In general these skills are rare.
Sometimes the rigours of PM might require you to question and reassess your customer and their work methods. This is all part of the process of increasing efficiency, to increase value for money invested. It is in the long-term interest of your customer that you adopt these rigorous measures. It is sort of like “tough love”. Hopefully you are a reasonable PM and your customer will see the benefits in the near future.
Sometimes the PM wishes to introduce measures that will increase the efficiency of the project. This is not an ego boosting exercise, or that the PM wishes to “be the boss”. This is the PM’s job, for without these recommendations the PM would be negligent. For some people the PM becomes the bearer of bad news. Like an auditor, there are times when standing up for your duty can get dicy, but stand up you must, because this is your job, your calling.
When team members are experienced and work well together as a cohesive unit the PM may have little to do other than track the start and completion of work. At the opposite extreme a project that is at the verge of falling apart will need drastic intervention. Without bold steps the project will miss its deadline, blow its budget or both. Like an exorcism, one needs to call out the guilty and send them on the right path. At the very least a PM should inform management as early as possible when there is a problem, how large, and when you expect the problem to be solved.
Project managers follow a school of philosophy, one of efficiency and timeliness, one where risk is predicted, identified and then mitigated. The job carries risks if your manager does not share the same philosophy.
Please do not kill the messenger.
2023 Mar 16 Over budget, way behind: Why we’re so bad at getting big things done
