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)
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:
On the other side, I’ve frequently met project managers who complain about business analysts who:
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:
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)
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)
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.
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)
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:
So what are the hallmarks of a good project name? Here are a few suggestions:
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)