Project portfolio management for the rest of us

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.

Dysfunctional IT attitudes: processes are more important than people

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.

Why I didn’t do some of the things I had to do…

Why do people postpone important tasks?  Research by Sean McCrea and his colleagues may provide a partial answer. Theyfound that people tend to procrastinate when asked to perform tasks that are defined in  abstract terms. What this means is best explained through one of their experiments: half of a group of students were asked to describe how they would carry out a mundane task such as opening a bank account, and the other half  were  asked to describe reasons why one might do that task  – i.e. why one might want to open a bank account.  The first task is straightforward, and needs little thought  prior to execution. The second one is more abstract; some deliberation is required before doing it.  Even though all participants were offered a small (but interesting enough) sum of money if they completed the task within three weeks, it was found that most of those who were given the concrete task completed it on time  whereas more than half those assigned the abstract task failed to complete it.  The researchers use the concept of psychological distance to describe this behaviour. Psychological distance in this context is a measure of the closeness (or remoteness) a person feels to a task, abstract tasks being more “distant” in this sense than concrete ones.

Reading about this reminded me of an incident that occurred many years ago, just after I’d made a career switch from academic research to business consulting. One of the partners in the firm I was working for had asked me to write a project proposal for a new client. He assumed I knew what was needed, and offered no guidance. I had a half-hearted try at it, but couldn’t make much headway.  Like the stereotypical student, I then put it off for several days. The day before the deadline, fearing the consequences of inaction,  I got down to it.  I spoke to a few colleagues to make the task clearer, spent some thinking it through then, finally, wrote (and rewrote) the proposal well into the night.

Seen in the light of Dr. McCrea’s research, my procrastination was simply a normal human reaction to an abstract task. Once I was able to define the task better – with the help of my colleagues and some thought – my reasons for procrastination vanished, and with it my mental block.

I see this operate in my current job too. I work with a small group of developers who tackle a wide range of projects ranging from enterprisey stuff (such as the implementation of CRM systems), to the development of  niche applications used by a handful of people. The small size of our group means that everyone has to do a bit of everything – design, coding, testing, maintenance, support and (unfortunately) … documentation. Now, in keeping with the stereotypical developer, most of the mob detest doing documentation.  “I’d rather do maintenance coding,” said one. When asked why, he replied that it took him a lot more effort to write than it did to do design or coding work.   Of course, this is not to say that cutting coding is easy, but that developers  (or the ones I work with, at any rate)  find it less remote psychologically – and hence easier –  than writing.  So, when required to do documentation, they typically put it off if as much as possible.

The relationship between task abstraction and procrastination indicates how  managers can help reduce the  tendency to procrastinate.  The basic idea is to reduce task abstraction, and hence reduce the psychological remoteness an assignee feels in relation to a task. For example, when asking a coder to write documentation, it might help to provide a template with headings and sub-headings, or make suggestions on what should and should not be included in the documentation. Anything that makes the task less abstract will help counter procrastination.

Tasks can be made more concrete in a number of ways. Some suggestions:

• Outline  steps  required to perform the task.
• Providing more detail about the task.
• Narrow the task down to specifics.
• Provide examples or templates of how the task might be done.

Of course, not all procrastination can be attributed to task abstraction. Folks put off tasks for all kinds of reasons – and sometimes even for no reason at all.  However, speaking from personal experience,  Dr. McCrea’s work does ring true:  I didn’t do some of the things I had to do simply because they weren’t clear enough to me – like that project plan I was supposed to have started on a week ago.  But advice is easier given than taken. With only a gentle pang of guilt, I put it off until tomorrow.