StratNavApp.com banner ad
Showing posts with label project management. Show all posts
Showing posts with label project management. Show all posts

Big business appears to favour big change

Big business appears to favour big change - that is, big initiatives, organising lots of people with large budgets, culminating in big announcements. I think that this is partly because bigger initiatives with bigger budgets look better on CVs.

But smaller incremental changes may produce better results:
  1. They start to earn a return sooner.
  2. The get customer feedback sooner - allowing you to change, speed up, slow down or even abandon programmes of change.
  3. They needs less, if any, financing.
  4. They are easier to project manage.
  5. They allow you to try more alternatives, abandoning directions that don't seem promising and continuing with those that deliver results.
Success can then be measured in terms of outcomes, not initiatives - in terms of measures like customer acquisition, satisfaction and retention rates, operational efficiency, costs and revenues, rather than in terms of projects delivered (whether or not they delivered any actual benefits).

I think it is time big business started seeing change as a continuous process, an element of culture, rather than a series of events. Almost any project can be broken up into a series of smaller changes. As a rule of thumb, I believe that, projects should be broken up into the smallest separately deliverable changes possible.

Resource allocation: in series or in parallel?

I remember being taught in undergrad finance that the enterprise "can always find enough resource to pursue all opportunities whose return exceeds the risk adjusted cost of capital" (or words to that effect).   A fine theory. But every organisation I've ever worked in always seemed to be short of resources somewhere.

So, scarce resources need to be allocated.

Should you fully resource you highest priority project, then the next, then the next (i.e. in series)? Or should you spread your resource amongst all of the projects (i.e. in parallel)?

This can be visualised as shown below.   In the top half of the diagram we see resources allocated in series - only once Priority 1 has all of the resources it needs, do resources overflow into priority 2.   In this case, priority 4 gets nothing.   In the bottom half of the diagram we see resources allocated in parallel based on the weighting, or relative importance of each of the projects.   (In practice, of course, the buckets would also be of different sizes.)
Most organisations I have encountered have a tendency to resource projects in parralel.   Everyone gets a little resource to appease their demands.   It's a political thing as much as anything else.

But there are three good reasons why it's better to allocate resources to projects in series:
  1. From a practical perspective, it makes sense to allocate resources in series.   It's better to have one project properly resourced and with a chance of success, than it is to have two projects inadequately resourced and with less chance of success.
  2. In a pure financial sense, it also makes more sense to resource projects in series.   Consider these respective NPV calculations (discounted at 15%) where project A and project B both cost £200 and have a payoff of £300.
  3. In seriesNPVYear 1Year 2Year 3Year 4Year 5
    Project A34.68-100-10030000
    Project B26.2300-100-100300
    TOTAL60.91

    In parallelNPVYear 1Year 2Year 3Year 4Year 5
    Project A6.40-50-50-50-50300
    Project B6.40-50-50-50-50300
    TOTAL12.80

    The NPV from funding the projects in series is clearly higher.   Not to mention the additional option value of being able to decide not to start Project B at all at the later date.

  4. It's better for morale - when the first prject finishes, it will give people a morale boost which will carry forward to the later project.

That's not to say you'll never run projects in paralel, just that you should apply all of the resources project A can usefully use before you look at what is available for project B.

For example, not all resources are created equal, and those not suitable to project A might be usefully applied to project B before project A completes. (Consider for example a Marketing intensive project A with few IT implications and an IT intensive project B with few marketing implications.)

So, in practice, whilst there will always be some parallelism in projects, serial resource allocation should be you starting point.

Project management lessons from investment management

In ROI: Risk of Ignoring, I started to explore investment management as a metaphor for strategic project management. Here are some more lessons from investment management:
  • Risk / Reward: it follows, I think, that the projects with the greatest potential risk for failure carry the greatest potential rewards (all other things being equal). In traditional finance theory, advisors establish the risk tolerance of a client. Organisations too have a project risk tolerance. Conservative companies are just not that good a high risk projects - which goes a long way to explaining the relatively low levels of innovation (historically) in the financial services sector compared to the dot com sector, as well as the re-invention of big pharma.
  • Diversification: particularly at the higher risk end of the spectrum diversification pays - that is running a portfolio of projects whose failure points are not correlated dramatically increases the chances of success. In organisational terms, that means not focussing all of your innovation and investment in one division or area of the business at the expense of the rest. It also warns those business who pin their hopes on a single transformative initiative. (On the other hand, people can only deal with so much change at a time, so that needs to be managed too.)
  • Profit Taking: with investments, it makes sense to sell investments once you've made a respectable profit, rather than hanging on for the investment to peak, thereby leaving something on the table for the next investor. Similarly, it make sense to get you products out there before they have every last feature implemented. It's better to get something out there than it is to wait until the market turns and someone else has mopped up your target market.
  • Liquidity: investments that are easy to monetise are more attractive than those that are not. Look for project structures that are easy to disaggregate into pieces that are easily repurposed or multi-purposed. Look for early wins that impact the bottom line. This is why Agile methods have become so popular.

Project Stakeholders have conflicting agendas

One of the biggest challenges in project management is managing stakeholder conflict. Even at the most basic level, different stakeholders have different relationships to the project.
  • Team members - typically work on a single project for a long period of time. As a result their personal identity becomes wrapped up in the project. They lose objectivity and may try to keep the project going long after it makes sense to give up.
  • Users - often see the project as unwanted interference - a change to be resisted. And if they carry the domain knowledge, they are uniquely positioned to consciously or unconsciously undermine it. (Although increasingly, it seems, projects have customers rather than users.)
  • Sponsors - are more likely to see the project as one of many potential investments they currently have on the go.   Their perspective is almost completely the opposite of the team members, as they have to consider how much resource they give them and whether or not it's time to pull the plug.
A successful project manager understands these conflicting agenda and is able to keep them in balance.

ROI: Risk of Ignoring

I've been grappling lately with the tradeoff between time to market and political expediency.   In a nutshell, time to market can be described as a continuum between rapid prototyping and agile development methods on the one hand, and traditional business development waterfall methods on the other.   The traditional methods focus on identifying and understanding as many variables as you can before you launch to market - a think before you act approach.     In contrast, the rapid prototping agile methods favour an act before (or rather while) you think approach - basically launching with an educated guess and and refining your proposition depending on the response it receives.

The best method for any given situation will most likely fall somewhere between these two extremes.

And finding exactly where the right method for your project falls will involve some assessment of the political risks, as determined by the sponsoring organisation's culture.   A more traditional bureaucratic culture will favour a more traditional business development waterfall methodology and will shun the risk associated with a agile method.   Similarly, a more entrepreneurial culture will favour a faster time to market and will be more comfortable with the level of uncertainty and risk involved.

This trade off between time to market (return) and political risk (risk) reminds me of the tradeoff between risk and return in investment theory.   And so I wonder if there is some sort of efficient frontier that you can calculate for projects and project portfolios.   If the analogy holds, then the trade off is not equal across the range (that is, there is a curve in the line on the graph to the right), and there is some theoretical attitude to risk which can be used to determine the sponsoring organisation's optimum risk / method tradeoff.   An understanding of that, even at a conceptual level, should help a project manager pitch his/her project correctly for the organisational culture in which he/she must operate.

Get it wrong, and you run a different risk - the risk of squandering the window of opportunity for your proposition.   That is, if you do not pursue the most aggressive method that the sponsoring organisation's attitude to risk will tolerate, you risk coming to market later than is absolutely necessary, and possibly missing the window of opportunity altogether.

For that reason, some organisations - those with bureaucratic cultures and low tolerance for risk - will never be able to deliver quickly enough to take advantage of opportunities in rapidly developing markets with opportunity windows that close quickly.   And so sponsoring organisations need to target markets which are amenable to their appetite for risk.