Easy in theory, difficult in practice

My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

What do I look for when reviewing resumes for project manager positions?

RBS is one more technique for your estimation tool belt!

Technical Competency for Project Managers – Valuable Asset or Source of Risk?

The Achilles Heel of project resource estimation is operational work

A self-managing team does not mean no rules!

A self-managing team does not mean no rules!

One of the more prevalent myths with agile delivery approaches is that the project manager should let the team develop their own working practices and rules of engagement to manage themselves.  While this sounds great in theory, in many cases it will result in disaster.

No question, in times of crisis over usually fairly short durations a team of professionals can develop creative ways to work together effectively and productively to resolve the situation but this doesn’t translate well into the world of most projects where the sense of urgency or shared goal is usually insufficient by itself to encourage productivity and efficiency.  While testing this hypothesis might make for a good social experiment and has been utilized regularly on reality TV shows such as The Apprentice, few organizations will want to take chances with their critical projects.

I’m not advocating the anachronistic use of rigid command and control practices on the part of the project manager.  While a lack of attention and guidance to work practices and results may result in chaos, being a slave driver is almost guaranteed to cause project failure along with permanently damaged relationships between the project manager and team members.

As with other project management situations, this becomes a balance between the “what” and the “how”.

The project manager needs to ensure that the team had a clear, consistent understanding of “what” the expected project outcomes and benefits are as well as “what” the key deliverables and activities are.  The project manager also should set expectations and require compliance with “what” he or she needs to develop plans and to track and report on progress for the project.

However, when it comes to “how” the work gets done and “how” progress reporting and other normal practices will be performed, the project manager should provide the team with the flexibility to explore and develop the most efficient method for them.  This doesn’t mean starting with a blank slate or letting the team radically change directions on a weekly basis.  It does mean reviewing the organization’s standard or de facto practices at the start of the project and educating the team on why these practices are important and then giving the team the opportunity to adapt these practices and to regularly review them during retrospectives.

Moving to a more “black box” approach to work management provides greater empowerment of team members without the risks implicit with totally abdicating management responsibility.

(Note: this article was originally written and published by me in June 2013 on my personal blog, kbondale.wordpress.com)

Posted on: February 15, 2018 05:59 AM | Permalink | Comments (12)

Project Managers & Business Analysts - Why Can’t We All Just Get Along?

You might disagree with me, but there is a greater co-dependency between the roles of a project manager and business analyst than with almost any other pair of project roles.

No doubt, a project sponsor is crucial to a project's success and it is critical that a project manager establishes a positive, mutually beneficial working relationship with their sponsor, but once the project gets underway, most project managers will find themselves spending much more time with the business analyst.

Requirements are one of the most frequently cited sources of project issues and an effective requirements management process can go a long way towards improving project predictability. Given this, one would expect that these two roles would naturally work very well together, or at the very least, would go out of their way to ensure that they weren't impacting each other.

Unfortunately, in many of the organizations I've worked with, this isn't the case, and while it might be easy to chalk up a few incidents to individuals, the number of times I’ve heard complaints between the two roles indicates there’s something deeper at play.

From the business analysts, common complaints about project managers include:

  • Appear to be focused solely on cost or schedule constraints without also embracing the criticality of having good quality requirements
  • Demonstrate an unwillingness or inability to provide assistance in ensuring that stakeholders are attending and contributing to requirements gathering or review sessions
  • Don’t bother to read or understand high-level project requirements documents
  • Support or initiate scope change decisions without proactively engaging the business analyst

On the other side, I’ve frequently met project managers who complain about business analysts who:

  • Appear to have no sense of time or cost constraints when producing their deliverables or appear unable or unwilling to provide effort or duration estimates for their work
  • Produce requirements documents which are unusable by other project team members or which don’t address the customer’s stated and unstated needs
  • Appear to forget that the second word in their job title actually implies the task of analyzing, distilling and refining requirements as opposed to just parroting what’s been received from stakeholders
  • Become unavailable for the remainder of the project’s lifetime as soon as their requirements documents have been signed off

While individual projects might suffer as a result of such challenges, the greater long term impact is the erosion of the mandatory trust and mutual respect which needs to exist between these roles - this will result in chronic challenges to projects.

While these symptoms appear quite varied, they usually relate back to one of the following two root causes:

  1. A lack of clarity regarding the responsibilities, drivers and expectations of each role, based on the context of a given project
  2. A lack of alignment in the performance objectives or metrics for each role, based on the context of a given project

One might assume that through osmosis if not through formal training each would be quite aware of the other’s role. This is absolutely the case when one is speaking theoretically about the functions which each performs. I’ve rarely heard complaints when project managers are being educated about the roles, standard practices and responsibilities of business analysts or vice versa. Trouble often begins when one tries to apply the theory to a given project and this is why I’ve added specificity in the ending clause of both of these root causes.

It’s common practice for project managers to have a preliminary expectations “get and set” meeting with their sponsors – this is often done as a particular executive might not have played that project role recently, or may not have ever worked with a particular project manager before. There’s really no good reason why a project manager shouldn’t extend the same courtesy to a role as critical to project success as the business analyst’s.

This meeting provides both individuals with the opportunity to walk each other through the practices they intend to apply based on the needs of the project and to discuss expectations each has for the other’s role. By covering ground rules at the outset, a number of future disconnects could be identified and resolved before they begin to impact project performance or the working relationship between the two roles.

Joint conferences have been held for project management and business analysis for many years, and PMI has doubled down on their commitment to business analysis with their new practice guide. Both of these are evidence of how inseparable the roles are. By taking the time upfront to understand how each role will work on a given project, one can almost hear the Turtles: “Imagine how the world could be, so very fine, So happy together

(Note: This article was originally written and published by me in May 2014 on Projecttimes.com)

Posted on: February 08, 2018 07:15 AM | Permalink | Comments (10)

Project Managers can Prevent the Three Signs of a Miserable Job

Patrick Lencioni’s book The Three Signs of a Miserable Job is an easy-to-read parable covering key sources of employee disengagement and what can be done to eliminate them.

The book takes the functional manager’s view – Lencioni states on his web-site “The primary source of job misery and the potential cure for that misery resides in the hands of one individual - the direct manager”. For staff working in a matrix organization, a significant proportion of their effort is spent on projects, hence Lencioni’s recommendations should be adapted for use by project managers as well.

The three signs that Lencioni identifies are irrelevance, inability to self-measure performance or success (or as Lencioni’s puts it, “immeasurement”) and anonymity. Let’s review some ways in which project managers can reduce these sources of misery.

Unless we are sociopaths, we want to know that the work we are doing is making a difference to someone, somewhere – without that we feel irrelevant. Projects are a medium for generating value through change, and if that change is expected to positively impact some stakeholder community, then that is something to feel good about.

Project managers should always ensure that their team understand the benefits of the work they are doing. This should start as early as the project kick-off meeting but that should not be where it ends. If the project manager can solicit periodic visits by representatives from stakeholder groups to talk to the team it can help to revitalize stress-dampened spirits.

Regular recognition of a team member’s efforts is important, but a generic “keep up the good work” is no substitute for one’s ability to quantify the progress they are making for themselves. As Lencioni explains, this is one of the benefits that salespeople enjoy – they have a very quantitative method of assessing if they are succeeding! For those of us whose days are spent in a never-ending stream of meetings without producing or selling anything tangible, self-assessment can be a little more challenging.

Projects provide an excellent opportunity to avoid this source of misery. By defining and completing a backlog of work items, team members are able to quantify their own progress. While this is not the primary rationale for scope decomposition, project managers could use this as part of their “sales pitch” to convince team members that this is a necessary practice. This is also the rationale behind the agile practice of using sprints or iterations – it is a lot easier to assess progress against work items that can be completed within one sprint than it is against activities that span multiple weeks or months.

Employees want to be recognized as individuals.

The ubiquitous use of the term “resource” should be banned – it furthers perceptions that team members are a fungible commodity. We may only work with assigned staff for a brief span of time, but it is in our projects’ best interests for us to get to know them as more than just a set of initials on a Gantt chart activity line.

It is a good practice for project managers to meet with team members as they are assigned to a project to review their work assignments and to set expectations for expected performance. This also provides a great opportunity to learn something unique about the team member and to share something unique about yourself with them.

Other opportunities for avoiding anonymity could be to start your team meetings by having someone talk about something interesting they did over the previous weekend. You could facilitate a team building exercise to identify team members based on a unique attribute, behavior or experience.

If you can demonstrate to your team members that you recognize and respect them as unique individuals, help them understand how the work they are performing matters and help them measure their own performance, you may realize John Quincy Adams’ quote “If your actions inspire others to dream more, learn more, do more and become more, you are a leader.”

(Note: this article was originally written and published by me in December 2012 on Projecttimes.com)

Posted on: February 01, 2018 06:34 AM | Permalink | Comments (8)

Sorry Mulder, with projects, “Trust no one” will usually guarantee failure!

An attendee from an agile project management webinar I delivered a while back asked how one can successfully manage projects (agile or otherwise) in an organization that has major trust issues.

After thinking about all the troubled projects I have witnessed or worked on, there is little doubt that there is a correlation between low levels of trust between key project roles and the ultimate success or failure of these projects.  There might be rare situations where the impacts of a lack of trust can be mitigated – for example, crisis projects or those where explicit contractual agreements can be drawn up between players, but in most instances, this issue can be one of the most damaging and yet most challenging to address.

So how can a project manager address this?

The first step is to identify the problem and understand the magnitude of impact.  Trust issues usually manifest themselves through negative communications, CYA-behaviors and body language – all cues that require a good combination of self-awareness and good observation skills.  Tying these behaviors to project issues starts to provide evidence that there is a real problem that needs to be addressed.

At this point, there are a variety of “baby steps” that can be taken to help the project team or organization re-cultivate trust.

  1. Team building exercises at regular intervals over the lifetime of the project and not just during initiation.
  2. Lead by example – don’t immediately assume that stakeholders or team members are lying to you or “out to get you”.  Only make commitments that you are able to keep.
  3. Hold the project organization (team members, customer & stakeholders) accountable to defined & communicated project rules of conduct and engage project sponsorship to support you in this process.
  4. Cultivate a sufficiently positive relationship with team members and stakeholders so that if you observe trust-related behaviors, you can (on a one-on-one basis) coach those involved to a more positive approach in the future.
  5. Make sure you have a trusted outside observer that can help to keep you “honest” by ensuring that you don’t fall into the “trust trap”.
  6. Practice 360 degree recognition – even for those that you or the team might originally have been inclined to distrust.

Take the time to ensure that the project organization is aligned with the project’s goals and success criteria – misalignment is a great way to strengthen mistrust.

Organization trust issues can appear like Goliath, but the slingshots of patience & predictability can help to slay this project über-villain.

(Note: this article was originally written and published by me in April 2011 on my personal blog, https://kbondale.wordpress.com)

Posted on: January 24, 2018 08:28 AM | Permalink | Comments (10)

So what’s in a (project) name?

Juliet might have said “That which we call a rose by any other name would smell as sweet” but I beg to differ when we are coming up with project names.

Here are a few of the ways in which good project names can make a difference:

  • Motivating and unifying a cross-functional project team that hasn’t worked together in the past and is not 100% dedicated to your project.  Ensuring that your project name is uplifting and somehow captures the essence of what benefits the organization and the team members will reap can help focus team efforts.
  • Engaging stakeholders and sponsors.  It might be easy as a stakeholder to ignore pleas from the project manager of the “implement ABC system version 1.2” but you’d think twice of doing this if the name was “reduce patient mortality due to transcription errors”…
  • Supporting that “outside in”, business-focused view of projects – this is especially true for technology projects.  IT is forever blamed as being disconnected from the business and purely technology-focused and picking technology-centric project names does not help your CIO foster credibility with his or her peers at the executive level.

So what are the hallmarks of a good project name?  Here are a few suggestions:

  • It should reflect the expected benefits or business outcomes of the project.
  • It should be short – short enough that you could give the project name & a brief description in the stereotypical thirty second elevator pitch.
  • It should be positive (e.g. reduce operating costs is not as positive as increase profitability)

The acid test is to visualize yourself at a conference presenting a case study about the success of your project upon its completion – would you be proud to state its name, or would you cringe and mutter it under your breath?

(Note: this article was written and published by me in June 2010 on my personal blog: https://kbondale.wordpress.com)

Posted on: January 19, 2018 08:36 AM | Permalink | Comments (9)

"Less is only more where more is no good"

- Frank Lloyd Wright