Project Management

[Kepler]

This is a thread about the practice of Project Management for those of us in the discipline either formally or using its techniques and concepts in their work. It's a Cafe experiment: a guild thread. Obviously anyone can post but please try to keep to scope and tone.

The subtitle of this thread is Let's Help Kepler Not Get Fired.

 

[jerphisch]

So Kep, just my opinion, and without knowing how many other PMs are on here hopefully this doesn't offend anyone but... First, PMI is a scam to take your money. I wouldn't spend a cent on it unless you are forced to. I find that in general the PMs who are deep into PMI this and PMBoK that are just enormous pains in the butt who are their to make everyone around them miserable. To avoid getting fired, just do everything you can to make your teams lives easier. Take all the blame even when it isn't your fault, and give away all the credit whether deserved or not. Everyone that works "for" you will say nice things when asked and you'll be fine.

 

[Kepler]

So Kep, just my opinion, and without knowing how many other PMs are on here hopefully this doesn't offend anyone but... First, PMI is a scam to take your money. I wouldn't spend a cent on it unless you are forced to. I find that in general the PMs who are deep into PMI this and PMBoK that are just enormous pains in the butt who are their to make everyone around them miserable. To avoid getting fired, just do everything you can to make your teams lives easier. Take all the blame even when it isn't your fault, and give away all the credit whether deserved or not. Everyone that works "for" you will say nice things when asked and you'll be fine.

Thanks. I certainly understand the PMI is the NRA -- an ostensible umpire, they are really in it to sell their own products. I am reading them primarily because (1) I am starting from cold iron, and (2) I don't know how pervasive their methods and terminology are so I want to have done my homework.

Being from CM, I understand that all methods and tools are guidance, none of them are prescriptive. You don't shape the job to the tool and you don't shape people to your management. In each case it is the reverse. I have a long way to go but hey I've read enough epistemology to understand that the only reality is other people and everything we think is just provisional models we can throw away if they come up with divide by zero.

I really appreciate the advice! I need it. I know everybody's faking and I am a confident person but I'm going to have a case of First Day of School Jitters for the ages after 15 years in a nice comfortable familiar job.

 

[St. Clown]

Project managers. My company used them once upon a time. Now they’re out of budget. And the latest project that I had the displeasure of working turned into a real shit show.

 

[MichVandal]

BTW, what's a CM? I was going to ask that in the other thread.

 

[Kepler]

BTW, what's a CM? I was going to ask that in the other thread.

Configuration Management.

 

[ScoobyDoo]

So Kep, just my opinion, and without knowing how many other PMs are on here hopefully this doesn't offend anyone but... First, PMI is a scam to take your money. I wouldn't spend a cent on it unless you are forced to. I find that in general the PMs who are deep into PMI this and PMBoK that are just enormous pains in the butt who are their to make everyone around them miserable. To avoid getting fired, just do everything you can to make your teams lives easier. Take all the blame even when it isn't your fault, and give away all the credit whether deserved or not. Everyone that works "for" you will say nice things when asked and you'll be fine.

I agree with all of this. Well stated.

 

[MichVandal]

Configuration Management.

Never heard of them- what do they do?

 

[LynahFan]

What is your actual scope of work?

My company uses the term "Project Engineer" instead of "Project Manager," and it can include everyone from MS Project jockeys, to people putting together change packages for Technical/Cost Review Boards, to people babysitting the Risk Management process, or, in the case of small (<$10M) IRAD/CRAD projects, the overall lead could be a Project Engineer rather than a Program Manager (PM). Our "Project Engineers" are basically PMs-in-training who actually do one aspect of program management, as opposed to the PM who has responsibility for all aspects.

 

[Kepler]

Never heard of them- what do they do?

On a development program we manage the lifecycle of products:

1. Identify what it is
2. Status where it is in the development cycle
3. On acceptance by testing formally add it to a protected baseline
4. Run a change board to ensure all requests for change are properly vetted
5. Audit it periodically to ensure it still meet requirements
6. At product end wind it all down and archive / dispose according to regulations

 

[Kepler]

What is your actual scope of work?

My company uses the term "Project Engineer" instead of "Project Manager," and it can include everyone from MS Project jockeys, to people putting together change packages for Technical/Cost Review Boards, to people babysitting the Risk Management process, or, in the case of small (<$10M) IRAD/CRAD projects, the overall lead could be a Project Engineer rather than a Program Manager (PM). Our "Project Engineers" are basically PMs-in-training who actually do one aspect of program management, as opposed to the PM who has responsibility for all aspects.

Insofar as I know (who knows what the first day will bring?) I will be doing requirements gathering and coordination of a team of "data curators." I think the Data Governance is a given delineated by SLAs and MOUs between Sponsor and Contracts. I stressed that I really don't care for the money side so I don't think I will be doing much cost review. This feels like an Outreach/Mission Engagement job where you coax the customer(s) to tell you their dreams and then hurry back to your technical staff and say "is any of this more than just vaporware they read about on Wired and can we actually deliver something of value to them?"

 

[MichVandal]

On a development program we manage the lifecycle of products:

1. Identify what it is
2. Status where it is in the development cycle
3. On acceptance by testing formally add it to a protected baseline
4. Run a change board to ensure all requests for change are properly vetted
5. Audit it periodically to ensure it still meet requirements
6. At product end wind it all down and archive / dispose according to regulations

Seems like for us- the combination of multi levels of management + marketing do most of that. Other than 6. That part we are all required to deal with, along with the lawyers.

Do CM's make sure that steps are not skipped? The ones that are skipped to keep to a timeline?

 

[TalonsUpPuckDown]

I'll come out of lurking on all the political threads and jump into the deep end on this one. I've been doing this type of work for 30+ years. I do large scale IT rescue and recovery and post-merger integration. I hold a PMP because, as jerphisch points out, it's the price of admission these days, as in "We require all consultants to hold PMP certificates." I was a CIO at a logistics company where I interviewed/hired PMs. I was a partner at a large consulting firm where I implemented CMM within the project management practice and at a couple clients (we only made it to Level 2 and it was CMM, not CMMi so I'm dating myself again). Not only have I made every mistake you can think of, I've made mistakes you couldn't possibly contemplate. I'm not scrum-certified but I've led my share of Agile software implementations (the last one was 70 people on two continents and three countries across 9 time zones working on an FDA-regulated software medical device).

Now that the credentials are out of the way, here we go. For me, I've boiled my experiences into a number of key elements that keep me grounded whether I'm doing basic PM work (my current gig, and wow am I bored silly) or turning around a multi-million dollar fuck up.

1) PM is both an art and a science. Read what you can, take your training courses, know the nuts and bolts. That's the science part. The art part is how you apply it. I've seen booksmart PMP knuckleheads who can recite chapter and verse out of the PMBOK but couldn't figure out why their backlog was growing if you put a gun to their head. Knowing stuff is required; applying what you know makes you great.

The rest of my comments relate to the art side of things.

2) Communication is a double edged sword. You can over communicate. I've seen situations where the PM was carpet bombing their team with info in the name of being a good communicator. You want to balance giving them what they need to be successful with paralyzing them.
3) Accountability. I've made a career out of this. Many PMs fail because they can't overcome their natural desire to be liked. Now the other side is being a despised asshole which isn't good either. It's OK for your team to dislike you because you hold them accountable, that's human nature. The PM needs to get commitment from the team then hold them to it. Understanding where they come up short and why and what strategies you have in your back pocket to get things back on track are really important.
4) Never ask a team member to do something you aren't willing to do yourself. I've sat in requirements meetings and taken notes to help out the analysts. I've worked nights and weekends when I had little to do simply because I'd ask the team to grind one out for me. None of these things are necessarily part of my job description but if you demonstrate you don't feel you're better than them, the team will respond when you ask them to do grunt work.
5) Approachability. This is tied in with #4. Characteristics of a high performing team include the understanding that a) no one will be beaten for bringing bad news, b) that people won't be thrown under the bus for making a mistake (unless they make it again, then all bets are off). I tell my teams that there isn't anything they can screw up that the rest of us can't help them fix. These two tenets are empowering for people. I had a manager of testing lay out a case for why we weren't going to make our date. Her data was rock solid. She knew that I could read a spreadsheet, that I wasn't going to be happy, and while she was uncomfortable approaching me, she knew that in the end everything was going to come out OK. We then worked together with the development team to figure out some options that mitigated the pending disaster and I held her up as an example to the entire team. Win-win.
6) Goal setting. Set your goals and objectives. Tell everyone what they are. Tell them again. And again. Base your decisions on how you're going to achieve these goals and communicate to the team how this will get you to where you want to go. This will enable the team to easily understand the "why" behind your decisions. "Well, even though I think that's a dumb thing to do, I get why he's doing it that way." This is also an effective way to keep people/teams from "thrashing." One thing at a time. And see point #2.
7) Talking truth to power. Way too many times a PM will say "YES MA'AM!" to every request from above. How can a team be successful when their goals and objectives change daily? The term I use for that is "thrashing" and when this happens, the team finds themselves working hard and getting nothing done. A good PM will be able to tell management no and explain why (and present options). You may not win every discussion, but the team will see you going to bat for them.

I have more of this stuff if anyone's interested.

 

[Kepler]

I'll come out of lurking on all the political threads and jump into the deep end on this one. I've been doing this type of work for 30+ years. I do large scale IT rescue and recovery and post-merger integration. I hold a PMP because, as jerphisch points out, it's the price of admission these days, as in "We require all consultants to hold PMP certificates." I was a CIO at a logistics company where I interviewed/hired PMs. I was a partner at a large consulting firm where I implemented CMM within the project management practice and at a couple clients (we only made it to Level 2 and it was CMM, not CMMi so I'm dating myself again). Not only have I made every mistake you can think of, I've made mistakes you couldn't possibly contemplate. I'm not scrum-certified but I've led my share of Agile software implementations (the last one was 70 people on two continents and three countries across 9 time zones working on an FDA-regulated software medical device).

Now that the credentials are out of the way, here we go. For me, I've boiled my experiences into a number of key elements that keep me grounded whether I'm doing basic PM work (my current gig, and wow am I bored silly) or turning around a multi-million dollar fuck up.

1) PM is both an art and a science. Read what you can, take your training courses, know the nuts and bolts. That's the science part. The art part is how you apply it. I've seen booksmart PMP knuckleheads who can recite chapter and verse out of the PMBOK but couldn't figure out why their backlog was growing if you put a gun to their head. Knowing stuff is required; applying what you know makes you great.

The rest of my comments relate to the art side of things.

2) Communication is a double edged sword. You can over communicate. I've seen situations where the PM was carpet bombing their team with info in the name of being a good communicator. You want to balance giving them what they need to be successful with paralyzing them.
3) Accountability. I've made a career out of this. Many PMs fail because they can't overcome their natural desire to be liked. Now the other side is being a despised ******* which isn't good either. It's OK for your team to dislike you because you hold them accountable, that's human nature. The PM needs to get commitment from the team then hold them to it. Understanding where they come up short and why and what strategies you have in your back pocket to get things back on track are really important.
4) Never ask a team member to do something you aren't willing to do yourself. I've sat in requirements meetings and taken notes to help out the analysts. I've worked nights and weekends when I had little to do simply because I'd ask the team to grind one out for me. None of these things are necessarily part of my job description but if you demonstrate you don't feel you're better than them, the team will respond when you ask them to do grunt work.
5) Approachability. This is tied in with #4. Characteristics of a high performing team include the understanding that a) no one will be beaten for bringing bad news, b) that people won't be thrown under the bus for making a mistake (unless they make it again, then all bets are off). I tell my teams that there isn't anything they can screw up that the rest of us can't help them fix. These two tenets are empowering for people. I had a manager of testing lay out a case for why we weren't going to make our date. Her data was rock solid. She knew that I could read a spreadsheet, that I wasn't going to be happy, and while she was uncomfortable approaching me, she knew that in the end everything was going to come out OK. We then worked together with the development team to figure out some options that mitigated the pending disaster and I held her up as an example to the entire team. Win-win.
6) Goal setting. Set your goals and objectives. Tell everyone what they are. Tell them again. And again. Base your decisions on how you're going to achieve these goals and communicate to the team how this will get you to where you want to go. This will enable the team to easily understand the "why" behind your decisions. "Well, even though I think that's a dumb thing to do, I get why he's doing it that way." This is also an effective way to keep people/teams from "thrashing." One thing at a time. And see point #2.
7) Talking truth to power. Way too many times a PM will say "YES MA'AM!" to every request from above. How can a team be successful when their goals and objectives change daily? The term I use for that is "thrashing" and when this happens, the team finds themselves working hard and getting nothing done. A good PM will be able to tell management no and explain why (and present options). You may not win every discussion, but the team will see you going to bat for them.

I have more of this stuff if anyone's interested.

Hell yeah I'm interested! You just became my Cafe Mentor. I want to benefit from all 30 years so as far as I'm concerned you can talk forever; I'm taking copious notes.

 

[Kepler]

Seems like for us- the combination of multi levels of management + marketing do most of that. Other than 6. That part we are all required to deal with, along with the lawyers.

Do CM's make sure that steps are not skipped? The ones that are skipped to keep to a timeline?

Yes, CM has the overarching task of enforcing the process - we are cops. That means sometimes we are not popular, and that has led me to develop some of the skills that TalonsUp cites. The CM's job is to make sure that in their enthusiasm or haste technical performers don't just blow through the road signs because that's how accidents happen. We exist to make sure baselines aren't corrupted, scope creep doesn't infinitely extend development, and every step is documented so when there are incidents you can figure out what happened and avoid a repetition (and rewind back to a restore point so you don't lose a cataclysmic amount of work).

Everybody hates CM until the one week everybody's life depends on them.

 

[LynahFan]

Everybody hates CM until the one week everybody's life depends on them.

Perfection.

Nobody likes saving for a rainy day until the clouds burst.

 

[Swansong]

My company also used to have PMs, but now they've put that role on supervisors and managers. Definitely not ideal as some people are awful at it, but some of us excel and end up tasked with running projects way outside our knowledge base.

 

[Swansong]

Every project I've run that required daily standups involved two steps:

1. Running down task list for updates
2. Asking each person what they plan to do that day and if they anticipated issues

The first question would identify current road blocks, the second would identify anticipated ones, and by requiring everyone to sound off on part 2, the wallflowers have to speak up. Typically they'd take 20-30 minutes first thing in the morning. A lot of these were the "drop literally everything you're doing and work on this until it's done". That's how we got telehealth stood up in less than a week at the beginning of the pandemic.

 

[dxmnkd316]

Formal training limited to an overview course in Project Management sponsored by the PMI; then I have training in some related tools and tricks like EVM. There are elements of it from my CM background -- managing the CM lifecycle uses concepts that apply to anything from software to a hard hat construction project. And I have done Proposal work and so understand some of the business objectives -- I can write a mean BOE for example. I am very interested in approaches and resources to help me be more effective and not provoke the negative reaction MV voices -- since I come from a technical discipline I understand where he is coming from, and am aware how ubiquitous that impression of Project Management is.

I just joined the PMI and am reading through PMBoK, and I'm on PM groups on reddit, Discord, LinkedIn, and the PMI to lurk and absorb language and zeitgeist. I'm trying to build a support/resource group which at first I'm unashamedly just going to be a drain on, eating their brains. Anybody here interested in a Project Management thread? I'll start one -- I haven't been ingratiating myself to you folks for the last 20 years for nothing. It was all the Long Game.

As for Agile, Scrum, and Kanban, I can spell them. I am starting to read up on them, but beyond the common sense precursors that I've stumbled on myself they are naught but words that come up in job reqs so far.

Agile, scrum, kanban all have their uses, but I find that far too many people try to force their use in situations they aren't suited for. THey just muck up the efficiency by forcing a process.

A CNC is an amazing tool. You wouldn't use it to hammer a nail.

PMI and PMBoK are great for foundational skills for many people. You'll take out as much as you put in and you might not find them useful in the end. The problem with project management is there isn't a one-size-fits-all approach.

 

[ScoobyDoo]

The one thing I find the most surprising in my IT Project work is the complete lack of risk management done on most of my projects. I also found Risk Management to be the best class I ever took in college related to Project Management.