Empower Project Team Members
| Project teams are built of people with multiple layers of skills and competencies. A few will be selected as project leads to have less responsibility than a project manager, but more than a team member. Project leads ensure smooth task management and reporting flow, but how many of them are allowed or trusted to make decisions? What level of decisions can they make? The key to empowering a team member lies in the project manager's ability to get to know the person's strengths and weaknesses. Some people, although highly skilled, are weak at managing customers. Some have the ability to influence but aren't necessarily good at managing time. In one of my earlier posts, I talked about delegating work to team members as a way to help them succeed. To be able to delegate effectively, project managers simply cannot pick one person and assign him or her a task without carefully considering that person's skills. When empowering team members, the same rules apply. In some cases, you can only see the true colors of a person through action. First, select someone with a suitable background and competencies. Then test the person with small decisions or tasks. Check if he or she can communicate effectively by having conversations to gauge his or her ability to think and act proactively. When you empower team members by giving them greater responsibility, you can significantly improve the way a project is managed. Deadlines that require input or quick decisions can be met promptly, for example. Customer satisfaction can be improved because a team member doesn't have to go through layers of approval. And, those empowered team members may get a confidence boost. What decisions do you trust your team members to make? Have you experienced any negative impacts by empowering team members? Do you think empowering team members improves project delivery? |
Persuade Stakeholders for Effective Project Governance
Categories:
Stakeholder Management
Categories: Stakeholder Management
| One of the biggest challenges faced by all sectors of the project management profession is persuading senior executives to focus on implementing effective project governance. Governance is a "top-down" process. Most of the risks and rewards associated with a project or program are determined long before the project manager is appointed. Effective project management delivers a realistic and achievable outcome efficiently. If the parameters for the project are unrealistic in the first place, the best project management can do is stop the situation from deteriorating further. Failure is guaranteed. Wishful thinking is not an effective substitute for effective project governance. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not have a miracle process that will magically transform an impossible set of objectives into an achievable set of objectives. The organization's executives need to balance risks, rewards and capabilities to set realistic objectives and then use effective governance systems to oversee the delivery. The only way to achieve meaningful change is by communicating to affect a change in the understanding of stakeholders. When senior executives require effective project governance, we can better assist them in establishing effective and robust systems. If you're lucky enough to work in an organization with effective project governance, broadcast the benefits. If you work in an organization that could improve its governance, use your skills to advise upwards. If your organization is on the road toward effective governance, keep helping it along. If we are successful in making effective project governance the normal way organizations operate, the rate of project success will increase, as will the standing of our profession. What can you do to help create the climate for better governance? |
4 Metrics to Help Spot Trouble for Agile Teams
| In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips: Juggle Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time. Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions. Plan leak This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning. Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work). In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates. Execution leak Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less). Jelly This shows how much unplanned work was added during the iteration. In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints. What do you think? Have you used these metrics? What metrics do you use to help spot trouble? |
Are You Sure Your Project Information is Secure?
Categories:
PM Think About It
Categories: PM Think About It
| Fellow blogger V. Srivinasa Rao recently wrote an interesting post about the Global Distribution Model 2.0 that is launching soon. The model holds a lot of promise and is a great framework for implementing mobile global communications tools. Today, the fastest rising communications and computing technology is mobile. And while this development provides exciting possibilities for improved project efficiency, it does not come without risks. I'm focusing specifically on devices with a mobile operating system, such as iOS, Android, Windows Phone 7, Blackberry or Nokia. The reason for my concern is the speed of adoption for the devices. They now play a role in every project I manage. It may be simple communications such as email between team members, text messaging and calendar functionality, or more sophisticated uses such as remote access to project data, project management software or even video conferencing. Yet 90 percent of the time, I find that no one is really thinking through the implications of using this technology. Think about it: With this expanded communication comes an increased risk that your project's confidential or critical information could be exposed, intentionally or unintentionally. This information can be controlled fairly easily by IT departments on laptops, but mobile operating systems don't allow for the same kind of security just yet. You must be wary of how information may be getting communicated over your mobile device. Information "attacks" can come in several forms. At an event where "free wireless access" is offered, for example, someone who wants to gather data illegally can set up a US$50 wireless router, name it "[Event Name] Wireless" and watch as attendees innocently connect their devices to communicate with the rest of the team. Simply leaving your Bluetooth enabled in public locations can open you up to attacks. It doesn't even need to be something that devious. All that needs to happen is for one of your team members to lose a device that has regulated data on it. In the United States, you'll have to officially report the incident to the Federal Government. The key takeaway here is that as our world expands, we are being given exciting new ways to coordinate and communicate with our team members across the planet. We should take full advantage of this. But we should do it with our eyes open. How do you protect your data on a mobile device? |
Beyond Stakeholder Management
| My mentor in this field -- Julio Matus Nakamura, a project manager -- once told me, "In any organization, there aren't just processes, projects, strategies or tools. What really matters is people." That lesson, learned long ago, taught me that no matter a person's position, he or she is a human being first. It's very important to build trust among human beings in order to believe in each other. When I realized that, I vowed to establish that type of relationship with my stakeholders -- to build that trust and try to create a more personal relationship with them. In my opinion, in some cases it's more important to have a good relationship with the sponsor or customer than the results of the project. I'm not suggesting you forget about your project's results or even the contract. Just that you should put the same emphasis in building a deeper relationship with your key stakeholders as you put in delivering good results and caring about contract issues. Here are some simple tips that I have used for a while. I hope it may help you when building a relationship with your stakeholders: 1. Use basic manners: Always say hello, goodbye, thanks, please, well done, good job and I'm sorry. These are powerful little words that can make a big difference. 2. Show respect: Often when we are in a conversation with someone, we are not 100 percent in the conversation. You must be present. No excuses. When talking with someone, pay all of your attention to what the person is saying. Avoid thinking about your response when the other party talks; just listen carefully to what's being said. 3. Learn to read body language: We communicate more with our body than with our words. Learn to "listen" to the body of your counterpart and learn to speak with your body. For example, don't cross your arms during a conversation, as this can seem standoffish. Make eye contact during conversation and always face the person to whom you're talking. 4. Share something personal: Find affinities with your stakeholder wherever possible. This could be the university where you studied, the town where you grew up, vacations you've taken, books you've read, or your favorite team and sport. Make sure to find the appropriate moment to share these commonalities. 5. Break the ice: Read the environment around your stakeholder and discover his or her interests. At the first opportunity, bring those interests into the conversation. What about you? What tools or techniques do you use to build trust with your stakeholders? |





