Easy in theory, difficult in practice

One of the symptoms of lower organizational project management maturity is having more projects active than can predictably be delivered by teams.  Even if processes have been implemented for work intake or prioritization, if governance committees continue to accept all project requests presented to them (i.e. the project funnel is a tunnel) the likelihood of staff overworking but still under delivering is high.

In most cases, this may not be the worst thing that could happen – so long as project and functional managers are able to keep their team members focusing on completing the most critical milestones, delays on less important projects might be an acceptable inefficiency.

Where this does become more concerning is when there are multiple genuinely important projects underway and this gets coupled with a work allocation model that has most staff performing operational and project duties.  In such cases, there is a strong probability that at one or more times of the year, there will be a convergence of “can’t miss” milestones across multiple projects conflicting with the completion of one or more critical operational initiatives.

In an organization with lower levels of maturity, this situation can be similar to the chaos that would ensue if a half-dozen footballs were dropped in the midst of an unsupervised group of preschoolers.  In the organizational context, staff will focus on the project milestone or operational activity which has been given the greatest priority by their project manager (in strong or some balanced matrix organizations) or by their direct reporting manager (in functional, weak or some balanced matrix organizations).  Since not each team member will receive the same instructions or priority directions, the risk is high that nearly all milestones will be missed.

To avoid such entropy, the easy answer is for the organization to take on less work – they should cut their coat according to their cloth.  However, this requires a fairly detailed quantitative understanding of staff capacity and capability as well as a governance team that is judicious about project selection & scheduling – both signs of a higher maturity organization.

Failing this, what else can be done?  Try to avoid milestone convergence at all costs.

While the ultimate tool to help achieve this might be a detailed cross-project/operations schedule, this will take a tremendous amount of effort to develop and, in low maturity organizations, it will be out-of-date the moment it has been published.

A simpler approach is for project & functional managers to maintain a list of critical milestones for their project and operational responsibilities for the next few quarters.  The only information required to be captured is the name of the initiative, the milestone description, the true degree of schedule flexibility for the milestone (or rather, the impact if the forecast date slips) and the forecast date. 

When developing project schedules or creating operational calendars, project and functional managers should review this list and if they are in a situation where a new milestone will conflict with existing ones, a quick meeting should be called to identify the “pecking order” at the milestone (NOT project or initiative) level, and rescheduling should take place on all other initiatives.  If this can’t be done for a particular convergence point, at least the organization will have a sufficiently advanced “head’s up” to assign additional staff or other such techniques of avoiding contention.

Reducing the number of active project and operational responsibilities for staff is a long term goal for lower maturity organizations, but a good short term objective is to shift focus to key milestones across concurrent work streams to avoid perfect storms.

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

In a recent role, I had the opportunity to review the lessons submitted by teams running large, complex projects and programs and found that over 90% of what was being captured and shared was of low or no value.

Back in April 2009, I published my very first blog article titled "Lessons Learned; Avoid the Oxymoron".  Since that time, I've gained a broader appreciation of the multiple challenges organizations face when trying to get sustainable, reusable knowledge out of projects and felt it was time to put a capstone on my writing about this specific topic.

So what have I learned about lessons over the past decade?

Patterns

• Frequent identification - either on a fixed cadence such as in a sprint ending retrospective or just-in-time based on a team's recognition that there is something of value to be captured and shared.
• Scrubbing and distillation - lessons are like a diamond hiding within a drab rock. Someone needs to take the time to harvest reusable knowledge from a raw lesson. This is not simple because stripping out too much specificity will result in a generic, low value outcome, but leaving in too much contextual detail will make it hard for a reviewer to decide whether it is applicable to their project or not.
• Category-driven response - depending on whether a lesson is a reminder, an organizational blocker or true knowledge, its deposition will be quite different. Reminders might be a call for more training or guidance whereas blockers should be escalated to an appropriate owner.
• Context-based guidance - rather than poring over hundreds of lessons spanning a project's lifecycle, it is helpful if a reviewer can be presented with a subset of lessons applicable to where they are in a project.
• Likes and dislikes - give reviewers the ability to like or dislike lessons. Let the free market decide which are truly useful and should be retained and those which can be safely purged.
• Regular incorporation into standards - instead of leaving it up to an individual to decide whether a particular lesson should be followed or not, those which are applicable in most cases should be baked into your templates, standards and policies.

Anti-patterns

• Lesson suppression - sometimes the most valuable lessons are those which weren't shared. A good PM must provide a safe environment and approach to help stakeholders be open about sharing the good, the bad and the ugly.
• Finger pointing - PMs need to ensure that lessons learned sessions don't turn into the blame game.
• Going through the motions - a risk of capturing lessons frequently is that the activity becomes mechanical and produces little value. Team members should have the confidence to cancel a session if there is nothing of value to be shared.
• Superficial parroting - as with requirements, the value of lessons comes from their analysis, not just regurgitation.

"The only real mistake is the one from which we learn nothing" - Henry Ford

A Harvard Business School blog article shared some key lessons in creating a culture of quality within one’s organization.

One of those key lessons was the importance of leadership emphasis in creating such a culture.

While it is certainly important for leaders to model the quality behaviors they would like their individual divisions to follow, this extends beyond actions to the share of airtime given to quality through their regular interactions with their direct reports and with other staff.

In the context of project delivery, one way to identify whether there is a genuine commitment to quality is to count how frequently delivery-focused language (vs. quality-focused language) gets used during executive management’s participation in steering committee meetings or during their reviews of project or portfolio-level reports.

If the predominant focus in their feedback is on hitting dates or meeting financial constraints and only rarely are the topics of deliverable quality or requirements achievement mentioned (except when it is in the context of schedule, cost or regulatory impacts), this emphasis is not likely to be missed by project teams.  In turn, teams will tend to focus their efforts on schedule and cost targets – short term gains for long term pains.  In such cases, it doesn’t matter how many town hall meetings are held in which the importance of quality is proclaimed by leaders – staff know that’s just lip service.

To create a more visible balance between tactical delivery objectives and quality-related ones, sponsors and executive stakeholders should require quality-focused metrics at both the portfolio & project levels, and the determination of project health status should go beyond triple constraint or financial realization indicators to also incorporate assessments of quality.  Dashboards, wall posters and other such high visibility tools could be used to highlight quality metrics, tips & techniques.

This needs to go hand-in-hand with creating a culture where staff are not afraid to raise warning flags and where there is true transparency of health reporting from the team all the way up executive views.  In such a culture, taking a page from the Toyota Production System, executives could encourage their staff to be able to push a virtual “STOP” button alerting them of quality concerns in a timely fashion.

Where focus goes, energy flows.

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

Anyone that has taken a course in risk management knows that there are multiple strategies available to respond to identified negative risks including avoidance, transferral, escalation, acceptance and mitigation. 

One would assume that risk owners would select the right response for a given risk, but most of the risk registers I’ve ever reviewed usually reflect only two responses – accept and mitigate.

For low severity risks which are usually characterized as having either a very low probability of occurrence as well as a low to medium impact if realized, the effort required to eliminate them may cost more than the benefits of doing so hence acceptance might be the best response. For risks which lend themselves to mitigation and whose severity is significant enough that it merits the effort, developing and executing an active response, that might be the best strategy.

But when was the last time you actually saw a project team propose and execute an avoid or transfer response strategy?

There are a couple of common ways in which an avoid response could be used – one is to reduce or modify scope which in extreme cases could even imply electing not to proceed with a given project.

For example, if a highway is to be built spanning multiple cities in a developing country, yet I know that the region between two of the cities is plagued by insurgent activity, I might propose that the project’s scope be reduced to skip connecting those two cities until order is restored to avoid incurring any labour-related safety concerns. 

It is also possible to avoid a risk by changing one’s approach to delivering scope – in the highway construction example, while the straight path between two cities might be the shortest, if that would result in the destruction or disturbance of some ancient ruins, significant stakeholder risks could be avoided by taking a longer route.

With a transfer strategy, the objective is to shift the risk to a third-party.  While the common method of doing this is to purchase insurance, outsourcing a subset of your project’s scope to a subcontractor who assumes full risk of quality or schedule issues is also an option.

One of the key benefits of both the avoid or transfer response strategies is that they can completely eliminate specific risks which is an ideal outcome in those cases where risk severity is extreme.  However, the efficacy of these strategies tends to diminish over the lifetime of a project – during initiation and planning, they can be quite effective, but once scope and approach are nailed down, it can be a much costlier proposition to avoid or transfer risks. 

As with all risk management activities, neither of these responses is free so it is important to balance the cost of avoidance or transfer against the expected financial and non-financial (e.g. reputational) impacts of risk realization before making response recommendations.

As Mr. Miyagi said in the Karate Kid Part 2: “Best way to avoid punch, no be there!”

(Note: this article was originally written and published by me in December 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:

• 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)