Three golf etiquette lessons for project managers
| Spring will soon be here in North America, and for many of us, that means we are heading out to the links in pursuit of a better handicap. Along with updating our golf clothing, buying new balls and re-gripping our clubs, a good practice to start the season is to refresh our knowledge of the rules of the game, especially as they pertain to etiquette.
Maintain pace of play This has to be the number one pet peeve of golfers regardless of their skill-level, but it’s funny how often they will complain about the pace of the group in front of them while not realizing that their own behaviors are likely irritating the foursome behind them! In project management, pace of play can be related to “flow” – our role is to keep things moving by removing hurdles to productivity or motivation. It’s easy to point the finger at others who might be slowing down our team’s momentum, but we shouldn’t ignore the waste we might be introducing in their way – redundant status reporting or meetings are just a couple of examples of this. Fix ball holes, rake out bunkers, pick up your garbage and replace divots While a golf course does have maintenance staff to tend fairways, bunkers and greens, by not performing simple corrective activities ourselves, we impact the experience of those playing behind us. Two similar examples in the work place are not ending meetings on time and not being proactive about letting resource managers know when you will need more (or less) of a team member. Both cases are examples of poor team (in the broadest sense of the word) behavior which will negatively impact other project teams. Be a gentle man/woman Unless you are a Tour professional, 99% of your frustration and competition is from within not without. As such, be a good sport – make sure you introduce yourself to the rest of your foursome, say “good shot” (and mean it), help others look for their lost balls and shake hands and say “good game” at the end of the round. As project managers, when times get tough it can be difficult, especially when faced with unprofessionalism or incompetence, but that is no excuse for unprofessionalism on your part. Always take the time to do a good job of on-boarding new team members and recognizing their accomplishments. And at the end, thank everyone for their contributions and celebrate the journey even if the destination changed. Non-golfers out there might feel that the game is a good walk spoiled, but for all of us, not applying these simple golf etiquette rules will guarantee a good project spoiled! (Note: this article was originally written and published by me in May 2014 on my personal blog, kbondale.wordpress.com) |
Does ANYONE benefit from your PM information system?
| A project management information system (PMIS) is not an investment which most companies would make lightly. The one time and ongoing hard costs coupled with the change management effort involved in implementing such tools can be significant so it is reasonable to expect that there will be some tangible value derived once the dust settles. Unfortunately, in spite of PMIS’s being commercially available for more than a couple of decades, they sometimes provide us with a live example of the Abilene paradox with everyone involved being fully aware that their system is a joy and money-leeching false deity which bestows no boons on anyone, least of all those who are required to offer information tithes to it on a weekly basis. Yet, investment in the system continues unabated, and the mandate to use it is frequently reinforced. Does the mere existence of an implemented PMIS provide any benefit? Wouldn’t this be similar to installing a fake security camera which could provide some degree of assurance even though it is all form but no substance? Does the requirement to submit project updates regularly create the right kinds of discipline in project teams? I highly doubt it. Just because I am required to feed the beast on a weekly basis doesn’t mean that I will provide quality sustenance, especially if I see no WIIFM and even more so if I get coerced to do so. What’s the root cause for such an unfortunate situation? While we could point to a bad procurement decision, a lack of understanding of the processes being automated, or insufficient requirements gathering, these are sometimes just symptoms of the real culprit – poor stakeholder engagement. If the PMIS purchasing decision and implementation is done without properly engaging one or more key stakeholder communities, the likelihood that data quality or presentation gaps exist will increase dramatically. As with establishing PMOs, the implementation of a PMIS should be orchestrated like any other strategic project. It should be supported by an appropriately vetted business case, and planned and executed in a disciplined manner including effective, holistic stakeholder identification and engagement. In other words, practice what you preach. (Note: this article was originally written and published by me in April 2016 on my personal blog, kbondale.wordpress.com) |
What do you ask when interviewing project managers?
| I've written previously about what I look for when reviewing project manager resumes as well as what I look for when hiring for these positions. Testing a candidate's knowledge of hard or soft skills provides limited benefit to the hiring process. If they have the letters ", PMP" or ", PRINCE2" after their names, they can very likely talk the talk even if they've never walked the walk. You could pose situational questions to gain some insights into how they think, but just because they answer the question to your satisfaction doesn't necessarily guarantee that they will actually behave according to what they said if a similar situation were to occur for real. Don't feel discouraged as conducting such interviews is still critical, but you might want to go beyond assessing technical knowledge or posing generic scenarios. Let me share five of my favorite questions when interviewing candidates for full time project manager roles. What's been your biggest project management failure, what did you learn from that, and how did you apply those learnings to a future project? This question is a triple threat. It assesses the self-awareness and humility of the candidate, their ability to dust themselves off and identify some lessons, and checks whether they truly learn those lessons. How do you stay current in the project management profession? There's no single right answer, but if a candidate has been neglecting their personal development this doesn't inspire confidence. Also, if their only lever for personal development has been formal training, this reflects superficiality as some of the best opportunities to grow come through experiential or relationship-based development activities. You will also have the opportunity to understand if they are giving back to the profession through volunteering, writing, presenting or mentoring others. What made you decide to become a project manager? Again, no right answer, but it provides insights into the candidate's career goals. Is project management a stepping stone to something else or is it a long-term destination? What do you consider when deciding how you are going to manage a given project? This question tests the candidate's ability to profile a project and the context in which it will be delivered as well as their awareness of complexity and delivery process tailoring. What questions do you have for me? "Judge a man by his questions rather than his answers" - Voltaire So what are your favorite questions when you've been in a similar situation? Feel free to add them in the comments below!
|
How do you engage remote team members?
| No question, there are many benefits to being collocated with your full team when managing a challenging project. But organizations are looking to reduce real estate costs, provide their employees with the benefits of telecommuting, and take advantage of a twenty-four hour work day by having teams strategically split across multiple time zones. So if we accept the inevitability that we might have to manage a project with some remote team members, how do we reduce the likelihood of this impacting team effectiveness? Herding cats is hard enough in person – it’s impossible to do when team members are scattered geographically. If they don’t buy into the vision of the project, you’ll face an uphill battle to get them aligned. If the project is a mixed blessing – hurting some team members while it helps others, you might need to spend more face time with the team members who will be impacted the worst. It is critical to fight tooth and nail to hold a project kickoff meeting which all team members and key stakeholders can attend in person to give you and your sponsor the best shot at inspiring them. But just because your team members are aligned at the beginning doesn’t mean drift won’t happen for a variety of reasons – perhaps they aren’t seeing sufficient progress or maybe a sexy new project is competing for their attention. So use your regular team meetings as an opportunity to re-engage them. “Out of sight, out of mind” is very real. It can get easy to neglect remote team members when it comes to recognition and team building, especially if the majority of your team members are collocated with you. Add a simple team building activity at regular intervals to your team meetings – there are many available via a simple Internet search which lend themselves to remote delivery. Even better, make this a rotating responsibility to give each of your team members a chance to be the life of the party. It can be tempting to impose the need for frequent progress updates or status meetings to reduce your fears, but this will become a self-fulfilling prophecy as your team members become disengaged or irritated with being micro-managed. You would be better served having a frank conversation with your team – help them understand your responsibilities and engage them in developing a reporting process which still meet your needs while empowering them. Trust your team members to behave like professionals and don’t give them a reason not to. (Note: this article was originally written and published by me in January 2016 on my personal blog, kbondale.wordpress.com) |
Seven deadly sins of scheduling
| Something I’ve taken for granted is a project manager’s ability to create and maintain a project schedule. The reality is that most accidental project managers spend at least as much time struggling with their schedules as they do getting real value out of them. No project scheduling tool is inherently bad, but there are a few cardinal sins that will reduce the value you achieve by using these indispensable aids. 1. Use a scheduling tool to help you define the scope for your project. Most scheduling tools are good for entry of tasks with durations and dependencies but are lousy as brainstorming or iterative definition aids. Spend the time to create a Work Breakdown Structure (WBS). Then using traditional Post-It notes or a similar visual approach, sequence the activities that will deliver the scope of your project. Once you’ve got the skeleton ready, you are ready to transition this information to a scheduling tool. Otherwise, get ready for spaghetti-like dependencies that are impossible to trace… 2. Use scheduling constraints excessively. Too often, I’ve reviewed project schedules that are saturated with constraints – these have been used as a cheap way of getting tasks to start and end on specific dates. While this may help to get a quick & dirty view of a project’s time-line, it effectively neuters a critical path methodology-based scheduling engine and eliminates the ability to optimize schedules through appropriate use of slack. Constraints should be used to capture real world situations only (e.g. we can’t start this task until the next Saturday as that happens to be the first available maintenance window). 3. Use automated resource leveling and effort-driven tasks. Automated resource leveling is a great concept but is poorly used – unless you are 100% certain about the relative priority of individual tasks (most organizations can’t even figure out the relative priority of their individual projects!), this feature can effectively shred your schedule. Effort-driven tasks work well for projects where there is a true linear relationship between resource allocation and task duration – however, on most knowledge-based projects, Brooks’ Law and the old cliché about nine women being unable to have a baby in one month come into play. 4. Capture too many (or too few) tasks. Remember that a schedule is just a model of what you expect to happen that serves the dual purpose of being a forecasting and tracking tool as well as a communication medium to team members and project stakeholders. There is equally as much pain of having a schedule that is at too high a level of detail (it is too easy to lose track of schedule progress) as there is of attempting to define and track every minuscule activity that occurs on the project (you’ll spend all your time maintaining the schedule). 5. The schedule is out of date the moment it is updated, so why bother updating it? Of course, this is a relative state, and yet many PMs seem to feel that keeping a schedule current is a waste of time. Unfortunately, this reduces the value of a schedule to purely being a task list. 6. Outline levels and milestones are GREAT! Outline levels and milestones are a good way to present schedule information in a fashion that will satisfy multiple levels of detail for status reporting. Having said that, too much of a good thing is also not a great idea – just because your scheduling tool supports hundreds of outline levels or milestones per schedule does not mean you have to push the boundaries of these limits! 7. We can’t start over… The worst sin of scheduling is to work with a schedule that has reached such a level of chaos that no one derives any value from its continued existence. Many project teams take that undesirable journey to Abilene without someone stepping back and saying “let’s start over” – not only can that reduce administrative effort but it can create the perception of a clean slate for the project team. To quote Kenny Rogers, “You got to know when to hold ’em, know when to fold ’em…” (Note: this article was originally written and published by me in September 2009 on my personal blog, kbondale.wordpress.com) |






In a