Setting Your Project Resources Straight
| Getting things done is easiest when responsibilities are clear. Because when it comes down to it, there's no special formula for project success other than being clear on key parameters such as requirements, scope, deliverables and resources. Take team members as an example. We need people with specific skills to execute project activities well. And knowing what's to be delivered and roles that are required to deliver those results creates for the team a picture of how the project will be completed. In project-based organizations, many project team members are not carrying out day-to-day functions. Team members often are brought in for a specific project with a specific role to fill. That role is not always as well-defined as, say, someone's role in auditing, marketing, operations management or human resources. As the project leader, figuring out and clarifying everyone's role and their responsibilities often comes from spending time on the project, asking questions and consulting project definition documents. Setting expectations of what is required of team members before the project is in full swing should be standard practice. One way to set expectations would be to clearly identify each role with its set of responsibilities and accountabilities within the project definition documents. Include an RACI chart--a matrix of all the activities or decision-making authorities undertaken in an organization set against all the people or roles--for areas such as communication, deployment, quality assurance and testing. When describing the role of a particular team member, it's also a good idea to distinguish his or her on activities that may not directly relate to the project, but may be required within the organization. What challenges do you face when doling out team responsibilities. |
Stakeholder Perceptions Are Paramount
| One of the first things salespeople learn is that perceptions are reality. And the same goes for project managers. Your perceptions and your reality may differ, but if you want to communicate effectively with someone you need to understand their version of the truth. Perceptions are also closely aligned with expectations. If a stakeholder perceives an organization as unresponsive and inefficient they will expect bad service. From this starting point, the stakeholder will readily accept as true every experience that contradicts their view of the world. A good experience can be written off as "the exception that proves the rule." This presents a distinct challenge to project managers who are developing a communication plan. Your stakeholder's perceptions of project management will be based on prior experience with other projects in other times and even other organizations. This is neither fair nor reasonable but it is a fact! The situation is made worse by another trait: our tendency to feel and remember bad experiences more strongly than good ones. Where negative attitudes occur, your solution is basically hard work. You need to assess the current attitude of your key stakeholders, determine the optimum attitude and then work to improve the stakeholder's perceptions of your project. There are three key elements to consider when working to change poor perceptions. 1. Build rapport and open communication channels that will be effective. You may need help from supportive stakeholders to achieve this. 2. Build your credibility by providing accurate, timely and useful information that precisely meets the needs of the stakeholder. Help them to be successful. 3. Whenever possible, differentiate your current project from the person's previous negative experiences. The bad news is one slip and you immediately reinforce the old perceptions. So stay focused and ensure every communication, authentic and credible. |
The Power of Prevention
| I received an intriguing question at a recent webinar I led: "How does Six Sigma training address or include the concept of acknowledgment?" That question was actually a new one for me! So I turned to my colleague, Anne Foley, director of Six Sigma for International Institute of Learning Inc. Apart from the usual reasons why you need to acknowledge a team member, I asked what role she sees acknowledgment playing in Six Sigma training? She said the training discusses the kind of culture you establish if you only acknowledge those who put fires out, without acknowledging those who actually prevent the fires. "Fire prevention is critically important to business success but often goes without notice. If you want to change the culture, you must change the way you acknowledge, celebrate and reward employees by honoring those who prevent fires as much (if not more) than those who put them out." Anne talked about how one of her green belt students discovered his company had a defective inventory management count. Finances showed the company had spent a certain dollar amount on inventory--and that did not match the amount of inventory in the system, which did not match the physical count. He investigated and found that the inventory-entry process was broken, which could have left the company without critical inventory to run its business had the problem not been discovered. He found it, fixed it and his boss was so happy he wrote it up in an internal company newsletter and gave his employee a whole week off--with pay. At several companies where Anne has conducted training, managers are trying so hard to acknowledge and encourage fire prevention that they actually run competitions among those who prevent errors--and the awards are big--from free dinners to stock options. Sincere and heartfelt acknowledgment always makes a profound difference to people. But did you know it also prevents fires? What an awesome tool! So thanks to the student who brought this question to my attention. I learned something important and hope you did, too! |
Taking on Project Management Myths, Part 5
Categories:
Agile
Categories: Agile
| It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses. Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance. Truth: Comparing budgets to actuals is not only useless, it's misleading. To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement. Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000. You time-phase your budget US$1,000 in month one and US$1,000 in month two. At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing? If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class. If you said, "It depends on how many widgets you've made," go to the front of the class. Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them. A very simple example, I grant you, but it starkly supports my assertion. The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry. Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted. My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep. The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be. What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare. So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda. But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary. So what do you think? Myth or reality? Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice. |
Defining Your Project
| Project management may not be all about document management, but it's a necessary and important part of the job. And it all starts with the project definition documents created in the planning phase. As the name implies, these documents outline the details of a given project, such as business goals and requirements, scope, budget and project management plan. Project definition documents should include: Basic project data: Goals, objectives and any business issues to be resolved Project execution parameters: Definitions of project boundaries, key policies and procedures that are specific to the organization and that must be followed to integrate the project work and its result into the organization during and after the product delivery Required project management methodology: Governs how the project is planned, how each phase is executed and what's required to move from one phase to another And don't forget any other information that might be helpful to anyone who wants to know about the project. What's great about A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is that it offers project managers an idea of what should be included in the project management plan. Project managers can then create various project definition documents that best the the project at hand. What tips do you have for putting together project definition documents? Are there certain processes you always follow? |
