Skip to main content

Tag: Communication

Start off Your New Year with a Quick Win

As we start off the New Year, it often takes a while to get back into the swing of things.  Thus, project results can become delayed or dampened while ramping back up to speed.  Instead, in today’s new normal business environment, where sales are lackluster and cash is tight yet service is paramount, there isn’t a moment to lose on achieving critical project results. 

One of the best ways to accelerate project results is to orchestrate a small, quick win.  A quick win gives the project team a reason to celebrate success and become re-energized on the project objectives.  It reminds the team of where they left off, why the project is important to the executives and company objectives, and it gives the team members a way to kick off the New Year with recognition.

 Undoubtedly, there are countless quick win possibilities for every project team yet achieving them when you need them can be a challenge.  So, what are a few tips to ensure your project team achieves a quick win?  1) Reengage.  2) Ask Questions.  3) Pick a “win”.

  1. Re-engage:  First, you must reengage your project team!  Don’t expect your team to continue where they left off.  Even if they wanted to do this, there have likely been too many distractions over the holidays.  Instead, kick off the New Year by bringing your team together. Reengage with them.  Back up for a few minutes and discuss why the project is valuable.  Recognize each team member for their part of the project success thus far or their key role in the project.  Remind the team of the critical path and where they left off.  And last but not least, reengage as the project leader.
  2. Ask Questions:  It’s surprising how simple it is to ask questions yet this secret to success is often overlooked.  First, find out where you project team stands.  Ask them what they think is most important to ensure success?  Is timing critical?  Resources?  Overlap with other departments or external resources?  Encourage debate and brainstorming.
    Find out which are the most critical upcoming tasks. Why? Is everyone on the same page? If not, why not? Should we incorporate any tweaks given the progress so far?  Ask about potential roadblocks. Listen carefully.
  3. Pick a “win”:  Choose a small, quick win as a project team.  Most importantly, ensure everyone is on the same page.  Ensure everyone has an opportunity for input and feedback. 

Then, develop or clarify a plan to achieve the quick win.  Make sure the leader of each project task understands its importance.  Communicate in advance that a critical path task is coming up.  Encourage teamwork.  Do not dictate; instead, participate. 

Plan to celebrate the win.  Begin promoting the importance of the quick win immediately to key stakeholders and executives.  Your #1 job as project leader is to ensure the quick win is perceived as a quick win!

The power of a small, quick win is incredible – there’s nothing like it to gain momentum.  It isn’t complex, expensive or time consuming yet it can propel your project forward in the New Year.  Why not reengage your project team to plan a quick win immediately?

Don’t forget to leave your comments below.

So What?

As we know, 80-90% of a project manager’s time is spent communicating.  The challenge for some project managers is that their communication appears to fall on deaf ears.  Team members don’t follow established procedures for status reporting or issue notification and senior stakeholders procrastinate or avoid decision making, issue resolution or risk response execution.

When asked, the project manager might point to minutes from meetings, project status reports and e-mail messages to prove that the requests were made.  Sadly, this ignores a core principle of the basic communication model as per the PMBOK Guide, 4th edition: “the sender is responsible for making the information clear and complete so that the receiver can receive it correctly, and for confirming that it is properly understood”.

If the message encoding the information the project manager is hoping will generate action is not perceived by the receiver to be as important or urgent as the project manager feels, the outcome will not be the expected one.

The project manager may wish to have team members follow certain “common sense” steps for sharing information or for escalating appropriately but if the impact of their not doing so is not clear to them, the team members are likely to perceive this as bureaucracy or micro-management. 

If the project manager takes the time to explain the linkage between the requested information and gaining greater predictability on achieving the project’s objectives and is successful in  communicating how the success of the project aligns with the success of the team members, they are likely to at least understand what’s in it for them and why it is important to the project.  This does not guarantee 100% compliance, but at least expectations were appropriately set.

With senior stakeholders such as a project sponsor, a different challenge presents itself.  If the project manager cannot clearly articulate the business impacts of a decision, issue resolution or risk response, at best, the senior stakeholder will procrastinate, but worse, this poor communication will impact the stakeholder’s perception of the professionalism and effectiveness of the project manager. 

While observing the body language or verbal reactions of senior managers to a project manager who is clearly missing the mark with their communication attempts, I’ve often mentally drawn cartoon bubbles over the senior stakeholders’ heads with the thought “Why are they wasting my time?”.

Even if the project manager clearly explains the business impacts of not fulfilling a request, it may still not be perceived as a high enough priority.  Sometimes, there is nothing more that the project manager can do in this case beyond further escalation but if there is the potential of a downstream impact to other more critical business outcomes, it is the responsibility of the project manager to help the senior stakeholder understand these ripple effects.

It would be wonderful if Star Trek’s Universal Translator existed, but until it does, project managers who are unable to answer the “So What?” question might suffer the same fate as an average red shirted crew member!   

Don’t forget to leave your comments below.

The Good Boss

The question often looms: Why do we work?  Perhaps it doesn’t really matter why – we all have to work to some degree or another.  Some people work to live and others live to work.  Some find a balance between the two where one flows naturally and seamlessly into another.  We spend every day doing stuff and it turns out, oddly and intuitively enough, that the people we encounter and work with influence our experience at work as well.  Our colleagues, clients, peers and bosses, all of those we cross paths with at work bear some weight on our satisfaction, productivity, creativity and diligence for the little niches we may find or cultivate.    

Let’s look at how one of these groups affects each and every one of us.  Most of us have all had a boss at some point and many of us may be a boss or have been a boss in the past.  In this case, we’ll consider a “boss” as any position managerial, supervisory, or executive – really any time someone leads other people.  Bosses are important for this reason, that they lead others through experience, vision, and honored time.  

Not all bosses are created equal, however, and there are certain trends that make for better bosses.  Forty years of combined experience – one of us with 35 as a professional management consultant and the other with 5 as a fresh and reflective worker – have uncovered prime examples of good bosses.  To enlighten the modern workplace and workforce, here are five examples of good bosses (and they are not mutually exclusive):

1)    The Listener – a boss who will listen to and appreciates different points of view.  This boss hears and honors their employees’ thoughts and considerations respectfully but with a caveat being they may or may not put these ideas into action.    The Listener listens to their employees because they were hired for a reason.  As such, they trust their employees and value their input.  Sometimes, they are even dependent upon it.  The Listener is a good boss because they have insight beyond their own experience and vision, insight that is influenced by many angles, and because if their employees are allowed to voice their own opinions and ideas, they are inspired and engaged.

2)    The Empowerer – a boss that lets employees run their own show and lets them learn by making some mistakes.  To a degree of trust and support, this boss cultivates leadership in their team.  Working together, they identify tasks and create a plan, but let the employees decide the nuts & bolts of how it actually gets done.  The Empowerer doesn’t delegate aimlessly, creating a sense of subordination in their team, but rather engages their employees from the ground up in a focused manner.  Employees are inspired to take on leadership roles and collaborate both with their boss and with others.  The Empowerer is a good boss because they can simultaneously ignite productivity, personal development, and satisfaction among their employees.  

3)    The Mentor – a boss that teaches, coaches and guides.  This boss doesn’t necessarily need to be older, but a tad wiser or simply just willing to share.  They seek to understand their employees’ experiences and identify which ones need or want mentoring.  The relationship with their employees is constructive, meaning both criticism and praise are offered with the intentions of growing the employees set of skills.  An offer to mentor is either explicitly offered or subtly developed over time.  The goal is both in current interest and looking towards the future, always geared to enhance the employees’ skills.  The Mentor is a good boss because they ensure a future for the employee and the company while inspiring immediate productivity and engagement.

4)    The Cool Dude (or Dudette) – a boss that has fun and lets their employees have fun.  This boss maintains a certain aura of authority while creating a likeable and lively atmosphere.  They let their employees enjoy their time at work and find time for small diversions, within the confines that the job still gets done…and done well.  At those instances, this boss rewards their employees with time off or special workplace events within the realm of a respectable workplace culture.  The Cool Dude or Dudette is a good boss because they understand that all employees are people, that all people need some kind of fun, and that happy employees are healthy, productive, and engaged.   

5)    The Creator – a boss who inspires invention and creativity.  This boss pushes the limits of their employees to ignite innovation.  They challenge intellect and question the status quo, so that new products and ideas are developed from within.  The Creator embodies the spirit of imagination and is never overly demanding.  Creativity and invention come from a unique mindset, so this boss correctly identifies those in their team that are keen to this way of thinking.  As such, The Creator is a good boss because they are motivational and collaborative.

These five bosses, or rather their respective characteristics, exemplify what makes for healthy leadership within organizations.  Many bosses may embody many or all of these characteristics.  The best bosses are able to reflect upon their own natural inclinations and experiences, leveraging their assets and developing areas of weakness.  Common trends amongst these five good bosses make for a great boss as well – collaborative, communicative, engaging, and inspirational.  Our new cogenerational world is crying out for leaders – of all ages and generations — and hopefully many of us will realize that great leaders can exist in the smallest, biggest, nearest and furthest of places.  

Don’t forget to leave your comments below.


Jim Finkelstein is a student and leader of people in business. With 34+ years of consulting and corporate experience, he has specialized in business and people strategy, motivation and reward, and organizational assessment, development, communications and transformation. Finkelstein has worked for diverse industries, from health care to high tech. He has built programs and provided services to Boards of Directors, senior executives, management and employees.

Matt Finkelstein received his MBA in Organization Behavior and Development from the Wharton School of the University of Pennsylvania (1976) and a BA in Psychology and Economics from Trinity College in Hartford, Connecticut (1974).

His experience includes being a partner in a Big Five firm, a CEO of a professional services firm, a corporate executive for Fortune 500 companies, and an entrepreneur with his current company, FutureSense®, Inc. He has experienced business from every possible angle and through every possible change.

The Agile Project Manager – Don’t Throw out the PMBOK!

Dec7bob4I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

  • be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
  • pay close attention to risks – planning, real-time surfacing and guiding team reactions
  • encourage the teams to improve at an accelerated rate; to set the bar high for improvement
  • become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress
  • take the role of impediment resolution to the next level; mining for impediments…and dependencies, then inspiring action
  • cheerlead for their teams; inspire and demand that the Product Owner does the same

What I was trying to convey to them was the ‘mindset’ of a “good Project Manager”…or at least the ones I’ve seen and collaborated with in my journey. You see, many agilists use the role of Project Manager as a bit of a verbal “punching bag”—implying that there is no need for them in an agile context. By the way, you see these same folks trivializing other roles too—functional managers, testers, and business analysts to name a few.

I can’t disagree more with these folks and that position. I think solid Project Managers can find a place in agile teams…a place that makes a HUGE difference. Yes, they might need to reframe their style and behaviors for an agile context, but please, please, please don’t throw away all of your approaches. Your teams absolutely need and will appreciate your skills, as long as you reframe appropriately without throwing out your essence!

The “Agile Way”?

An anti-pattern that often shows up in agile teams relates to managers and project managers losing their way when it comes to knowing when and where to engage their teams. Knowing how to effectively handle the fuzzy and scary notion of a “Self-Directed Team” it turns out can be quite challenging.

A common reaction is to treat the team as if walking on egg shells. If you see the team heading for a cliff, you can’t really say anything—as they’re “self-directed”. Of if you do say something, you must whisper…quietly…hoping that someone might hear you.

I once coached a team in Toronto. As is my typical practice, I gave them a quick Scrum overview, then planned and kicked off their first sprint. I stayed for a few days to ensure they were going in the right direction, and then I went home. I came back at the sprint transition just to see how things were going. In my first morning Scrum upon returning, one of the developers sort of “yelled at” their functional manager who was attending as a ‘Chicken’.

The team was stuck at a technical impasse and she said: “You better step in and tell us how to handle this, or I’m going to scream”. I was taken aback and after the stand-up I asked her what was up.

She said that ever since the sprint started that none of the functional managers were saying anything—nor providing any guidance whatsoever to their teams. And that she was sick and tired of it. She wanted help! I then asked the functional managers what was going on. They said that they were only doing what I’d told them—that the team was “self-directed” and that they were to keep quiet…being ‘Chickens’ if you will.

Ugh I thought as I smiled a wry smile to myself. Yes, I had told them that respecting self-direction is important. But that doesn’t imply that you don’t have a role and responsibility as the teams’ functional manager. You certainly don’t let them crash into a wall without yelling and warning them. You see, the managers missed the nuance of leading within agile teams, as many roles do. They mistakenly behaved as if they were marginalized and didn’t matter…when nothing could be further from the truth!

Dec7bob3

So—Which way do we go George?

It’s Situational & Skills Matter

Always remember that your agile PM role is situational. You’ll want to keep the values (Lean principles, Agile Manifesto Principles & Practices, Essence of your specific methods, Quality, and focus on Team) core in your thinking, but at the same time very much react to situations as you always have—with simply some ‘adjustments’.

As part of being situational, always remember that the teams’ skills & experience matter quite a bit in how you should react. If you have a brand spanking new team, then you probably want to provide more prescriptive guidance. If you have a master-level team, then your job is to softly guide & support them, but truly get out of their way. The Dreyfus model of skill acquisition is a good model to become familiar with to conceptualize the various team levels that you might encounter and to guide your adjustments.

Risk an Opinion

As in the above story, your teams still need leadership—leadership that provides clarity, vision, missions, and goal-setting. Leadership that is “in the game or trenches” with them. Leadership that endeavors to protect them and to shield them from major obstacles and mistakes. Leadership that is supportive and encouraging. Leadership that is in all cases, well, leading them…

In a word, you should evolve towards a more Servant-Leadership style. But you also need to share your thoughts with you team. Risk saying how you feel and what you’re concerned about, but then allow the team to take risks and chart their own paths. Risk telling the team ‘No’ if you feel they’re on a destructive path and be prepared to also tell them ‘Why’. Finally, risk ultimately becoming a part of the team and sharing their responsibilities.

Leverage your Instincts

As I’m writing this, my company iContact is making a fairly major release of our eMail Marketing software platform. We’ve been adding social capabilities for several months and are now exposing them via this release.

One of the things we struggled with was how we turn on our +70k customers. Do we do it all at once, or in a more measured way to mitigate risk and allow us to see how the new functionality ‘behaves’ under load. There were two schools of thought across the teams—release it ALL and release it incrementally. Most of the teams had an ALL perspective, as did our QA team members. However there were a few in the development organization that wanted a more controlled release and argued for that option. Initially they were considered naysayers, only reacting to FUD, but to our credit—we listened to them.

After much discussion, we opted for a controlled roll-out. While we didn’t encounter huge problems as we ramped-up, it allowed for us to better understand our usage metrics, plan for incremental use, and have time to fix a few lingering issues. In the end, it proved that our overall risk-handling instincts were the right way to go. I’m glad the few had the courage to “speak up” and that we trusted their instincts.

Ceremony & Reporting Matter

Remember that even agile teams still bear a responsibility to integrate back into the organization. They need to be transparent and communicative—and not simply in agile terms. It’s not sufficient to simply say “come review our burndown chart” or “just attend our Daily Scrum” if an executive or stakeholder asks you or the team for status.

Sure that is a mechanism or ceremony setup for this sort of communication. But what if that stakeholder doesn’t show up? Does that alleviate your communication responsibilities? Of course not! So beyond the information radiators, a PM can ensure the team is effectively communicating broadly across the organization.

Another important point is communicating in ‘terms’ that the business can understand. Whether it is reports, data, videos, or whatever it takes to represent the teams’ progress and efforts.

The PMBOK!

I’ll even go so far in this post to say that many of the ‘traditional’ principles and techniques from the PMBOK shouldn’t be “thrown away” from an agile perspective. Let’s take the notion of critical path for instance. In larger agile projects, with multiple teams, there still are plans that evolve. And within that framework keeping the critical path of work in-sight across teams can be a crucial visibility point.

As can asking the team to manage risks, or creating a project charter, or establishing effective milestones for cross-team integration. So please don’t throw away or ignore these skills if you “Go Agile”. Just transform them (and yourself) a bit and then trust your instincts in the situations that emerge.

Wrapping Up

I want to wrap-up this post with caution though—traditional Project Managers DO need to reframe themselves and their approaches in an agile context. Throw away your templates and checklists that prescribe a specific approach to all projects & teams. Instead you must become context-based and situational in your approaches.

You must also engage your teams, not as an execution monitor or policy cop, but as a true partner.

I’ll leave you with the following two charts that nicely illustrate some of the focus and tempo changes that occur between Traditional & Agile PM activities.

Dec7bob2Dec7bob1

So, Project Managers—may you navigate these waters well and engage with your teams. They NEED YOU!

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

Why You Should Align Your Project and Company Goals

Each year, as project managers we take courses and read articles and books on how to improve our project management skills: how to track the critical path, influence without authority, tackle bigger scope and bigger budgets, work with remote teams, flush out the ‘right’ requirements, engage the teams we’ll need for success and many other topics. Often, these are great courses and articles with great tips and advice that we use every day to deliver projects assigned to us. One area where PMs aren’t always included—or do not involve themselves in—is the project selection process, that pre-initiation stage where the project is still a concept, someone’s brainstorm or someone’s personal pet project.
Many projects come from the must-do category—legal, compliance, regulatory, contractual (this last one is a big area and for the purposes of this discussion it will be left in the must-do category). But what about the rest of the project requests that are raised? There are infrastructure projects, which some companies define as must-do based on end-of-life criteria, while other companies include them as part of a discretionary project, such as a new product or new functionality. There are software projects—new options, features, products, functionalities—that will improve market share, increase customer experience, provide more features that customers can buy, improve turnaround time for transactions, allow customers to have more self-serve options, cut headcount, improve security, etc. How does a company select which projects will go ahead given the available project hours in a year or term?

Many project managers become involved or are assigned after a project is approved and only focus on the project they’ve been handed; they do not question whether it is the ‘right’ project to be done. However, as a responsible project manager, it is your place—and your responsibility—to at least raise the question of how the project fits in with the company’s goals and strategic direction.

Projects that do not align with the company’s goals—projects done because someone has a personal interest or is focusing only on their own area/department—do not necessarily further company interests. Such projects will not get the proper management support they need to be really successful, they will have over-inflated benefits that look attractive but are not based on realistic data (without these good-looking benefits, they wouldn’t have made it past the selection stage) and they will ultimately fail even if they are successfully installed.

In order to ensure that the project actually benefits the company, PMs should get to know the company short- and long-term goals. Most of these are easily available in the company’s intranet, and some companies want to ensure employees are aware of the goals so they print posters that are posted in company hallways or lunch rooms. If they’re not easily available, ask your manager/director, or the person who assigns you your work. If they don’t know, then the project may not be aligned to the company’s goals.

Go through the goals one by one and work with the sponsor and key stakeholders to identify the ways in which the project does and does not align with each stated goal. If there are aspects that do not align to the goals, spell these out in the Charter. Taking the time to write this out in plan form may save you from issues being raised later in the project. Be as specific as possible; if the company goal is to improve the customer or client experience, state specifically how this project does or does not contribute to this goal. If the company goal is to be a luxury brand or to have a reputation for world-class service, list the ways that this project will help or hurt this perception; again, documenting the negatives as well as the positives may get the sponsor/key stakeholders to reconsider their approach before the project is too far down an odious road. Once you are sure that the project is aligned to the company’s goals, ensure that this is spelled out in the Charter and is signed off by major stakeholders.

Once the information is documented and approved, ensure that the project team understands how this project fits those goals. Use this information throughout the life of the project to help guide decisions, including change requests. It is by no means the only information to be considered, but should be included with other information to make sure that the project doesn’t sway from the intended goal.

Perhaps the company already does this before the project gets the approval to proceed. In this case, the exercise should be very simple to complete and most of the information will already be in the business case. In this situation, once the information is in the Charter, it will be signed off and you can proceed to the next phase of your project.

You may be surprised to find that in projects where this alignment is not considered up front, once you complete the exercise and document the findings, the project may stall as people discuss and possibly reconsider the decision to proceed. Do not view this as a time-waster or think that you are being a troublemaker—a boss or sponsor who interprets this as such probably has other reasons for wanting this project to proceed, reasons that will likely come to light through the exercise. Remember that your goal as a project manager is to deliver the project—not just any project, but the project that will benefit the company. 

When you do the right project, there is engagement at all levels, there is support, and there is also increased attention and monitoring. There is also likely more pressure as this is a strategically important project. Welcome this attention as it will help you to deal with risks more effectively and prevent some risks from becoming issues.

A project that doesn’t align to the company’s goals will not contribute to the company direction—it is a project that will not meet expectations, that will attract only a handful of customers, that will actually pay back in multiple years rather than months, and that doesn’t get the attention of the senior management team when issues arise. It is the type of project we’ve all installed after arduous hours and many challenges that everyone forgets about as soon as the installation is over. This is not the project we enjoy installing—it’s the project we’re all glad is over. And this is not the project we should be doing. 

Ultimately, the decision to proceed comes from the business and leadership team. If they accept that the project does not support or contribute to the company’s goals, then at least it is documented and approved, and can be referred to in later stages if the question “why are we doing this project” is raised. If that happens, you are prepared to hear this question and can prepare for the inevitability that the project will not get the attention to help it proceed smoothly.

Don’t forget to leave your comments below.


Effie Sismanis is a Project Management consultant working in Toronto, Canada. Effie has spent the last 17 years delivering IT projects for the Financial Services & Telecom industries in Canada and internationally. PMP-certified since 2004, Effie started out working in a call center, and appreciates that business knowledge is a key to delivering successful projects.