Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Project Management’ Category

Fostering cross-project learning and continuous improvement in projectised environments.

with 3 comments

Introduction

There’s much angst and hand-wringing about how difficult it is to engender a learning environment in projectised organisations. In an earlier post I made a case for an emphasis on learning rather than efficiency in project execution. That  discussion focussed on challenges around learning within a project.  These challenges are magnified in the case of learning across projects. In most organisations, the responsibility for cross-project learning typically rests with the project management office  (PMO) or its equivalent – whether or not it exists as a formal entity. In a paper entitled, How Project Management Office Leaders Foster Cross-Project Learning and Continuous Improvement, published in the Project Management Journal, Jerry Julian investigates how project management office leaders facilitate cross-project learning. Based on his findings, he also presents some recommendations for improving cross-project learning and foster continuous improvement. I summarise and discuss the paper below.

The paper begins with the observation that, “…project teams often start solving problems anew rather than learning from previous projects within the same organisation. This often means that the end of a project is the end of collective learning…” As they are the focal point for all project work within the organisation, PMOs are best placed to foster cross-project learning. Further, since they serve as a repository for project documentation, they are also well placed to identify potential improvements and implement these after due consideration.  The paper explores how PMO leaders perceive their role in fostering learning and continuous improvement.  The specific questions addressed are:

  1. What do PMO leaders see as their responsibilities in fostering learning and continuous improvement?
  2. How do they foster cross-project learning?
  3. What are the enablers and barriers (as perceived by them) to cross project learning and continuous improvement.

The author attempts to  answer these based on data gathered from surveys and subsequently validated through focus groups. Regardless of the validity of the author’s methodology, the paper serves to inform PMO leaders about what their peers are doing to foster cross-project learning. It therefore merits attention from PMO or program/portfolio managers.

Background

One of the most common activities associated with cross-project learning is the practice of conducting project post-mortems aimed at finding out what went well and what didn’t.  From his review of the literature,  the author finds that although the value of such “lessons learned” sessions is widely acknowledged, many organisations fail to conduct them in practice (see this paper by Maximilian von Zedtwitz, for example).  Amongst those that do, there is general dissatisfaction with the process. As Anne Keegan and Rodney Turner state in this paper, “…Project team members frequently do not have the time for meetings, or for sessions to review lessons learned. Often project team members are immediately reassigned to new projects before they have had time for lessons learned sessions or after action reviews. In no single company did respondents express satisfaction with this process, and all claimed that time pressures exert enormous pressure, and reduce the effectiveness of these learning practices.”

However, the problem is deeper than time pressures. As Jacky Swan and coworkers point out in this paper, the assumption that knowledge can be captured and transferred in textual form is itself questionable, basically because it ignores that knowledge is often embedded in practice, and hence cannot be understood independently of that practice. If this is true – and most experienced project managers would recognise that it is – then the traditional lessons learned document is less useful than it is thought to be. What might be more useful is in knowledge is transferred in other ways, such as narration and joint work.  In essence, many lessons can only be learned by doing – furthermore, doing in the right context.  This isn’t new: it is central to the idea of reflective practice articulated by Donald Schon in his 1983 classic entitled The Reflective Practitioner . It is also central to Jean Lave and Etienne Wengers ‘ ideas on communities of practice. Accordingly, the author uses these concepts in developing a framework to study the role of PMO leaders in cross-project learning.

Framework and Methodology

Following, Wenger the author views (cross-functional) project teams as being made up of  people from multiple communities of practice, and a PMO as being embedded in a “constellation of practices” through which knowledge about past projects must be negotiated and shared.  In this framework a PMO leader can be seen as a broker between various communities of practice – which may include senior management, project teams and the PMO itself. A PMO leader would do things that promote communication between various communities of practice. Specifics of what those “things” might be include: alignment (ensure everyone’s “on the same page”), translation (for instance, between IT and business-speak), coordination (ensure people’s efforts are directed to the same end) etc. The PMO leader, being at the boundary between multiple communities of practice, has a particular responsibility in managing boundaries between these communities. A PMO leader manages these boundaries by:

  • Promoting boundary encounters (single or discrete encounters that provide connections across practices)
  • Developing effective boundary practices (practices that sustain connections across boundaries)
  • Creating / archiving useful boundary objects (artefacts – documents, stories etc.- that organise interconnections across communities).

In addition to managing boundaries, the PMO leader should reflect on the knowledge gained in boundary encounters. Such reflection could be at the level of

  • Content: review how ideas have been applied to solving problems.
  • Process: review the problem solving process.
  • Premise: review the assumptions underlying the process.

Ideally reflection should occur at all three levels. In this view, the PMO leader is not just the custodian of project-related processes, but also a driver of process improvement. The author uses the aforementioned concepts of communities of practice (and the boundaries between them) and reflection (or reflective learning) to frame his research methodology and subsequent analysis. To gather data, the author interviewed several PMO leaders drawn from various industries. Prospective interviewees were identified through 20 initial contacts and then using a snowball sampling strategy whereby initial contacts and others were asked to provide referrals to individuals who met the author’s selection criteria. Data collection was done through a pre-interview questionnaire followed by an in-depth interview. The paper has a fairly detailed description of the methodology, so I’ll leave it at that and proceed on to the findings which are likely to be of greater interest to my readers.

Findings

The author’s results are best discussed in the context of the research questions posed in the introduction:

Perceptions of PMO leader responsibilities relating to cross-project learning

  • 75% of participants said that their primary responsibility was to ensure that projects were delivered on time and within budget and expectations.
  • 60% required project teams to identify lessons learned.
  • 45% said that continuous improvement of project performance was an important part of their job.
  • 45% felt that they were responsible for consistent adoption of project management practices across the organisation.
  • 20% said that their responsibilities included providing a learning and development environment for project managers.

How PMO leaders foster cross-project learning

Unsurprisingly, every interviewee claimed that they facilitated cross-project learning by brokering connections between senior management, project teams and other communities. They do this through a variety of boundary practices, objects and encounters. Specific boundary practices include:

  • Lessons learned practices (85%)
  • Status and project reports to senior management and other governance processes (85%)
  • Common project management practices (80%)
  • Knowledge sharing forums (40%)

Boundary objects used to foster connections across projects include:

  •  Tools and templates (85%)
  • Systems (65%)
  • Documents (40%)

Boundary encounters included meetings to

  • Intervene when projects were going off-track
  • Transfer project management knowledge to project teams
  • Improve processes used on projects.

In addition it was found that about half the interviewed PMO leaders engaged in content and process reflection to diagnose project-related problems and to help project staff and other stakeholders learn from prior projects.

Enablers of cross-project learning

The following were the major findings relating to enablers of cross-project learning:

  • 60% of those interviewed believed that a network of strong relationships is important to enabling cross-project learning.
  • 6% thought that senior management support is important.
  • 30% believed that organizational culture plays an important role.
  • 25% believed that it is important to have a neutral facilitator
  • 25% emphasised the importance of professional development of project managers via training, apprenticeships etc.
  • 10% believed that reflection throughout the course of the project (rather than just at the end) is critical.

Barriers to cross-project learning

The following were the author’s findings relating to barriers to cross-project learning:

  • 55% identified the lack of direct authority over project managers as a major barrier.
  • 45% thought that time pressures were an important factor.45% reckoned that frequent staff rotation hindered cross project learning.
  • 35% felt that fear of reprisals prevented staff from airing or owning up to mistakes.
  • 20% thought that lack of senior management support played a role.
  • 20% identified the deferral of learning to the end of the project – i.e. lack of continuous reflection and improvement – reduced the effectiveness of learning.

Analysis and discussion

On analysing his data, the author finds that PMO leaders broker learning through a variety of activities, including:

  • Project intervention – 35%
  • Status reporting and governance – 17%
  • Lessons learned practices -16%
  • Process improvement -12 %
  • Transfer of standards and practices -12 %
  • Knowledge sharing fora – 7%

The author acknowledges that the large percentage associated with the first item might be due to a framing effect – the questions asked in the interview specifically solicited critical incidents in which intervention was required. He also suggests that the relative importance of the reporting/governance item is due to the fact that most PMO leaders consider project performance to be their primary responsibility. Since PMO leaders are often judged on project performance, it is common for them to dashboards to keep track of project statuses. In these, statuses are monitored through traffic light reports, wherein projects that are going well are coded green; those in potential difficulty, yellow; and those in trouble, red. Most often, projects doing well are ignored and only those in trouble are given attention. This leads to what the researcher calls “red-light learning” wherein lessons are learnt only in the context of something going wrong. Potentially useful information pertaining to “what went right” is ignored.

Based on the findings described in the previous section, the author posits that social capital  is a key enabler of  cross-project learning. In the present context of cross-project learning, it is important for PMO leaders to build social capital by developing connections to individuals and other social networks (project teams, expert groups etc.) both within and outside their organisations. On the other hand the findings suggest that, defensive routines are barriers to cross-project learning. The term defensive routine was coined by Chris Argyris, who defined it as, “..actions or policies that prevent individuals or teams of the organization from experiencing embarrassment or threat…” An example of this, familiar to those working in projectised environments, is the unwillingness of project team members to talk about things that didn’t go so well. Most often such defensive routines point to a deeper malaise – in the case of the example, unwillingness to discuss what went wrong may be due to a “blame culture” within the organisation.

The findings indicate that PMO leaders broker learning through a variety of boundary practices. The author classifies these into two categories: retrospective and prospective. The former includes activities aimed at generating and reviewing knowledge from past projects (e.g. lessons learned, status reporting), whereas the latter is aimed at applying knowledge gained in past projects to future ones (e.g. process improvement, knowledge forums).  The author refers to these practices as “collective brokering.”  In his words, “PMO leaders can be viewed as knowledge brokers who, through the establishment of retrospective and prospective brokering practices, help their organizations learn from past project experiences by embedding process knowledge into organizational routines that can be transferred to new or existing projects.”  In my opinion, the reference to organizational routines is unfortunate, as routines imply rigidity. Perhaps the term “organizational practices” may be more appropriate here – implying a degree of flexibility and adaptability. See this post by Nikolai Foss for more on organizational routines versus organizational practices.

Concluding Remarks

The paper ends with some conclusions and recommendations. I list these below, along with some comments. Conclusions first:

  1.  PMO leaders are knowledge brokers who facilitate organizational learning and continuous improvement.
  2.  Organizational routines that incorporate knowledge gained from past projects provide a vehicle for improving an organisation’s everyday processes.
  3. Defensive routines can hinder organisational learning from projects.

The view of PMO leaders as knowledge brokers is a useful one: PMO leaders, by virtue of their involvement in diverse projects across the organisation, are uniquely placed to serve as catalysts for learning and improvement. The second conclusion merely states that knowledge gained from projects should, where possible, be incorporated into an organisation’s day-to-day work processes. I’m sure many project and program managers will concur with the third conclusion. I suspect it is the main reason why – so often – not much is learnt from lessons learned sessions. Finally, the author presents some recommendations for PMO leaders. These are:

  1. To focus on building up social capital across multiple communities (within and outside the organisation) through the development of relationships based on trust, professional development and mutual understanding.
  2. To focus on  learning from both successful and failed projects.
  3.  To reflect throughout the course of a project, not just at the end.
  4. To use neutral facilitators in order to get the most out of project retrospectives.

The recommendations range from the very general (the first one) to the very specific (the fourth one). It is all good advice,  no doubt. However, I can’t help but feel that it isn’t really new: most PMO managers who understand their role in fostering cross-project learning already know this from experience.

References:

Julian, Jerry., How project management office leaders facilitate cross-project learning and continuous improvement, Project Management Journal, 39 (3), 43-58. (2008).

Written by K

March 12, 2009 at 11:15 pm

Project portfolio management for the rest of us

with one comment

Introduction

In small organisations,  projects are often handled on a case-by-case basis, with little or no regard to the wider ramifications of the effort. As such organisations grow, there comes a point where it becomes necessary to prioritise and manage the gamut of projects from a strategic viewpoint. Why?  Well, because if not, projects are undertaken on a first-come-first-served basis or worse, based on who makes the most noise (also known as the squeakiest wheel).  Obviously, neither of these approaches serves the best interests of the organisation. The issue of prioritising projects is addressed by Project Portfolio Management  or PPM (which should be distinguished from IT Portfolio Management). This post presents a simple approach to PPM; one that can be put to immediate use in smaller organisations which have grown to a point where an ad-hoc approach to multiple projects is starting to hurt.

Let’s begin with a few definitions:

Portfolio: The prioritised set of all projects and programs in an organisation.

Program: A set of multiple, interdependent projects which (generally, but not always) contribute to a single (or small number of) strategic objectives.

Project: A unique effort with a defined beginning and end, aimed at creating specific deliverables using defined resources.

As per the definition, an organisation’s project portfolio spans the entire application and infrastructure development effort within the organisation. In a nutshell: the basic aim of PPM is to ensure that the projects undertaken are aligned with the strategic objectives of the organisation. Clearly then, strategy precedes PPM – one can’t, by definition, have the latter without the former. This is a critical issue that is sometimes overlooked: the executive board is unlikely to be enthused by PPM unless there are demonstrable strategic benefits that flow from it.
 
It is worth pointing out that there are several program and portfolio management methodologies, each appropriate for a particular context. This post outlines a light-weight approach,  geared towards smaller organisations.

Project portfolio management in three minutes

The main aim of PPM is to ensure that the projects undertaken within the organisation are aligned with its strategy. Outlined below is an approach to PPM that is aimed at doing this.

The broad steps in managing a project portfolio are:

  1.  Develop project evaluation criteria.
  2. Develop project balancing criteria. Note: Steps (1) and (2) are often combined into a single step.
  3.  Compile a project inventory.
  4. Score projects in inventory according to criteria developed in step (1)
  5. Balance the portfolio based on criteria developed in step (2). Note: Steps (4) and (5) are often combined into one step.
  6. Authorise projects based on steps (4) and (5) subject to resource constraints and interdependencies
  7. Review the portfolio

I elaborate on these briefly below

1.  Develop project evaluation criteria: The criteria used to evaluate projects are obviously central to PPM, as they determine which projects are given priority. Suggested criteria include: 

  • Fit with strategic objectives of company.
  • Improved operational efficiency
  • Improved customer satisfaction
  • Cost savings

 Typically most organisations use a numerical scale for each criterion (1-5 or 1-10) with a weighting assigned to each (0<weighting<1). The weightings should add up to 1. Note that the above criteria are only examples. Appropriate criteria would need to be drawn up in consultation  with senior management.

2. Develop balancing criteria: These criteria are used to ensure that the portfolio is balanced, very much like a balanced financial portfolio (on second thoughts, perhaps,  this analogy doesn’t inspire much confidence in these financially turbulent times). Possible criteria include:

  • Risk vs. reward.
  • Internal focus vs. External (market) focus.
  •  External vs. internal development

3. Compile a project inventory: At its simplest this is a list of projects. Ideally the inventory should also include a business case for each project, outlining the business rationale, high level overview of implementation alternatives, cost-benefit analysis etc. Further, some organisations also include a high-level plan (including resource requirements) in the inventory.

4. Score projects: Ideally this should be done collaboratively between all operational and support units within the organisation. However, if scoring and balancing criteria set are set collaboratively, scoring projects may be a straightforward, non-controversial process. The end-result is a ranked list of projects.

5. Balance the portfolio: Adjust rankings arrived at in (4) based on the balancing criteria. The aim here is to ensure that the active portfolio contains the right mix of projects.

6. Authorise projects: Projects are authorised based on rankings arrived at in the previous step, subject to constraints (financial, resource etc.) and interdependencies. Again, this process should be uncontroversial providing the previous steps are done using a consultative approach. Typically, a cut-off score is set, and all projects above the cut-off are authorised. Sounds easy enough and it is. But it can be an exercise in managing disappointment, as executives whose projects don’t make the cut are prone to go into a sulk.

7. Review the portfolio: The project portfolio should be reviewed at regular intervals, monitoring active project progress and looking at what’s in the project pipeline. The review should evaluate active projects with a view to determining whether they should be continued or not. Projects in the pipeline should be scored and added to the portfolio, and those above the cut-off score should be authorised subject to resource availability and interdependencies.

The steps outlined above provide an overview of a suggested first approach to PPM for organisations beginning down the portfolio management path. As mentioned earlier, this is one approach; there are many others.

Conclusion

Organisational strategy is generally implemented through initiatives that translate to  a number of programs  and projects. Often these initiatives have complex interdependencies and high risks (not to mention a host of other characteristics). Project portfolio management, as outlined in this note, offers a transparent way to ensure that the organisation gets the most bang for its project buck – i.e that projects are implemented in order of strategic priority.

Written by K

February 23, 2009 at 9:01 pm

Dysfunctional IT attitudes: processes are more important than people

with 3 comments

The service desk phone rang one morning. The guys were busy attending to other jobs, so the manager picked up the call, “Morning, IT service desk, Jake speaking. How can I help you?”

 “I had asked for Consolidate to be installed on my new computer, but have just noticed that it wasn’t.” The lady at the other end of the line sounded irritated. The software should have been installed on her computer – it was on top of the list she had provided to the service desk when she’d put in the request for her new computer.

“Have you logged a  service request?” enquired Jake.

“Yes,” she said, ‘but this is urgent. I have to send my sales figures for the month to head office this morning, and I can’t do it without Consolidate. Could you please send someone up right away?”

There was a short pause at Jake’s end. “I’m looking at the SLA right now, and Consolidate isn’t listed as a business critical application. There’s no way we can do this right now.”

“Look, it’s critical as far as I’m concerned. It’s got to be done right away or head office won’t get their sales figures. So, when can I expect a response?” Her annoyance levels were starting to increase

“Not before tomorrow, or may be even day after, depending on how soon we clear other, pending jobs.”

“I think I’ve made it clear this is important. Can’t you do it sooner?”

“No.” Jake clearly thought that no further explanation was necessary. Can’t have folks jumping the queue; service desk processes were put in place for a reason.

She took a more conciliatory tone, “Please understand,” she said, “I wouldn’t make an issue out of it if it weren’t important… the sales figures must be done by this afternoon. I just need the application installed; it shouldn’t take more than five minutes.”

“Sorry, you’ll just have to wait.” He didn’t sound sorry at all.

She’s starting to get really ticked off now. “It was a help desk mess-up in the first place. You should take responsibility and fix it now.”

“Perhaps you didn’t hear what I said; someone will come by tomorrow or day after. That’s the best we can do given that Consolidate is not a business critical application. You’ll just have to wait your turn.” There was no response from her side, so he added, “We have processes in place. We can’t bypass them for just any request.”

Jake’s reference to processes only annoyed her further, “Obviously your processes – whatever they may be – don’t work. The application should have been installed when I got my computer.”
 
“I’m sorry about that, but I can’t make any exceptions to the way we deal with service requests.” He sounded even less sorry now.

She seethed. “Thanks….you’ve been so very helpful.” Her tone made it clear that she thought Jake was being singularly unhelpful. She hung up, not waiting for a response.

Jake had a point: proper functioning of a service desk depends on processes. Bypassing these can lead to problems – not the least being that everyone would expect an instant response. Service desk processes ensure efficiency and transparency. Everyone knows what they can expect when they lodge a request; expected service levels being documented in excruciating detail in  service level agreements. Yes, all this is true, and can’t be argued.  Even so, I can’t help but think that the lady deserved better.  Jake could have explained his position in a more acceptable way, or damn it – even got off his rear and fixed the issue himself in five minutes flat. He would have bypassed his beloved processes, but  gained much goodwill in doing so.

Over the years, processes have become entrenched in corporate IT, as witnessed by the plethora of best practices such as ITIL and  CMMI. Implementation of processes based on these frameworks and methodologies helps standardise the way corporate IT carries out its functions. This, in most cases, is a good thing. Yet, processes aren’t the be all and end all of IT. At the receiving end of IT services are ….yes, real people doing real work that keeps businesses ticking. Conflicts between IT and the business occur when IT folks forget that people are more important than processes; like Jake in the true incident described above. This holds not just for operational IT (like the service desk), but also for development work (i.e. projects)  as I’ve mentioned in an  earlier post. Trouble is,  processes  trump people more often than not.  When that happens, things aren’t working the way they should- processes are intended to help people, not to hinder them. This is something folks who work in corporate IT would do well to keep in mind; especially these days, when business leaders are being seduced by the call of outsourcers and the IT-as-utility crowd.

All too often, IT management thinks of processes as a panacea for all IT ills. The way I look at it is a little different: processes are fine and good, and even necessary; but the people who are served by IT must come first. If that means making the occasional exception to a mandated process, then so be it.

Written by K

February 15, 2009 at 11:35 am