Skip to main content
spelling correction
Source Link

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no "one right way"): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

There is no "one right way": I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you herehear "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no "one right way"): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

There is no "one right way": I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you here "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no "one right way"): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

There is no "one right way": I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you hear "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

commas don't work like that. :) also, note on why post was edited will not be relevant later; just leaving it out makes a better answer.
Source Link

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no, one "one right wayway"): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

Edit- Per thursdaysgeek request my other two principles.

There is no, one "one right wayway": I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you here "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no, one right way): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

Edit- Per thursdaysgeek request my other two principles.

There is no, one right way: I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you here "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no "one right way"): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

There is no "one right way": I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you here "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

added 727 characters in body
Source Link

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no, one right way): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

Edit- Per thursdaysgeek request my other two principles.

There is no, one right way: I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you here "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no, one right way): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile.

They are:

People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I call it 100% and the big thing is you have to be adding value. As a PM you are the ultimate translation point for the project. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock (sub-concept: There is no, one right way): Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at getting rid of it. And if something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

Edit- Per thursdaysgeek request my other two principles.

There is no, one right way: I rolled this into "Process is a Tool, not a roadblock" but it really is its own principle. If I want to go from San Francisco to New York there are dozens of options (Different airlines, drving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and contraints. Anytime you here "That's the way we have to do it" ask "Why?"

All roads lead back to the customer: It's one of my guiding mantras, rooted in my original high tech job in customer support. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

Source Link
Loading