Forward Momentum: Delivering Results

By Vicki Wrona, PMP

I had earlier posted a popular article on email pet peeves. Let’s continue that discussion by sharing how we handle annoying office behavior. With today’s open offices and greater workforce diversity in terms of age and culture, we all find ourselves observing behavior we may not deem as preferred (or professional). What can we do about that behavior if it affects our ability to work professionally?

There are several things which I have encountered which are bothersome. They are:

• Headphones – I don’t mind people wearing headphones to allow them to concentrate while working in a busy, open or noisy environment. What I mind is when they get in the way of office communication. People who don’t remove headphones or earbuds when you are trying to talk to them are especially irksome to me. Shouting in the office so they can hear me over their music does not help anybody.
• Loud talkers – this includes people on the phone as well as those whose voices really carry even during normal conversation. Some people are not aware of how far their voice carries.
• Phone answerers – there are those people who will run to their phone while you are in the middle of a business conversation or meeting to answer their phone. Their implication is that the person on the other end, no matter who it is, is more important than you and the conversation you are having now. I understand that sometimes important calls are expected, but this should be the exception, not the rule. It’s OK to let the phone roll to voice mail and deal with that issue later.
• Office fridge – there are the normal problems of unidentifiable, stinky and fuzzy food in the fridge. I will admit to the being the person who didn’t recognize my own container and so left food in the fridge until well past the fuzzy stage. (It only happened once, I swear.) I can deal with old food, because it’s easy enough to throw away. What I don’t like are the people who bring their lunch in a cooler or protected lunch sack who displace other food in the fridge to make room for their large sack. Don’t they know that the lining protects their food from the external elements…namely the cold air in the fridge? Meanwhile, they put food that is not protected and needs to be refrigerated on the counter. I wouldn’t mind their action if they tossed fuzzy food instead of fresh food.  Erg.
• Showing up at work sick – I just had a discussion with my neighbor about this the other day. I worked for a company that issued awards for perfect attendance, encouraging people to show up sick to work. In the end, they may have received their perfect attendance but the rest of us didn’t.

How do I work around many of these? I use a proven method of providing feedback.

• Headphoners – I no longer make fun of them and call them Borg.  I make sure not to raise my voice to compensate for the headphones. At times, I have simply asked them to remove the headphones or earbuds.
• Phone answerers – Unless this is done by my boss or a more senior person, I simply leave their office or the conference room where we are meeting. If they do this in my office, I signal for them to step outside while talking and I switch focus to other work to give a clear indication that I am moving on. Later, I talk to them to discuss why I acted the way I did and see if we can come to an agreement on future discussions.
• Loud talkers – if it is truly disruptive, I rely on providing simple feedback or asking them if they are aware of just how much their voice carries. I have found people to be interested and very willing to make an effort to lower their voice.
• Showing up at work sick – my best defense was to avoid them as best I could. If I had to talk to them face to face, I kept a larger than normal distance and used lots of sanitizer. They knew who they were, and it became the office joke to offer them some sanitizer….even if it wasn’t really funny.

What annoying office behavior bothers you most?

By Kathy Garland, guest contributor

No one can argue that most companies spend too much time in meetings. Too many agenda items, too many things to accomplish in too little time, no guidelines, no clear understanding of the real purpose of the meeting are things I’ve found get in the way of having a productive meeting.

One of the strategies I used when I led a sales team was to have standing meetings. Particularly when deadlines are short, proposals are due and the pressure is on which seems to be the standard today, a standing meeting can get everyone back on their tasks more quickly.

We got more done and I could see the relief on my co-workers face when the meeting concluded quickly and they could get back on task.

It’s a commitment to make this change. You have to think about your meetings in different ways.

This type of meeting is not for long discussions, strategy planning or policy decisions. It’s a way to keep co-workers frequently updated on what the group is accomplishing and what still needs to be done.

You can discover other reasons to have stand up meetings, however, here are two that will improve your team’s productivity:

1. Status update – particularly helpful when working on a project with a lot of moving parts and people. Ensure no overlap and nothing falls through the cracks. Strive to make this meeting no longer than 5-10 minutes.

2. Ad hoc decisions – My job was to lead the pitch process for new business development. Occasionally something would change in the process, someone would have an insight to share that would help the team, or a risky creative concept needed to be discussed before moving forward. These types of ad hoc meetings can keep a team on track and ultimately affect the outcome of your project.

You can make your stand-up meetings fun. The important thing is that there is a shared understanding of the purpose of the meetings and the format.

Here’s a link to an article on stand-up meetings and stories of how companies use them to keep moving forward: http://goo.gl/q9cVi.

Originally posted by Kathy Garland on her site, www.kathygarland.com.

by Kathy Martucci, PMP

As project managers, we are accustomed, even mandated, to planning our work and working our plan. We build and examine (and re-examine) Work Breakdown Structures and eventual project schedules. We swear our Gannt chart is our most important tool for tracking, managing and communicating. While this approach has led to many successful outcomes, is it the “end all and be all”? Are there alternatives to or variations on this tried and true methodology? I say YES.

According to PMI, there is no project scope (and, therefore, no project) without meticulous collection and vetting of any and all product and project requirements. There is no scope statement, no WBS, no schedule, no costs. This makes perfect sense – work for its own sake is folly, work geared to legitimate requirements is the means to an end, a defined end.

Requirements collection is, without a doubt, the most important work of the project. After all, without the requirements there would BE no project; the requirements embody the needs and wants of the project stakeholders. As such, excruciating care must be taken to define and document all the requirements with as much clarity and understanding as possible. Preferably, trained and experienced business analysts with clear marching orders and defined processes can accomplish this all-important task. Knowing what you know, you can plan an approach to requirements collection and management that will form the basis of everything else you do from that day forward. If the sponsor of your project wants you to fast track at this point, cut corners or otherwise skim the surface of the heart of the project, find another project.

Now, we aren’t naïve enough to believe that, once the requirements are documented, they won’t morph or take on nuances that were not understood initially. That’s all right; that’s why you continue to review and re-review as the project progresses. That’s why you undergo risk management and thoughtful communications. That’s why the organization has chosen YOU to shepherd the requirements to their full expression. That’s why you devise a plan and methodology for requirements management: a workable traceability matrix and accompanying processes.

In my world, the requirements traceability matrix is the cornerstone of any project large or small. The matrix not only ties each and every requirement to a legitimate business objective (defining “legitimate” must be documented and agreed-upon with stakeholders beforehand). Every other step in the project management methodology flows from the requirement / objective: the task and its activities to accurately and effectively address the requirement, the time to accomplish the task, the human resources to complete the task successfully, and any resultant procurement. I can’t state it too often or too loudly: every other downstream process in the project management methodology is moot or compromised when considered outside of the requirements management process.

The matrix, though, without processes to track and manage the requirements is useless. As the project progresses to the Execution phase, work should not be authorized unless it is deemed the right work at the right time based on the fulfillment of one or more requirements. Without a process to tie work to the requirements documented in the matrix, the methodology falls apart and serves no one.

Once you’re satisfied that the requirements have been solidified as much as possible, define the scope of the project. The scope should be based firmly and squarely on the body of requirements. It should be abundantly and unarguably clear to stakeholders what is NOT going to be provided either by the end product or in the project processes. Taking the time at this point in the project to communicate (and defend or confirm requirements AGAIN) with your stakeholders is part and parcel of stakeholder management and communications.

The Work Breakdown Structure (WBS) can only be built based on a deep and thorough understanding of the requirements. It may seem obscure that project team training will be part of the WBS, but if team members need skills to accomplish tasks that are derived from a legitimate business objective, it’s a valid work package…not just valid, but a critical success factor. Let’s turn that around: if your team is excited that they will get some training which is not necessary but will certainly enhance their resumes, they are in for some disappointment. That’s ok; it’s character building.

Requirements not only dominate the Scope Management of project methodology, it is the major driver for all other management processes. Human Resource management is dependent on the requirements of the project. If a cosmic-sized database is needed to accommodate requirements, a cosmic-sized database administrator (and the resulting costs) is justified. Hold out for the best; it’s a MUST.

Don’t have a super-sized database or the servers on which to run it efficiently? Procurements and procurement management will be driven by these requirements.

Lastly, “project quality management includes the processes and activities…that determine quality…responsibilities so that the project will satisfy the needs for which it was undertaken”. Of course, the “needs for which it was undertaken” are the requirements. Are we seeing a pattern here?

No, we’re not disrespecting or abandoning the WBS and project schedule; we are ensuring that these tools are driven and built by the requirements of the project, by the legitimate needs of your customer. Only then can the definition of a successful project include true customer satisfaction.