Communicating With the Right Stakeholders
Categories:
Communications Management
Categories: Communications Management
| Any project team will have far more stakeholders to potentially communicate with than they have either the time, money or people to manage. But selecting the right stakeholders for a sustained communication effort in a project is not simple and can be a very resource intensive process. My research over the last 10 years suggests a three-phased approach works best. One: Identify the stakeholders and figure out what you need from them and what they want from the success (or failure) of the project. This is called 'mutuality'. If you can show the person they're likely to achieve at least some of their aims, they're far more likely to provide you with what you need from them. Two: Work out which stakeholder is most important. This requires assessing at least three aspects for each: • How powerful is the stakeholder? Can he or she close the project down, force change or do they have little direct impact? • How much effort is the stakeholder likely to invest in asserting their position or 'rights'? Some stakeholders will go to almost any lengths to assert their position while others are really not that interested. • How close is the stakeholder to the project? People actively working on the project have more impact than those who are relatively distant. Three: Determine the attitude of each important stakeholder towards the project and how receptive they are to your communication. Now you have the information needed to focus your communication efforts where they can achieve the greatest benefit. People who have a supportive attitude simply need 'business as usual' communication. On the other hand, important stakeholders who are assessed as having a less than optimal attitude may need heroic communication efforts to change their views if the project is going to succeed. And always remember: People change. Reassessing the stakeholder community on a regular basis helps ensure the communication plan is working or if it needs changing. |
Time to Empty Your Bag Full of Issues
Categories:
Risk Management
Categories: Risk Management
| Time and again we see projects with a trail of issues that, if not dealt with, build up into this "issues bag," as I call it. The further you get into the project, the bigger and heavier the bag becomes--making it harder to control. Carrying around these unsolved issues creates several risks. 1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases. 2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding. 3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money. So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest: • Keep track of the issues. • Maintain a list of the risks involved with these issues. • Keep a list of assumptions about what? and validate them. • Maintain a list of all changes executed during the project. • Perform quality assurance and close-out any outstanding quality? issues. • Ensure appropriate user-acceptance testing phases and garner signoff on the testing. • Pay attention to the organizational and business environment your project is impacting and any issues that arise. • Notify systems support teams of any impacts that may be caused by your project, directly or indirectly. |
Eulogy to the Old Agile
Categories:
Agile
Categories: Agile
| Escorted on stage by a bagpipe rendition of Amazing Grace, Alistair Cockburn, Ph.D., began his keynote address for the Agile 2009 Conference by waxing Shakespearean on the death of agile as we know it: I come to bury agile, not to praise it; The evil methods do lives after them, The good is oft interred with their bones, So let it be with agile. The noble Waterfall Hath told you agile was ambitious: If it were so, it was a grievous fault, And grievously hath agile answered it. (Adapted from Julius Caesar, Act 3, Scene 2. You can read Alistair's full monologue here.) Melodramatic (in a good way) to be sure. But Alistair, an IT strategist and co-author of the Agile Manifesto, doesn't really believe agile has "met its maker" as the saying goes. Instead, he said agile is in transition--it's not the agile of the 1990s. The landscape has changed. It's grown beyond small organizations and is being applied to much richer, much more complex concepts and projects. Agile shouldn't be "new news," he said. "We're focusing so heavily on things that are 15 years old, I want to start focusing on things that are current." He also shared three pillars of 21st century software development: • Software development is a craft: Developers must pay attention to their skills and to the medium--they must relearn every few years. • Software development is a cooperative game of invention and communication: It relies on teamwork, communication and strategies. • Software development should use lean processes: That means small queues, cross-trained people and varied processes. Hosted by the Agile Alliance, the conference has pulled in 1,400 attendees from more than 38 countries. You can follow all of the conference happenings on Twitter. Did you attend Alistair's keynote address? What did you think? More to come. |
Taking On Project Management Myths, Part 1
| I'm going to spend the next several posts discussing commonly held, but, in my opinion, profoundly erroneous tenets of project management. Two esteemed colleagues, David Hampton and Alice Skehan, PMP, rated my list of 10 assertions in order of contrariness to common project management precepts, as well as the extent with which even they disagreed. Here, then, are my numbers 10 and 9: Myth 10: Trying to leverage organizational power to implement project management in the macro-organization is futile. Oh, I know, people try it all the time, and in many cases the ultimate outcome bears a strong resemblance to a legitimately installed project management office (PMO). As I discuss in my book, Things Your PMO Is Doing Wrong, the so-called coercive strategies don't work in the long run for the simple reason that people are being, well, coerced into doing project management. The moment they can opt out of the system, they will, and no reason that can provide reasonable cover will be considered too silly. I once had a project team that tried to use a paperwork-reduction initiative as a reason why they shouldn't have to send along their earned value reports. Really. Myth 9: There is no cost performance management without earned value. Period. No exceptions. And yet, the comparison of budgets to actual costs persists. When I'm instructing new cost engineers in earned value, I like using the following scenario: You're a project manager, assigned to get 2,000 widgets created in two months, with a US$2,000 budget. You time-phase your budget US$1,000 in month one and US$1,000 in month two. At the end of month one, your accountant comes to you and says that your project has spent US$1,100. Then I spring the question: "How are you doing?" Invariably, one of them will say "Poorly, because I'm overspent." "What if I told you that you had made 1,300 widgets?" Obviously, that little fact changes everything. In this instance, comparing the budgets to the actuals was not only useless, it was actually misleading. Management information systems can be forgiven for offering up the occasional jejune tidbit, but never for misleading. And yet that's all you're left with if you don't have an earned value management system. Next up, I'll be taking on the capabilities of the general ledger and re-visiting the bottoms-up estimate at completion debate. |
Managing Project Dependencies
| Projects don't run in silos or in a vacuum. They run in organized, chaotic environments where everyone is working toward the end result. There's nothing wrong with that--it's how organizations achieve multiple results in a short period of time. The key, of course, is to manage all these changes and interdependent projects. But what if you are part of a project that's not a part of any program or portfolio with an assigned program or portfolio manager or director? How do you manage those interdependencies that are not part of your scope? In my view, it's a matter of paying attention and linking yourself to three key areas: • Organization: Culture, processes, standards, rules, events, special blackout periods, etc. • Operations: Operational teams responsible for change management, incident management, delivery and quality management/control • Project Delivery: Such as a project management office or a business committee or unit that's responsible for project delivery No matter what dependencies may exist, they will be manifested through these three main channels. |
