Project Management Tips

The Buddy System—Virtual Style

by Andrea Brockmeier, PMP

Managing virtual teams is a challenge—especially when it comes to communication. Meetings typically occur on conference calls or online, making communication particularly difficult. Technical issues often impede progress—dropped calls, line static, poor speakers, and other mechanical problems can get in the way of productivity.

Next time you schedule a virtual meeting, consider the buddy system to attend to the people conferencing in. Appoint another onsite associate to be your virtual call attendant. This person is responsible to make sure that everyone on the call can hear and understand what is being said across the call. The virtual attendant can also serve as the meeting facilitator, ensuring that everyone contributes their ideas equally.

Back to Top

Untangling Long e-Mail Strings

by Andrea Brockmeier, PMP

Do you ever find yourself getting lost in a string of e-mails? All of those redundant headers and footers contained within an e-mail message can be a huge time waster.

The next time you receive a long e-mail text string, clean it up first before sending it on. Create a new e-mail message with a revised, more succinct subject line. Delete all unnecessary headers and footers, and use bullet points to highlight important information and relevant links.

The time you take to clean up an e-mail message string and start fresh will be time saved many times over by making it easier for others to get information to act efficiently.

Back to Top

Uncovering Assumptions and Constraints

by Andrea Brockmeier, PMP

Isn't it interesting how assumptions and constraints often get buried somewhere in the depths of a project management plan? Often considered along with risks, it's not uncommon for someone reading a project management plan to encounter assumptions and constraints well into the other details of the plan. At that point, if you discover that the assumptions and constraints are different than your own, you may feel the need to go back to the beginning of the project management plan and read it again.

Whenever I develop a project management plan, or even a project charter from scratch, I put assumptions and constraints at the very top of the document—sometimes in one font size bigger than the rest, so that they stand out.

Assumptions and constraints are like the lens through which we understand everything else in the project management plan. Putting these details at the top of the plan will increase the likelihood that stakeholders are working with the same assumptions and constraints as they read the details of the project.

Identifying the assumptions can be difficult. Sometimes we don't recognize assumptions until we encounter someone who doesn't have the same ones as we do. Or, it is often unclear between an assumption and information that is simply misunderstood. Assumptions are the information that others are not familiar with, yet needs to be identified. As a project manager, it's your job to discern the difference between the facts as you see them and the facts as others see them. To do this, put yourself in the minds of your key stakeholders. Not only think about your assumptions, but what others might be thinking. Contemplating about others' assumptions might help shed light on our own.

Back to Top

To Work or 'Not' Work from Home—That is the Question!

by Andrea Brockmeier, PMP

More and more, professionals are deciding to work at least part of their week from home. For the individual, working from home offers a lot of personal benefits including: a flexible schedule, more quality work time, less expense and hassle commuting, and an overall reduction in distractions. Equally, employers feel this arrangement offers a win for them—with more workers opting to work from home, employers can reduce office space and offer work-from-home options as an employee benefit, which boosts morale and productivity. However, before workers and companies decide to exchange their business suits with pajamas it's important to know the disadvantages to work-at-home arrangements.

Working from home is not the panacea to modern-day business. In fact, a lot of business is 'stalled' because someone is working from home. Likewise, impromptu meetings where important decision-making or idea generation is lost, when key team members are working from home.

So, how do you keep business flowing while working from home? One of my students shared a 'buddy' system that seems to strike the perfect balance! Each work-at-home team member is assigned a 'buddy' who is the in-office point person. This 'buddy' is responsible for pulling items from the printer, addressing in-box items, or gathering other communications at the office for the work-at-home person. Essentially, the team buddy is responsible for keeping things moving in the office to minimize the impact of absence of the work-at-home person. The project manager assigned the team buddy to peer team members depending on the work-from-home schedules to ensure everyone was always covered.

Back to Top

The PMBOK Guide—A Great Resource, but not a Methodology

by Andrea Brockmeier, PMP

Well, it’s that time again. A new release of the PMBOK has been unleashed. When this type of “event” colors your daily life, it is undeniable proof that you really are as uncool as your 13-year-old insists you are. I suppose it’s not unlike other disciplines in which people specialize. But, really, one can hardly be considered a party “sparkler” when your conversations frequently involve comparing favorite chapter and verse of the PMBOK.

It’s always a bit frenzied when the PMBOK gets refreshed. You can sort of hear the buzz of excitement in the project management community. (It doesn’t take much.) Of course, it generates work for some of us, as well, which is always a good thing. The content changes are not necessarily titillating, but noteworthy. Take this 4th Edition, released at the end of December, for example. It certainly isn’t any harder to read than the last version. More attention has been drawn to identifying and influencing stakeholders, for example. That’s a good thing. And the idea of requirements makes its debut in this version, finally giving project managers a talking point for addressing the relationship between project management work and that of the business analyst. That’s a good thing, as well.

With everyone all atwitter about this latest release, there is no shortage of articles about the PMBOK. What’s of particular interest to me, however, is that in addition to all the noise about what’s changed and what hasn’t is the persistent, occasional reference to it as a methodology! This is somewhat surprising given that the PMBOK has been around for over 20 years. More importantly, however, not only is it confusing to think of the PMBOK as a methodology, but it completely undermines its value.

It’s my perspective that the PMBOK is less intimidating and has a wider audience than it used to. With over 320,000 PMPs on the planet, most project professionals have at least seen it or have a copy floating around their offices. However, I still get students who grumble (or who have been grumbled to) about the utility of the PMBOK. “No one can do all this stuff,” is typically what I hear (or something along those lines). It’s as though it’s not worth using since failure is the inevitable outcome of trying to implement all 42 processes and innumerable inputs, tools, and outputs. Why set yourself up for failure?

Well, of course no one does all that stuff. It’s not a methodology! Only when the PMBOK is understood for what it’s intended, that is, to be a collection of best practices with processes selected and scaled appropriately as decided by the project management team, does it have real value. Anyone who reads it with the intention of getting a “how to” lesson on project management is going to be disappointed as well as frustrated. The fact that it’s organized by knowledge area in and of itself would serve to confuse if one were to think that those things were organized as some sort of instruction set.

PMI is very clear about the intention of the standard and they state it repeatedly throughout the document, starting with the bold print on page 3:

“This does not mean that the knowledge, skills, and processes described should always be applied uniformly on all projects. For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process.” (PMBOK Guide, 4th Edition, page 38)

Clearly, each project is going to apply whichever of these processes and tools and techniques that make sense and scale them to project and organizational need. That’s our call as to what that looks like according to project and organizational need. With this understanding of the intention of the PMBOK, it feels a lot less like a 459 page albatross that we have no real hope of actually doing, and a lot more like the tool that it is, a reference of the best practices that work most of the time on most projects. After all, per page 39, most of us recognize that there’s more than one way to manage a project. The PMBOK just provides us with the whole bag of tricks from which we get to choose.

Now that’s a book to keep handy

Back to Top

Roles of the Project Manager and Business Analyst

by Elizabeth Larson, CBAP, PMP

There have been many articles and blog postings lately on the role of the PM and BA. We have also written about how organizations are blending the role, even though we do not advocate it. Reality and budgets sometimes dictate that the same person play both roles. Our recent 2009 Trends article mentioned that companies are increasingly blending the role, which statistics back up. There are always issues when cutting corners, though, and we wanted to clarify that it is important to keep the roles separated whenever possible. Now, for this month’s tip. Ed.

Even when the roles of project manager and business analysts are separated, there are points where conflicts can and do occur. One of these is around collaboration to gather and manage requirements. You probably know that trust is essential to successful collaborations. We talk about it in our classes frequently.

It's difficult to establish trust, though, when roles and responsibilities are not clearly defined. Trust and collaboration can’t be dictated ("You will trust each other and you will collaborate--or else!"). Having been both a BA and a PM, I have seen how important both roles are to the success of the project. I do not think these roles need to cause conflict, but I think recently they have, mainly due to the misinterpretation of the two bodies of knowledge. For example, having a section on collecting requirements (Section 5.1 of the PMBOK® Guide - Fourth Edition) might be misinterpreted as saying that project managers do the requirements work. Having the BABOK® suggest that the business analyst is responsible for product scope might be misinterpreted as having the business analyst be responsible for the total project scope.

It seems to me that the project manager gets input from many resources on the team, including the business analyst, and incorporates that input into the project management plan. Having been a lead contributor to both bodies of knowledge, I do not see them as contradictory. The project manager needs to ensure that requirements are collected. The business analyst is responsible for business analysis activities, which are incorporated into the project activities. The biggest area for potential conflict, it seems to me, are the pre-project activities. Who defines the business problem and project objectives seem to be in question. Are they defined before the project is undertaken during Enterprise Analysis? By the sponsor or project manager or business analyst as part of the Project Charter? I do think that BA and PM responsibilities in this area will need to sort themselves out as the business analysis profession matures.

What do you think? If you have ideas or anecdotes from your experience, please send us a note at info@WatermarkLearning.com.

Back to Top

Project Quality—Not Product Quality

by Andrea Brockmeier, PMP

When was the last time you gave thought to project quality? Project quality, not product quality. The quality of the products we create is fairly easy to think about. The product conforms to specification (it does what it says it supposed to do) and it meets a real need. The proverbial car that never needs repair that people use for transportation comes to mind. But what of project quality? We don’t as often think about that one. Project quality objectives, once defined, can be applied to all projects in the organization. If schedule is the hot button for your organization, maybe monitoring variation from the schedule baseline or milestone dates would be an appropriate project quality metric. We often hear that communications is the biggest opportunity area for projects. How could communications effectiveness be measured and quality objectives be defined around that? Meeting attendance could be an appropriate project quality metric. For example, if consistent meeting attendance by all invitees is considered to be an indicator of a high-quality project, it might be enlightening to monitor that variable for projects. Then at the conclusion of the project, evaluate that project quality result and compare it to how well the project achieved the organization’s definition of project success. If they seem to be positively correlated, good quality assurance and control will enable you to be more proactive in delivering project success.

Back to Top

To Meet or Not to Meet: That is the Question

by Susan K. Heidorn, CBAP, PMP

Before you have that next meeting, you may want to consider if you really need to meet or not. Given all the meetings most of us are in, your participants will be excited not to go to another meeting. How do you determine if you should have a meeting?

Do you need an interactive session to:
o Get input or advice from the group
o Get group buy in
o Build team identity
o Create participant commitment
o Address team conflict
o Clarify common understanding on an issue or problem

Can you get the right people in the room?

Are you prepared with an agenda (purpose, topics, time frames, etc.)

If not, then determine if the information could be covered by an email, telephone call or one on one meeting with the specific participant.

Remember - make your next meeting count.

Back to Top

When the Going Gets Tough, Turn to the “Whoo-Hoo” Board

by Andrea Brockmeier, PMP

Sometimes, it’s hard to think about what’s working well when things seem to be going from bad to worse. When projects are running behind schedule, over budget, and issue after issue seems to be rearing its ugly head, perhaps it’s only the foolish project manager that may recognize that as the right time to ask “What do we got on the project that's good?” But that may be exactly the question to ask to turn that project around.

A student recently shared with me a story about a project that she remembers working on in which things were not going well. In addition to being behind schedule and over budget, team members were dealing with senior level saboteurs, malfunctioning software, and integration problems. In fact, things were pretty dismal. It was in the depths of this project despair that the PM stopped to ask the question, “What do we have that’s going well?” And the Whoo-Hoo board was born! A space was cleared on the white board in their work area, and team members were invited to make entries on the Whoo-Hoo board noting small successes, including the date and name of the person involved. It didn’t take long for the list on the Whoo-Hoo board to grow, providing visible evidence that there were, in fact, many things going well. The Whoo-Hoo board proved to be a huge confidence booster for the team and helped turn that project ship around and move them in a positive direction.

So next time you feel like your project vehicle is heading for disaster, maybe that’s the time to find out what’s going right?

Back to Top

A Little Empathy Goes a Long Way

by Andrea Brockmeier, PMP

Come on…isn’t project work just about getting stuff done? Yes, we certainly need to get ‘er done, but we are better equipped to meet various stakeholders’ definitions of success if we appreciate where they are coming from on the project and the pain they are feeling. So it is for project team members, as well. The folks doing the work often get so consumed with the details that they can quickly lose sight of the big picture or why it is that they are doing the work they’re doing.

A student of mine recently shared something that a project manager of hers did that was a great example of how to develop empathy and the positive impact it can have on project performance.. The project client and team members in this organization did not interact; they were two separate entities with little or no face time during the life of the project. It was the PM’s job to facilitate communication between the client and the technical team members doing the work. To enhance understanding and develop some empathy between the two parties, the PM included one team member in the regular client status meetings. In that meeting, the client would get to know the team member and what they did for the project. The team member got to hear things from the client’s perspective so that the work they were doing had real meaning. The PM would rotate team members so that a different team member was taken to the meeting each time, allowing the client to eventually meet all of the team, and each team member to get a chance to meet and hear from the client.

The net effect of this simple tactic was certainly improved team performance, but it surely increased client appreciation for the work that was being done, as well. It’s well known that teams that have an opportunity to meet each other face-to-face, even if only once, work better together. How much easier is it to partner with someone when you know who they are and can develop a little empathy for them? Feel my pain and you are more likely to be more committed to developing something to fix it. What a great win-win!

Back to Top

Scheduling with Stickies

by Andrea Brockmeier, PMP

Few problems in life can't be solved with a few sticky notes and an Excel spreadsheet. With the addition of countless colors and shapes in today's sticky note selection, the possibilities are endless. Take project scheduling, for example—Sometimes detailing the dependencies and sequencing to get from task identification and estimates to scheduling can be a bit daunting. In addition, team members can further complicate scheduling with other dependencies that may not show up on a project manager's radar, but may significantly impact the critical path.

Enter the ever-useful sticky note! While they may seem a bit low-tech, sticky notes are perfect for capturing tasks and finding the ideal path for your project. Here's how you can use sticky notes to your advantage, in your next project meeting.

First, gather team members together and ask them to write down activities to be considered for the proposed project schedule on individual sticky notes. Have them include the estimated hours required to complete each task. Assign team members with their own sticky note color or shape to better distinguish between them.

Next, after all the activities have been collected, go to the whiteboard and put the sticky notes in a sequence in order to create a network diagram. With each activity on its own sticky note, activities can be shown to occur in tandem or sequentially. Use additional, uniquely colored or shaped stickies to indicate potential “lags” in the schedule. Once the activities are sequenced and the diagram is complete, everyone can see where their work fits in with the overall project. After the sticky notes have been “stuck,” use Visio or another modeling tool to create the diagram for sharing or for future reference.

It's critical this exercise be performed “hands-on,” with all team members participating. Require that each person approach the whiteboard with their sticky notes and arrange them as they understand the relationships between the activities. This promotes a better understanding of the work to be done. Furthermore, by participating in the scheduling exercise, there is a better chance of team member buy-in.

While this exercise may not be feasible for every activity on the entire project; for those small sections or phases where it is critical for team members to see how their activities fit into the overall task, this is a great approach.

Back to Top

Provide Key Assumptions to Ensure Project Success

by Andrea Brockmeier, PMP

We all know how critical assumptions are when providing estimates for project work. When asking for estimates from subject matter experts on projects, project managers should consider including key assumptions pertinent to the activity being estimated in their request. It's difficult for the people doing the work to know all of the assumptions they are working with and how they may influence their estimates. A request for an estimate that identifies a PM's assumptions can help guide the estimator, who often feels like they are being asked to provide information in a vacuum. Also, keeping those assumptions in front of team members gives everyone the opportunity to correct or confirm them as the project progresses and more information becomes available.

Back to Top

Project Risk Identification—Get Real!

by Andrea Brockmeier, PMP

The value of a project risk identification exercise is often undermined by the failure to provide intellectual handles for identifying risk events. If a project manager simply asks team members, “What are some of the risks on this project,” without some way to break that question down, team members are likely to have a hard time thinking of anything. Responses to the project manager's questions in this scenario can lead to responses like, “Well, the building could blow up.” Of course, it's always a possibility that a building could blow up, and that would undoubtedly have a significant impact on the project. However, it's not exactly an event we want to spend project resources trying to manage. The challenge here is to get team members' “feet on the ground” so they can think about realistic events that can be measured and, hopefully, managed.

The exercise of decomposition, or breaking things down, is ubiquitous in project management. We break down projects into sub-projects so they are easier to manage given limited resources. We break down activities into tasks to aid in estimating. And, we break down deliverables to help us understand them and to assist in communicating their complexity. Why not use the work that's already gone into these decomposition exercises as a tool in identifying risks?

A deliverable-based work breakdown structure (WBS), for example, can stimulate thinking about risk events specific to particular components of a deliverable. A task-based WBS can provide intellectual handles for thinking about events that could derail those tasks from being completed. By using the decomposition work that's already been done, team members' feet are more likely to be planted on solid ground when thinking about risk events. The building could still blow up, but use of various breakdown structures will help the team get to more realistic, measurable, and manageable risk events.

Back to Top

Juggling Multiple Project Sponsors

by Andrea Brockmeier, PMP

How many sponsors should a project have? One, of course. You may have experienced the challenges of having more than one sponsor on a project and know first hand what it's like trying to reconcile differences of opinions regarding change requests and other inputs we need from that sponsor.

Is it within your realm of authority to control what sponsorship looks like on your projects? Perhaps not—it may be that senior leadership isn't willing to identify a single sponsor, but rather wants more than one person filling that critical role so that everyone makes sure to get what they want. Where does that leave the project manager? With two or more people both responsible for making key decisions. Sounds like a headache!

If you have more than one project sponsor, identify the things you are going to need and then ask each of them for input on who can fulfill specific sponsorship roles. For example:

1. Who will review and approve significant change requests?
2. Who will be your resource for resolving cross-functional differences?
3. Who will be your "champion" and take the lead on advocating and transferring the project vision to the rest of the organization?

Create a small Responsibility Assignment Matrix, such as a RACI diagram, for key items you will need from sponsorship and assign a point person to each task. If this is met with resistance, make sure sponsorship understands the WIIFM (What's In It For Me?) factor: Time and money will be spared if you have clearly defined roles for your multi-sponsored project. And not to mention lots less spent on headache relief medication!

Back to Top

Keeping Project Vision Under Foot

by Andrea Brockmeier, PMP

We all know whose responsibility it is to define the project vision (i.e., the sponsor). But, how do we make sure we don't lose sight of that vision? A Watermark student recently shared something that he has done on projects to make sure it doesn't get lost in the changes and evolutions that projects go through: Include the project vision in the footer of your project documentation. This is a simple way to make sure stakeholders keep that vision in the forefront, as they read, and, perhaps suggest changes to the project. We couldn't agree more!

Back to Top

Does Your Project Plan Have the "Right Stuff?

by Richard Larson, CBAP, PMP

It's easy to take a project plan for granted. After all, we often use a past project as a template to jump-start our next plan. Or, our organization has a standard that we must follow. But, do they have the "right stuff?" Here is a checklist of essential items to include for any project plan, regardless of size. Each element in this list uniquely contributes to the plan, and increases the likelihood your project will succeed:

• Scope statement
• Scope baseline
• Project roles and responsibilities
• Staffing plan
• Schedule and cost baselines
• Baseline management plans
• Project quality and risks
• Communication plan

Back to Top