Agile development and generic project management both share the value of ceremony. It just looks different in each context. Any project should have approval points for scope, budget, resources, schedule, work product. That's just smart CYA. One thing Agile seems to hold up as a project management obstacle that has a great deal of truth behind it is a non-negotiable march to procedure, no matter what.
This happens more often than it should when PMs are not properly trained or are inexperienced without a mentor. These PMs show robot-like adherence to a list of best practices and templates by phase even when it makes no sense. These are the people who want everything boiled down to a checklist. To PMs' defense, I will say that I have worked under managers who mandated total, absolute, and literal compliance without question or thought because they themselves didn't understand project management and had never done the job in reality. They certainly were not open to hearing from actual practitioners. If you have the right template, a chicken can do this job! "Bok Bok" says the Hindenburg. What if your template set is missing pieces or hasn't considered some important element? Now what? What if your templates are just weird and wrong? E.g. I had a status report to use that wanted estimated end dates on risks. Risks haven't happened, so how am I supposed to know when it ends? It defied logic. I just put 12/31/YY to get it over with. The fight wasn't worth it. I did allow myself to think "this is so stupid" every time I had to fill it out. Or the manager who insisted on knowing baseline dates even though his staff never provided estimates. Smalls, you're killing me.
I don't care what kind of shop you're in or what the prevailing development methodology is, to be a really good/trusted/dependable project manager, you must understand the art and the science. You must THINK. You must understand why you need to do certain things even if there isn't a mandate from the boss. You have got to know how to assemble certain information even if there is no template. This is what separates the wannabes from the pros. It takes time and experience to get there. It takes doing it the shortcut way and paying dearly for it later. But he said it was OK in the meeting, why is he refusing to pay the invoice now? It also requires taking responsibility for what you failed to do - even if you didn't know. If you expect somebody to write all the things down that you need to know to do in every possible situation, you're never going to get it. But please, hold your breath and wait right over here....
I learned this lesson two different ways. One is by doing a root cause analysis on the issues list throughout every project. What *really* caused this issue? What caused that? What is the lesson learned out of this one? Be brutally honest. No blaming others. What did you as the PM not do (and I don't care why) that led to this problem? What question wasn't asked? What assumption did you run with? This harsh, but necessary reflection has much to teach if you can be open and objective. Find a trusted person to help you if necessary.
The second way is from becoming PMP certified. The training I did was hard for me and I left it feeling totally inept and quite low each day, but it was effective. As I was studying for the exam, I had an experience that was like seeing into the Matrix one day. It all connected and the lights came on. I can't remember not knowing any of this. Of course you need to make sure the requirements are possible and testable. Of course the project constraints translate into the risk list. Of course you need to sanity test the goals and objectives in the charter with deadlines and budget as soon as possible.
It's fine to depend on templates and best practices as a junior PM, or as someone new to an organization. After all, you want to score well on compliance come review time and there's no sense in being the lone wolf who just has to do it her own way. Aggravating the boss is not a good idea. But ultimately, you have to transcend and no longer be dependent on instructions to make your way. You have to recognize change when it's just emerging. You need to develop a Spidey-sense about issues and probe on them. You have to be able to read people and understand who is jerking your chain versus who is actually performing.
A day will come when you can explain exactly why you need to log decisions and approvals somewhere, some how. You can explain why scope exclusions will help you later in the project. Why unstated assumptions and beliefs end up making for low customer service surveys. It will be a great day! You will have the key to effectively working with customers and the team to make sure the project is doing the right things, the right way, for the right reasons. Parts of your job will become much less stressful. Your credibility will increase, and the people around you will know that when you have a project assignment, it's in safe hands.
This happens more often than it should when PMs are not properly trained or are inexperienced without a mentor. These PMs show robot-like adherence to a list of best practices and templates by phase even when it makes no sense. These are the people who want everything boiled down to a checklist. To PMs' defense, I will say that I have worked under managers who mandated total, absolute, and literal compliance without question or thought because they themselves didn't understand project management and had never done the job in reality. They certainly were not open to hearing from actual practitioners. If you have the right template, a chicken can do this job! "Bok Bok" says the Hindenburg. What if your template set is missing pieces or hasn't considered some important element? Now what? What if your templates are just weird and wrong? E.g. I had a status report to use that wanted estimated end dates on risks. Risks haven't happened, so how am I supposed to know when it ends? It defied logic. I just put 12/31/YY to get it over with. The fight wasn't worth it. I did allow myself to think "this is so stupid" every time I had to fill it out. Or the manager who insisted on knowing baseline dates even though his staff never provided estimates. Smalls, you're killing me.
I don't care what kind of shop you're in or what the prevailing development methodology is, to be a really good/trusted/dependable project manager, you must understand the art and the science. You must THINK. You must understand why you need to do certain things even if there isn't a mandate from the boss. You have got to know how to assemble certain information even if there is no template. This is what separates the wannabes from the pros. It takes time and experience to get there. It takes doing it the shortcut way and paying dearly for it later. But he said it was OK in the meeting, why is he refusing to pay the invoice now? It also requires taking responsibility for what you failed to do - even if you didn't know. If you expect somebody to write all the things down that you need to know to do in every possible situation, you're never going to get it. But please, hold your breath and wait right over here....
I learned this lesson two different ways. One is by doing a root cause analysis on the issues list throughout every project. What *really* caused this issue? What caused that? What is the lesson learned out of this one? Be brutally honest. No blaming others. What did you as the PM not do (and I don't care why) that led to this problem? What question wasn't asked? What assumption did you run with? This harsh, but necessary reflection has much to teach if you can be open and objective. Find a trusted person to help you if necessary.
The second way is from becoming PMP certified. The training I did was hard for me and I left it feeling totally inept and quite low each day, but it was effective. As I was studying for the exam, I had an experience that was like seeing into the Matrix one day. It all connected and the lights came on. I can't remember not knowing any of this. Of course you need to make sure the requirements are possible and testable. Of course the project constraints translate into the risk list. Of course you need to sanity test the goals and objectives in the charter with deadlines and budget as soon as possible.
It's fine to depend on templates and best practices as a junior PM, or as someone new to an organization. After all, you want to score well on compliance come review time and there's no sense in being the lone wolf who just has to do it her own way. Aggravating the boss is not a good idea. But ultimately, you have to transcend and no longer be dependent on instructions to make your way. You have to recognize change when it's just emerging. You need to develop a Spidey-sense about issues and probe on them. You have to be able to read people and understand who is jerking your chain versus who is actually performing.
A day will come when you can explain exactly why you need to log decisions and approvals somewhere, some how. You can explain why scope exclusions will help you later in the project. Why unstated assumptions and beliefs end up making for low customer service surveys. It will be a great day! You will have the key to effectively working with customers and the team to make sure the project is doing the right things, the right way, for the right reasons. Parts of your job will become much less stressful. Your credibility will increase, and the people around you will know that when you have a project assignment, it's in safe hands.
Comments
Post a Comment