You're wrong. It's about ME!
•Transferir como KEY, PDF•
1 gostou•622 visualizações
Why aren’t client objectives enough? Papercut Project Monitoring looks up the noses of stakeholder organizations and tries to fathom what’s important. If someone’s objectives aren’t spelled out at the beginning of a project, sooner or later a senior stakeholder in that organization is going to notice and scream about what they’re not getting. That senior guy is going to put pressure on the project team to deliver, who will then try to wrestle project objectives away from the other teams.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a You're wrong. It's about ME!
Semelhante a You're wrong. It's about ME! (9)
Mais de Geoff Crane
Último
Último (20)
You're wrong. It's about ME!
- 1. You’re wrong. It’s about ME. or, why aren’t client objectives enough? Image courtesy of Landii on Flickr.
- 6. Risk!
- 7. Easy! Risk!
- 8. Easy! Risk! Money!
- 9. Easy! Risk! Objectives Money!
- 10. PMBOK
- 11. Easy! Money!
- 12. Easy! Risk! Objectives Money!
- 13. Risk! Money!
- 14. Easy! Risk! Objectives Money!
- 15. Easy! Risk!
- 16. Easy! Risk! Objectives Money!
- 17. Image courtesy of Evil Erin on Flickr.
- 18. Easy! Risk! Money!
- 19. Easy! Risk! Money!
- 20. Easy! Thbbbbbt! Risk! Money!
- 21. Easy! Thbbbbbt! Hello?! Risk! Money!
- 22. Easy! Thbbbbbt! Hello?! Risk! Nooooooo!!! Money!
- 24. • Be forthright about capturing objectives • Be sensitive to people’s fears Do • Clearly identify consequences • Foster a sense of team
- 25. • Give in to pressure D on’t • Agree to secret deals • Be forthright about capturing objectives • Be sensitive to people’s fears Do • Clearly identify consequences • Foster a sense of team
- 26. • Give in to pressure D on’t (ahem) • Agree to secret deals Image courtesy of cliff1066 on Flickr. • Be forthright about capturing objectives • Be sensitive to people’s fears Do • Clearly identify consequences • Foster a sense of team
- 28. Gr eat Min ds! @ReadyTOFeedback @managementsushi @alecsatin
- 29. http://www.twitter.com/PapercutPM http://papercutpm.tumblr.com http://www.myvirtualcv.com/papercutpm http://ca.linkedin.com/papercutpm [Feel free to tear off this branded slide to use the file in your own presentation]
Notas do Editor
- I’m Geoff Crane, Owner and Chief Consultant at Papercut Project Monitoring. In this week’s presentation, I’m going to talk a little bit about stakeholder management and why it’s so important to represent everyone at the planning table. As project managers are fully aware, a stakeholder is anyone who has a “stake” or interest in a project. As most project managers also know, stakeholders can be found all over organizations, and are prone to prone to remain hidden until the last minute and pop out of the woodwork to throw a monkey wrench into things. For purposes of this presentation, I’m going to keep things simple and talk about stakeholder organizations on a project, and what happens when they get neglected.
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- So here we have a client organization who’s commissioning the project. *click* They’re going to need some help from their end user community, *click* and likely they’ll also need some help from a vendor to help build the actual product or service. These people will make up the core project team. *click* Unless these people entirely represent the organizations they work for, there’s likely senior stakeholders who are concerned with one thing in particular. Each organizations needs are going to be different. The client organization, for example, is generally motivated by either a risk, like, we need a new service to be able to compete with our competitors, or the opposite of a risk, an opportunity. Like, here’s a new idea that will give us an edge over our competitors. *click* That’s very nice for the client, but the end user organization won’t give a crap about the clients needs. They want the product or service to be easy to use, and that’s all they care about. *click* The vendor, of course, couldn’t care less about what they other two want. They just want to get paid. *click* All of these needs come together at the heart of the project to form the project objectives. *click*
- Now the project management body of knowledge is very clear about needing to establish the project objectives at the beginning of a project. It doesn’t matter which methodology you subscribe to, making sure you capture objectives is clear across all of them. What’s not so clear is WHY you do it. Oh sure they’re clear about being sure the project team knows what the project is about, and what the client wants to achieve, but it’s not all about the client, is it? If it were, the end user and vendor organizations wouldn’t be needed at all. The fact of the matter is, getting the project done is a team effort between all organizations. That means giving the objectives of each organization equal weight. So, take a second, and think of project objectives as a ball. *click*
- If someone’s objectives aren’t spelled out at the beginning, sooner or later a senior stakeholder in that organization is going to notice and scream about what he’s not getting. That senior guy is going to put pressure on the project team to deliver, who will then make a play for the objectives ball. When that happens, stakeholders behind the other teams aren’t going to like it. *click*
- If someone’s objectives aren’t spelled out at the beginning, sooner or later a senior stakeholder in that organization is going to notice and scream about what he’s not getting. That senior guy is going to put pressure on the project team to deliver, who will then make a play for the objectives ball. When that happens, stakeholders behind the other teams aren’t going to like it. *click*
- One of the other stakeholders will yell, putting pressure on their team, and they’ll wrestle for control of the ball.
- One of the other stakeholders will yell, putting pressure on their team, and they’ll wrestle for control of the ball.
- This will keep going. *click* And going. *click* And going. *click* And each time that ball *click* gets pulled away from the centre, *click* the tug of war will take its toll on the project, *click* and the project manager, who, all this time, *click* is struggling to sustain project momentum. *click* If this is allowed to continue, *click* it won’t take long before someone *click*....snaps.
- This will keep going. *click* And going. *click* And going. *click* And each time that ball *click* gets pulled away from the centre, *click* the tug of war will take its toll on the project, *click* and the project manager, who, all this time, *click* is struggling to sustain project momentum. *click* If this is allowed to continue, *click* it won’t take long before someone *click*....snaps.
- Nobody wants this to happen.
- So it’s important to lock those objectives down at the start. And here’s where a lot of project managers miss the boat. Objectives are typically skewed towards one group or another. Generally, it’s the client organization, because they’re the ones with the money. *click* Sometimes the end user organization is the public at large, or separate from the client somehow, as is the case with B2B. In that case, the end users may not get an equal voice in the project objectives, and so will be poorly represented. *click* What the client THINKS their end users want and what the end users REALLY want may be two different things. The project completes, the end users don’t like the results, and so don’t use the product or service. Did the client achieve their objectives? Probably not. And don’t forget the vendor. It’s an ugly truth that vendors are primarily interested in revenue. People accept that. But it often goes unspoken that vendors can have sales quotas. Projects span a period of time, easily crossing a year end. What happens to the vendor if a project delay pushes anticipated revenue into the new year? This could have an impact on the salesperson’s bonus, their job, and if the project was significant enough, even the value of vendor shares. Think of the kinds of behaviour you’ll get from your vendor as the year draws to a close and their objectives aren’t met. *click* I’ve seen it from both sides, and it’s not pretty. But ahh...if their quotas were identified as a project objective early, key deadlines might be taken more seriously by everyone involved. If the schedule looked like it might slip, the vendor could be notified and make early arrangements to prevent any negative impacts from the slippage. Here we’re entering sensitive territory, though, because a vendor might not want to tell the client about their financial objectives, and the client might be adamant they know more than the end users. *click* With all of these different variables, how do you get a lockdown on the situation and still keep the project going forward?
- So it’s important to lock those objectives down at the start. And here’s where a lot of project managers miss the boat. Objectives are typically skewed towards one group or another. Generally, it’s the client organization, because they’re the ones with the money. *click* Sometimes the end user organization is the public at large, or separate from the client somehow, as is the case with B2B. In that case, the end users may not get an equal voice in the project objectives, and so will be poorly represented. *click* What the client THINKS their end users want and what the end users REALLY want may be two different things. The project completes, the end users don’t like the results, and so don’t use the product or service. Did the client achieve their objectives? Probably not. And don’t forget the vendor. It’s an ugly truth that vendors are primarily interested in revenue. People accept that. But it often goes unspoken that vendors can have sales quotas. Projects span a period of time, easily crossing a year end. What happens to the vendor if a project delay pushes anticipated revenue into the new year? This could have an impact on the salesperson’s bonus, their job, and if the project was significant enough, even the value of vendor shares. Think of the kinds of behaviour you’ll get from your vendor as the year draws to a close and their objectives aren’t met. *click* I’ve seen it from both sides, and it’s not pretty. But ahh...if their quotas were identified as a project objective early, key deadlines might be taken more seriously by everyone involved. If the schedule looked like it might slip, the vendor could be notified and make early arrangements to prevent any negative impacts from the slippage. Here we’re entering sensitive territory, though, because a vendor might not want to tell the client about their financial objectives, and the client might be adamant they know more than the end users. *click* With all of these different variables, how do you get a lockdown on the situation and still keep the project going forward?
- So it’s important to lock those objectives down at the start. And here’s where a lot of project managers miss the boat. Objectives are typically skewed towards one group or another. Generally, it’s the client organization, because they’re the ones with the money. *click* Sometimes the end user organization is the public at large, or separate from the client somehow, as is the case with B2B. In that case, the end users may not get an equal voice in the project objectives, and so will be poorly represented. *click* What the client THINKS their end users want and what the end users REALLY want may be two different things. The project completes, the end users don’t like the results, and so don’t use the product or service. Did the client achieve their objectives? Probably not. And don’t forget the vendor. It’s an ugly truth that vendors are primarily interested in revenue. People accept that. But it often goes unspoken that vendors can have sales quotas. Projects span a period of time, easily crossing a year end. What happens to the vendor if a project delay pushes anticipated revenue into the new year? This could have an impact on the salesperson’s bonus, their job, and if the project was significant enough, even the value of vendor shares. Think of the kinds of behaviour you’ll get from your vendor as the year draws to a close and their objectives aren’t met. *click* I’ve seen it from both sides, and it’s not pretty. But ahh...if their quotas were identified as a project objective early, key deadlines might be taken more seriously by everyone involved. If the schedule looked like it might slip, the vendor could be notified and make early arrangements to prevent any negative impacts from the slippage. Here we’re entering sensitive territory, though, because a vendor might not want to tell the client about their financial objectives, and the client might be adamant they know more than the end users. *click* With all of these different variables, how do you get a lockdown on the situation and still keep the project going forward?
- So it’s important to lock those objectives down at the start. And here’s where a lot of project managers miss the boat. Objectives are typically skewed towards one group or another. Generally, it’s the client organization, because they’re the ones with the money. *click* Sometimes the end user organization is the public at large, or separate from the client somehow, as is the case with B2B. In that case, the end users may not get an equal voice in the project objectives, and so will be poorly represented. *click* What the client THINKS their end users want and what the end users REALLY want may be two different things. The project completes, the end users don’t like the results, and so don’t use the product or service. Did the client achieve their objectives? Probably not. And don’t forget the vendor. It’s an ugly truth that vendors are primarily interested in revenue. People accept that. But it often goes unspoken that vendors can have sales quotas. Projects span a period of time, easily crossing a year end. What happens to the vendor if a project delay pushes anticipated revenue into the new year? This could have an impact on the salesperson’s bonus, their job, and if the project was significant enough, even the value of vendor shares. Think of the kinds of behaviour you’ll get from your vendor as the year draws to a close and their objectives aren’t met. *click* I’ve seen it from both sides, and it’s not pretty. But ahh...if their quotas were identified as a project objective early, key deadlines might be taken more seriously by everyone involved. If the schedule looked like it might slip, the vendor could be notified and make early arrangements to prevent any negative impacts from the slippage. Here we’re entering sensitive territory, though, because a vendor might not want to tell the client about their financial objectives, and the client might be adamant they know more than the end users. *click* With all of these different variables, how do you get a lockdown on the situation and still keep the project going forward?
- The best thing you can do is to maintain a climate of openness and encourage all your senior stakeholders to do the same. Be up front that you want to capture ALL the objectives, and include them in the charter. Some people are going to be afraid, though, and you need to be sensitive to that. If you strongarm them into telling the rest of the project team what their motivations are, they’re likely to just dig their heels in, which really isn’t a great way to start a project off. Explain that it’s in their best interests for everyone to be aware of what they need to accomplish, and that once people come together with those objectives in mind, they can develop an approach to the project that will make everyone satisfied. Also think with them what could happen if they don’t divulge their objectives. How could they wind up disappointed? At the start of a project, everyone is likely to be a little bit shy and nervous about what other people think of them. Build a sense of team from the get go, encouraging everyone to work together. It will go a long way to help develop trust across the team, and will help establish your position as a leader. *click* What you shouldn’t do though, is give in to pressure or agree to secret deals. If you do, you’re essentially taking responsibility for non-disclosure and putting yourself at risk if one of your stakeholders is unhappy. People throughout time have been very consistent in their ability to throw blame around, and if you cave, you give them permission to send a lynch mob after you later on when they’re not getting their way. *click* If your stakeholders continue to resist, your best strategy is to push back, letting them know that you’re uncomfortable walking into a project that’s already shrouded with secrets. If you’re going to take that approach though, make sure you let stakeholders within your own organization know, because they’ll have their own objectives too! Being tough is much easier when you have strong support behind you.
- The best thing you can do is to maintain a climate of openness and encourage all your senior stakeholders to do the same. Be up front that you want to capture ALL the objectives, and include them in the charter. Some people are going to be afraid, though, and you need to be sensitive to that. If you strongarm them into telling the rest of the project team what their motivations are, they’re likely to just dig their heels in, which really isn’t a great way to start a project off. Explain that it’s in their best interests for everyone to be aware of what they need to accomplish, and that once people come together with those objectives in mind, they can develop an approach to the project that will make everyone satisfied. Also think with them what could happen if they don’t divulge their objectives. How could they wind up disappointed? At the start of a project, everyone is likely to be a little bit shy and nervous about what other people think of them. Build a sense of team from the get go, encouraging everyone to work together. It will go a long way to help develop trust across the team, and will help establish your position as a leader. *click* What you shouldn’t do though, is give in to pressure or agree to secret deals. If you do, you’re essentially taking responsibility for non-disclosure and putting yourself at risk if one of your stakeholders is unhappy. People throughout time have been very consistent in their ability to throw blame around, and if you cave, you give them permission to send a lynch mob after you later on when they’re not getting their way. *click* If your stakeholders continue to resist, your best strategy is to push back, letting them know that you’re uncomfortable walking into a project that’s already shrouded with secrets. If you’re going to take that approach though, make sure you let stakeholders within your own organization know, because they’ll have their own objectives too! Being tough is much easier when you have strong support behind you.
- The best thing you can do is to maintain a climate of openness and encourage all your senior stakeholders to do the same. Be up front that you want to capture ALL the objectives, and include them in the charter. Some people are going to be afraid, though, and you need to be sensitive to that. If you strongarm them into telling the rest of the project team what their motivations are, they’re likely to just dig their heels in, which really isn’t a great way to start a project off. Explain that it’s in their best interests for everyone to be aware of what they need to accomplish, and that once people come together with those objectives in mind, they can develop an approach to the project that will make everyone satisfied. Also think with them what could happen if they don’t divulge their objectives. How could they wind up disappointed? At the start of a project, everyone is likely to be a little bit shy and nervous about what other people think of them. Build a sense of team from the get go, encouraging everyone to work together. It will go a long way to help develop trust across the team, and will help establish your position as a leader. *click* What you shouldn’t do though, is give in to pressure or agree to secret deals. If you do, you’re essentially taking responsibility for non-disclosure and putting yourself at risk if one of your stakeholders is unhappy. People throughout time have been very consistent in their ability to throw blame around, and if you cave, you give them permission to send a lynch mob after you later on when they’re not getting their way. *click* If your stakeholders continue to resist, your best strategy is to push back, letting them know that you’re uncomfortable walking into a project that’s already shrouded with secrets. If you’re going to take that approach though, make sure you let stakeholders within your own organization know, because they’ll have their own objectives too! Being tough is much easier when you have strong support behind you.
- The best thing you can do is to maintain a climate of openness and encourage all your senior stakeholders to do the same. Be up front that you want to capture ALL the objectives, and include them in the charter. Some people are going to be afraid, though, and you need to be sensitive to that. If you strongarm them into telling the rest of the project team what their motivations are, they’re likely to just dig their heels in, which really isn’t a great way to start a project off. Explain that it’s in their best interests for everyone to be aware of what they need to accomplish, and that once people come together with those objectives in mind, they can develop an approach to the project that will make everyone satisfied. Also think with them what could happen if they don’t divulge their objectives. How could they wind up disappointed? At the start of a project, everyone is likely to be a little bit shy and nervous about what other people think of them. Build a sense of team from the get go, encouraging everyone to work together. It will go a long way to help develop trust across the team, and will help establish your position as a leader. *click* What you shouldn’t do though, is give in to pressure or agree to secret deals. If you do, you’re essentially taking responsibility for non-disclosure and putting yourself at risk if one of your stakeholders is unhappy. People throughout time have been very consistent in their ability to throw blame around, and if you cave, you give them permission to send a lynch mob after you later on when they’re not getting their way. *click* If your stakeholders continue to resist, your best strategy is to push back, letting them know that you’re uncomfortable walking into a project that’s already shrouded with secrets. If you’re going to take that approach though, make sure you let stakeholders within your own organization know, because they’ll have their own objectives too! Being tough is much easier when you have strong support behind you.
- The best thing you can do is to maintain a climate of openness and encourage all your senior stakeholders to do the same. Be up front that you want to capture ALL the objectives, and include them in the charter. Some people are going to be afraid, though, and you need to be sensitive to that. If you strongarm them into telling the rest of the project team what their motivations are, they’re likely to just dig their heels in, which really isn’t a great way to start a project off. Explain that it’s in their best interests for everyone to be aware of what they need to accomplish, and that once people come together with those objectives in mind, they can develop an approach to the project that will make everyone satisfied. Also think with them what could happen if they don’t divulge their objectives. How could they wind up disappointed? At the start of a project, everyone is likely to be a little bit shy and nervous about what other people think of them. Build a sense of team from the get go, encouraging everyone to work together. It will go a long way to help develop trust across the team, and will help establish your position as a leader. *click* What you shouldn’t do though, is give in to pressure or agree to secret deals. If you do, you’re essentially taking responsibility for non-disclosure and putting yourself at risk if one of your stakeholders is unhappy. People throughout time have been very consistent in their ability to throw blame around, and if you cave, you give them permission to send a lynch mob after you later on when they’re not getting their way. *click* If your stakeholders continue to resist, your best strategy is to push back, letting them know that you’re uncomfortable walking into a project that’s already shrouded with secrets. If you’re going to take that approach though, make sure you let stakeholders within your own organization know, because they’ll have their own objectives too! Being tough is much easier when you have strong support behind you.
- The best thing you can do is to maintain a climate of openness and encourage all your senior stakeholders to do the same. Be up front that you want to capture ALL the objectives, and include them in the charter. Some people are going to be afraid, though, and you need to be sensitive to that. If you strongarm them into telling the rest of the project team what their motivations are, they’re likely to just dig their heels in, which really isn’t a great way to start a project off. Explain that it’s in their best interests for everyone to be aware of what they need to accomplish, and that once people come together with those objectives in mind, they can develop an approach to the project that will make everyone satisfied. Also think with them what could happen if they don’t divulge their objectives. How could they wind up disappointed? At the start of a project, everyone is likely to be a little bit shy and nervous about what other people think of them. Build a sense of team from the get go, encouraging everyone to work together. It will go a long way to help develop trust across the team, and will help establish your position as a leader. *click* What you shouldn’t do though, is give in to pressure or agree to secret deals. If you do, you’re essentially taking responsibility for non-disclosure and putting yourself at risk if one of your stakeholders is unhappy. People throughout time have been very consistent in their ability to throw blame around, and if you cave, you give them permission to send a lynch mob after you later on when they’re not getting their way. *click* If your stakeholders continue to resist, your best strategy is to push back, letting them know that you’re uncomfortable walking into a project that’s already shrouded with secrets. If you’re going to take that approach though, make sure you let stakeholders within your own organization know, because they’ll have their own objectives too! Being tough is much easier when you have strong support behind you.
- Before I finish, I want to mention some really smart people out there who also come at their work from a perspective of openness. Give their blogs a read because they have some really great things to say. Sonia di Maulo is ReadyToFeedback on Twitter. She not only encourages openness but is a strong advocate for feedback. This lady believes that a little kindness can move mountains. From a stakeholder perspective, this approach is invaluable. Bernie Ritchie, or Management Sushi, is full of excellent advice for leaders in a fast changing world. She delivers this in a variety of fabulously inventive formats. Alec Satin is a project manager extraordinaire. With a smile that could win over the meanest stakeholder, he heaps out fantastic advice on how to make your projects go smoother. You can find all of their writings on their sites linked from their Twitter homepages.
- Incidentally, if you want to print off and use this presentation in your own meetings, feel free. I’ve deliberately kept my logo off all pages except this one. That’s it, once again I’m Geoff Crane, owner of Papercut Project Monitoring, and you can find me online at any of these networks. Feel free to join me and share your ideas on stakeholder management.