Communicating Project Perceptions with Stakeholders
Categories:
Stakeholder Management
Categories: Stakeholder Management
| When you deliver a message to a stakeholder, the impact that it has on him or her can vary depending on the individual. The same person can react quite differently to similar messages at different times. For example, let's say you need to advise two senior managers about a US$50,000 reversal in an expected project outcome. One manager had no idea there was a problem in the first place. The other manager heard through the grapevine that your project was facing a US$500,000 reversal. For the manager who thought that everything was OK, US$50,000 is bad news. But since the other manager's perception was that a major disaster was looming, US$50,000 seems like good news. There are several factors at play in this situation. One is certain peoples' perception of the work you are doing. The perception may be unrealistic, but it's real to the person holding it. Where your message falls in the stream of information the person is dealing with also plays a role. If yours is the one bit of good news in a bad day, for instance, you may get a much warmer response than if your bit of good news is swamped by other spectacular events in other parts of the business. The challenge of communicating with stakeholders is not knowing the perceptions they currently hold of you and your project. You also have no control over the other news he or she receives in a given day. The only solution is to listen carefully to the feedback from the stakeholder. Then try to put your message and the feedback in context and adjust accordingly. It helps if you are in regular two-way communication with your key stakeholders and if you are tapped into their grapevine as well. By being connected you will be able to understand a little of the "ambient temperature." You can adjust the way you communicate and the timing of the communication to increase the chance of a successful outcome. Then expect the unexpected. How much time do you spend thinking about the impact of key communications? What are some of the ways you've found success in communicating with stakeholders? |
Zooming In On Project Tasks
Categories:
Scheduling
Categories: Scheduling
| A project that's broken down into milestones and tasks doesn't seem that difficult -- in fact, it seems more manageable to execute. But the tasks can be numerous, and they all compete for your time -- something there is almost never enough of. I use a technique where I take one task and separate it from any others that should be worked on that day. The task comes from the project plan and my calendar, so I've already assigned a duration and specific date and time to work on it. To actually execute the specific task, I separate it in my mind from anything else I need to do and focus on it completely. In other words, I zoom in. If disruptions are present, try focusing on your task with these tips: 1. Clear your mind of everything except what you're working on. 2. Establish what your optimal environment is. Are you most productive when it's quiet? When there are people around? At your desk? 3. Visualize the end result or completion of the task. 4. Convert or break down the task into actionable items that you or someone else on the team can handle. Converting written tasks into actionable items pushes those items to completion much faster. 5. Identify people who can help you get the task done or resources you need to get it done. 6. Jump straight into the task until completion. What tactics do you use to "zoom in" on your tasks? |
Prioritizing Agile Project Requirements
Categories:
Agile
Categories: Agile
| In Agile project management, we must prioritize a requirements list for release planning, iteration planning and the insertion of new requirements. But there are several techniques to do this. One of the most popular methods of prioritizing Agile project requirements is the "MoSCoW" approach. This stands for 'Must, Should, Could, Won't.' The only problem with this method is that everything is usually a must -- which doesn't allow proper Agile release planning because the requirements aren't necessarily put in order of priority. Another method is the Kano model, developed by Professor Noriaki Kano, which strives to fulfill requirements and please customers. This model features four components: • Must haves are elements the product cannot ship without. • Dissatisfiers are things the product must NOT include. • Satisfiers include requirements where the more you have the better the product is perceived. Like a marketing checklist, each feature adds incremental value. • Delighters take the product beyond simply meeting the requirements to boosting customer satisfaction and recommendation. Several prioritization models put together a table weighted by two variables: features and customers. Each feature is weighted by its value to each customer. The sum of the weights multiplied by the scores makes it possible to see which features are most useful overall across the set of demanding customers. No matter which technique is used, your list of project requirements must be sorted from most to least valuable. What techniques do you use to prioritize requirements? |
Project Planning for The Great Unknown
| My project team and I had embarked on a massive renovation to our company's main movie theater. It was one of the largest projects we'd done to date. And it was one of those "your job is on the line if something goes wrong" type of projects. Such a big project brings some very big potential risks. My project delivery team and I made a list of possible risks plus a list of planned responses. Should one of the risks actually manifest, we knew exactly what to do. As you may have guessed by now, this huge project that couldn't go wrong went very, very wrong. Our team realized one thing while planning: We know that we don't know. Irritating as that phrase is, it may keep you from ruining what would be an otherwise successful project. We knew that even our collective genius may not be enough to avoid disaster. But rather than spend the time creating mitigation plans for unpredictable risks, we created a mitigation plan for the actual risk of not knowing what could happen. The plan included an eight-step process tailored to how the project team operates and how we run our projects. This gave us a standard procedure to follow if trouble arose. And when it did, we used that mitigation plan. There was no need to worry. Everything was under control, even for a risk we hadn't specifically planned for. Because of this project, my team and I still always assume an "unplanned for" risk is on the horizon. We always give our due diligence to risk management and create responses for risks we can specifically identify. But then we review our eight-step plan to ensure we're all prepared for the unknown. Do you have a risk-management response-mitigation plan in place for risks you know you don't know? |
Project Off Track? Regroup, Reengage, Reset
| Elements of the project are falling apart, whether with the team, with the supplier or in your project management domain. Now is the time to regroup, reengage and reset everyone back in the direction of the project goal -- before it's too late. To regroup, conduct a structured session with the core project team to capture the status of everyone's tasks. The regroup can be in the form of a meeting, brainstorming session or workshop. This way, no one on the team is invalidated for elements that went wrong, and you can show your appreciation for everyone's input. Allow for a discussion of their concerns. To reengage, work with the team to align with the original goal, requirements and project deliverables. Then, reset the expectations of each team member, as well as your responsibilities as the project manager. Finally, implement any changes required for the successful delivery of the project. Separate failure to perform from a lack of teamwork within the group. This action allows you to focus on how to achieve the expected results of the project, with buy-in from the entire team. What do you when your projects are off track? |





