Category Archives: Strategy

Portfolio management

There is an established literature on IT portfolio management. I am particularly interested in how this works in an Agile environment, but before I can start to examine that aspect, it is valuable to review what I mean by IT portfolio management generally.

What is IT Porfolio management

Portfolio management is a way of looking at our IT assets not as individual assets but holistically. This is valuable because it lets us balance costs, risks and investments as a whole – enabling us to set strategic objectives for, as an example, what we consider to be an acceptable balance between potential benefits and risks and what our target rate of return is on the investment overall. Having decided on those strategic parameters it is the job of portfolio management to ensure that the investments we make in IT viewed as a whole meet those objectives.

Therefore the portfolio management function has a different perspective from the strategic planning function or the project/ programme management function.

portfolio priorities

What does the IT Portfolio consist of

When IT portfolio management first became prevalent in the 1990s it focussed on project management – the investments it was concerned with were primarily development. As the technique has matured, it has expanded to include the whole of IT investment

  • Applications (existing applications)
  • Infrastructure (both software and hardware)
  • Projects and programmes.
  • Thus the scope of portfolio management has increased dramatically to reflect better the assets managed by the IT function. With that in mind, simply listing those assets becomes a) a large undertaking, and b) valuable in itself.

    Having done so however we can categorise investments by their value and potential value to the business. In my experience a major part of IT investment is concerned with “keeping the lights on”, in other words keeping the existing IT facility running. So, a large part of our investment is maintenance – mostly BAU, sometimes more strategic changes to infrastructure.

    Resource allocation

    We therefore might categorise our portfolio in this way, enabling us to have a first cut at investment priority based upon our appetite for risk and the amount we might consider reasonable to spend in each area based upon previous experience.

    portfolio asset classes

    Project prioritisation

    Next we look at the projects we are funding, after all these are the discretionary investments we are making so it makes sense to see what value we are getting and what risk we are incurring.

    We can look at each of these separately and then make our prioritisation based upon the value we place upon IT as a strategic tool:

    portfolio boston square value

    Or take a more risk based view:


    Performance tracking

    The final process is to track performance to ensure that the portfolio is delivering the benefits we planned. The nature of portfolio management changes here, from strategic planning to project tracking.

    portfoio tracking

    This is where the feedback loop occurs and where events and changes in the environment or in our plans update the portfolio. The objective is to ensure that although projects change, are put on hold, or are started, the overall portfolio continues to reflect our business strategy.

    Agile portfolio management

    So that is (very quickly) IT portfolio management. Interestingly portfolio management has up to now focussed very much on waterfall projects because of the top down focus inevitable in strategic planning.

    What I am interested in is how that works in an Agile environment. In my next post I shall address that specifically.

    Project based rightshoring

    For over twenty years offshoring has been a major part of many UK companies delivery strategy. As you would expect, the industry has matured in that time and has fragmented in to a number of specialised forms

  • Offshoring
  • Nearshoring
  • Rightshoring.
  • In my time at O2 we evolved a fairly sophisticated model for partner offshoring and, while it may not be appropriate for everyone, I feel it would be useful to describe how it worked for us.

    First, though, lets define the three key approaches.


    Wikipedia defines offshoring as

    the relocation by a company of a business process from one country to another—typically an operational process, such as manufacturing, or supporting processes, such as accounting. … More recently, offshoring has been associated primarily with the sourcing of technical and administrative services supporting domestic and global operations from outside the home country, by means of internal (captive) or external (outsourcing) delivery models.

    For our purposes we are interested in a subset of that concerned with IT development and maintenance. I would also say that offshoring for our purposes involves moving business processes to a country in another continent – typically India, but increasingly China, Philippines, Malaysia and latterly countries in Africa.


    Back to Wikipedia and we have nearshoring as

    the transfer of business or IT processes to companies in a nearby country, often sharing a border with your own country.

    Again, lets be a little more specific than nearby, and restrict it to a country in the same continent. Nearshoring for the UK therefore typically means moving business processes to the Eastern Bloc.


    Wordspy defines rightshoring as

    Restructuring a company’s workforce to find the optimum mix of jobs performed locally and jobs moved to foreign countries.

    In other words rightshoring means moving some, but not all, business processes offshore (or nearshore) depending on the business process.

    So having defined our terms, what are the advantages and disadvantages of them?

    On the positive side we have

    Cost: Cutting cost and taxes is the main reason behind companies embracing offshoring.
    Time Zone Advantage: Offshoring gives companies the advantage of exploiting the time zone by receiving round the clock benefits.

    Of course it’s not all upside. Problems include

    Differences in work practices and culture. A huge difference always remains in the work practice and culture which are hard to overcome
    Communication Barriers: It is often difficult to communicate with companies in other countries that speak a different native language. Face to face meetings are very expensive to conduct and video conferencing may not always be convenient due to time difference.
    Finding good offshore partners: It can be hard to find a good IT provider based on the reviews on their websites and few teleconferences. It is not easy to make a good judgment without proven track record of working for other international companies and authentic references.

    You can see that rightshoring is an attempt to get an ideal mix of cost and flexibility at the organisational unit level. The problem is that in terms of delivery we want to make that tradeoff at the project level. We don’t want to decide where all projects will be developed and then be stuck with that decision – we want to make it on a per project basis and ideally be able to change it if our needs change halfway through.

    Essentially that is what we did at O2.

    Project based rightsourcing

    We had a team based in UK and another, larger, one based in India. At the initiation stage of a project we would produce a high level estimate based on Agile story points. We also asked the business owners to give us a simple view of the urgency based on H/M/L. All of the H priority projects were developed completely in UK using Scrum. The default for M projects was for an initial detailed impact assessment and design to be carried out in UK and the build to be carried out in India. All L projects were carried out in India completely using a waterfall approach (as it happened they also had a daily standup but it was really just to review progress against the plan).

    Of course to do this we had to put in place a number of processes to make it work. The key ones were:

  • A BA team in UK, a core development team in UK (small) and a core development team in India with a shadow team in India whose role was to work with developers in India and become familiar with the UK projects and infrastructure. The shadow team was typically in training
  • Where possible we shared work between the two core teams, every UK team had at least one India team member attending the standups and working as a productive part of the team
  • Bi-weekly planning meetings looking 6 weeks ahead. All H priority projects were done in UK, but the rest depended on available resource. We tried to balance resource between UK and India while meeting our SLAs for planned work
  • If that could not be done we would move one or more teams from the core group between UK and India as required, then replace them with members of the shadow team
  • An administration group tasked with organising visas and accommodation.
  • The nett result was that we were able to develop systems either on or offshore based on the trade-off between cost and delivery time. The amount of each varied – that was the point, after all – but we found it worked within the below parameters.

    team size

    There were some caveats – you need a certain amount of work in the UK as mentioned – but in general it worked for us.

    Some consider it noble to have a method; others consider it noble not to have a method. Not to have a method is bad; to stop entirely at method is worse still. 

One should at first observe rules severely, then change them in an intelligent way. The aim of possessing method is to seem finally as if one had no method.

    Chieh Tzu Yuan Hua Chuan
    The Mustard Seed Garden Manual of Painting (Qing Dynasty)