Blog posts

change management, freelancing, interim management, project management

What is the difference between interim and freelance project management?

Interim management is a temporary injection of skills into an organisation.

The Interim will typically work from within the organisation to manage a transition, change or crisis. Because organisations do not need these skills at all times, interim management tends to fall outside IR35. Some interim roles lend themselves to fixed price contracts with payments for achieving pre-defined milestones, goals and benefits.

Freelancers take on specific tasks, most often for a fixed price. The boundaries of the task are clearer and the employment is almost certainly outside IR35.

In my discipline – project management – an interim would enter an organisation that has need of a project but does not need the skills of a project manager on a permanent or fixed term basis. They are likely to spend most of their time within the organisation but will keep a distance so they can be most useful in terms of providing a ‘fresh pair of eyes’. Interim contracts generally last between three and nine months.

On the other hand, many freelancers stand apart from the organisation. They might define a project from business case to schedule, coaching and guiding the delivery manager along the way. They are much more likely to pop in and out of the business and might be able to handle several clients at once. A freelance activity might last an hour or hundreds of hours over several months.

To be honest, the difference is more audience related, I find that larger companies prefer interim and many SME are comfortable with freelance. Both are synonymous with self-employment and contractor.

View over the flood plain

About Delta Swan

I am setting up a website for my limited company and will be removing content from this site. My company is Delta Swan Limited and this post explains the name.

The name Delta Swan comes from the view from our study window. On reflection, I realised I had chosen two symbols of change for my brand. My choice may have been unconscious, but it is entirely appropriate. In mathematics, delta means the difference between, but in the natural world, a Delta is a region that regularly floods and is constantly replenished by those flood waters. The Okavango Delta is celebrated for the wildlife it nurtures in the middle of the arid landscape of Northern Botswana.

Water lilies in the Okavango Delta
Water lilies in the Okavango Delta By diego_cue, CC BY-SA 3.0,

My style of project and change management is about refreshment, most of all making sure that change delivers a positive outcome for everyone involved.

The other symbol is the swan. Our local flood waters are less dramatic than those of the Okavango but they draw in lots of birds. We see many types of duck and have three regular flocks of geese. But my favourite visitors are the swans.

A family of swans
A family of swans prove the adage about ugly ducklings.

These graceful animals show the value in persevering and accepting a little disadvantage early on for a great outcome later in life. If you want to hum the song, this is the right time.









So, I unintentionally chose two images that represent change. I think that sums up my approach to life and business.

change management, interim management, learning, programme management, project management

Doing something badly doesn’t make it a bad thing

In last week’s post, I said I was a fan of PMOs ‘in principle’. By that, I meant I have seen PMOs that haven’t worked well for the organisation or the Project Managers. And I was falling into the trap of conflating idea and implementation. To repeat a phrase I have used before: ‘Doing something badly doesn’t make it a bad thing’. In other words, my experience of some PMOs doesn’t make the concept of a PMO wrong.

Have you ever been in the situation where a cohort of people actively pushes back on a solution to a problem? Obviously, it could be a poor solution, but sometimes the team is not reacting to the idea but to their experience of a previous application of the idea or similar idea.

That is not to bad mouth our predecessors. On many occasions, innovation fails when we don’t have the right resources around us, be that a good sponsor, an honest teammate or technology that matches our aspiration. Sometimes command and control organisations have sought to impose change, rather than engage with their teams to build a good outcome.

Whatever the reason for the earlier failure, helping this once bitten – twice shy team embrace change will need a bit of effort to understand what went wrong last time.

It didn’t work last time – how root cause analysis can save the day

Applying a bit of analysis to the previous situation will yield valuable lessons learnt. Just remember they may not be directly related to the solution. You can improve your probability of success with better communications and fuller requirements capture (and if you put something out of scope, addressing the impact of that decision – see No mop-ups in here), and by respecting all your stakeholders.

So next time you hear that dread phrase ‘didn’t work last time’, often accompanied with a slow shake of the head to signify ‘they will never learn’. Don’t be rude. Listen and resolve the issue (not perception) at the bottom of that pit of despair.

I hope you have enjoyed these posts and have had some food for thought. I am an interim and freelance project manager and would love to talk to you about planning for success.

Hm - is it a project or a programme?
change management, interim management, programme management, project management

How to work out if you have a project or a programme

Both projects and programmes introduce change to improve something. Neither delivers the organisation’s mission, that is they do not directly serve customers or produce something that can be sold.
Generally, people accept that there is a difference between project and programme.

On a separate, etymological note, project comes from the Latin word for “throw forth” and came into use in English in the 15th century. Programme comes from both Late Latin and Greek. It entered the vocabulary meaning “a definite plan or scheme” in the early 19th century. On this basis programmes are clearly ‘new-fangled nonsense’.

However, the nature of that difference is not commonly agreed and sometimes results in conflicting job titles, descriptions and expectations.

Size is not a good indicator and some people incorrectly describe ‘big projects’ as programmes. While size, particularly duration, is a factor in defining the nature of a body of work, there are many, more significant differences. Rather than present every nuanced example, here are three ways of telling apart projects and programmes.

  1. Programmes can be open end – projects are always bounded.
    If we consider the London 2012 Olympics, each construction site ran at least one project. Those projects ended with hand over to the games organisers. The games were also a project with a clear public end at the closing ceremony and, probably, several other ends as athletes and officials went home, and the venues passed into new ownership. On the other hand, the Legacy was a programme. It doesn’t have a defined end state, although it was time bound. The legacy programme set up, launch and oversaw many projects.
  2. Projects have solid relatively clear outcomes; programmes have aspirational goals.
    Back to the Olympics. The individual projects whether a building or the actual games are pretty much understood. Stop for a moment and consider the goals of the Legacy. They fell into four broad camps: economic, sporting, social and volunteering, and regeneration. These goals are relatively ambiguous; they are hard to describe. But all the projects (eg fund elite sport, invest £1bn in the Youth Sport Strategy) are all fairly easily bound.
  3. Project stakeholders tend to agree about the outcome, whereas programme stakeholders are likely to have very different perspectives on life.
    Sure, squabbling stakeholders beset some projects (caused by bad project definition and buy off) and some programmes boards are suspiciously conciliatory. However, because programmes are unbound and have aspirational goals, stakeholders see both the end goal and the means of achieving it from their own perspective. And many differing perspectives often result in disagreements. The art of programme management is untangling these differences and getting agreement to a set of goals that will benefit the organisation and that the programme can achieve.

You now work out whether you have a project or a programme;

So, what?

Can it be that managing projects is all that different to managing programmes? Oh yes. The Programme Manager has to build consensus from chaos, provide clarity from ambiguity and maintain cohesion when project forces threaten to pull the programme apart. By this definition, the Programme Manager is a necessarily a different beast to many Project Managers. And many would argue a Programme Manager has a responsibility to Project Managers, perhaps as a leader, certainly by setting standards and providing a toolkit.

You might ask, ‘where is the ambiguity between project and programme?’. I feel a misuse of the name Programme Manager comes from the term PMO. When it means Programme Management Office, we start to see people called Programme Manager who collate data, report progress and administrate the risk process; among myriad other tasks. Their role is important and centralising the activity to support multiple projects and programmes can improve quality and efficiency (so I am a fan in principle). But the staff of the PMO are not Programme Managers. I heard them called Programme Officers, Project Controllers, Project or Programme Support staff and Project Administrators. Does it matter? Does a rose by any other name smell as sweet? Well, Juliet thought so of her Romeo and providing we have a common understanding it probably doesn’t really matter. However, if the Programme Manager is challenging methods and bringing fresh insight, while the stakeholders expect nothing more than regular reporting, then the individuals involved are in for a bumpy ride.

Next time: Doing something badly, doesn’t make it a bad thing

photo credit: sam.naylor Pensive via photopin (license)

Mountain Climber
business analysis, change management, data analysis, interim management, programme management, project management, quality

The surprising toolkit of the pioneering Project Manager

I always smile when learning about a new project framework or tool. At some point, the purveyor of the method is bound to mention that this technique is different because of the soft skills of the project manager. Be that listening, relationship building or conflict resolution.

For example, in the last post we looked at the mechanics of defining (envisioning in Agile) a project. However, the practitioners of any framework will tell you that the key to a good definition is to include the whole team. And by team, they mean customers, sponsor, users and any other relevant stakeholder (for instance, in a compliance project you will include the Quality Manager or subject matter expert for the standard or regulation you are following). Moreover, they won’t leave it there.

Each framework encourages project managers (PMs) to use all the soft skills mentioned so far in this post. They tell us that the modern-day PM has moved on from command and control to coaching and facilitating and I welcome that change. The pioneering Project Manager builds skills across three areas: modern project management, change management and business analysis.

We have to be comfortable with the mechanical skills of project management. Indeed, we need to work quickly and efficiently in this arena because we are also team coach. We work with our team to support individuals and help them deliver. We do not do the job for them or make technical decisions; we help our team so team members can apply their expertise to the project. We create an open environment where each team member can express their opinion and concerns. We negotiate with the sponsor and key stakeholders, making sure they understand what they are buying into and the impact of changes on cost and timings.

As a change manager, we think about the end customer of our project. We make sure they are ready to change; we resolve their concerns; we act as their advocates within the project team. If we are launching a new product or service, we bring the voice of the customer into our requirements, reviews and decision-making.

Wearing a Business Analyst hat, we find and provide the information to make data-driven decisions. We present progress in a way that is meaningful. We can build a business case and realise benefits. We structure requirements to make them congruent and complete.

Why pioneering? At times our stakeholders are impatient with good preparation (I was once told to “get on with the f’ing project”, which the board later cancelled because the preparation work showed it was ill-conceived). Standing up against this pressure is hard, particularly when recruiting managers seek a Project Manager to produce a Gantt chart and nothing more. There will always be an important place for a schedule and risk register in projects, but I hope that soon we will see the end of the belief that the key skills of a PM are the ability to work a scheduling tool and spreadsheet.

Next time: how to work out if you have a project or a programme

Spotlight image from pablo
business analysis, change management, data analysis, excel, interim management, management, programme management, project management

A Spotlight On When Expertise Makes Things Harder

I am a fairly advanced Excel user. For example, just this morning I created a lovely workbook so that one of the volunteers at Nottingham Industrial Museum can enter the time given by all volunteers and produce a simple report for our licencee (no, we don’t sell alcohol, but the charity operates under licence from Nottingham City Council – NCC). In this case, my objective was to save time for the volunteer and get the numbers needed for NCC. I felt this was easier done by hand (oh! sacrilege), but she wanted to stick to Excel as she also needs a total per volunteer, wants a quick way of seeing when a volunteer stops giving their time and isn’t comfortable with arithmetic. So, with a heavy heart, I set up a data entry table, a couple of pivot tables and a look-up table. We now have a very easy to use spreadsheet, that does all the hard work by automagic.

The opposite happened when I was looking for a host for my new website – it is time to move on from for my professional activities.

I started by working out what is important to me – in no particular order I came to: a customisable spam filter, WordPress compatible, servers in the UK, provides backups (that can be restored by individuals), subdomains, decent storage, unlimited bandwidth, price and provision of a domain. Given that I identified eleven potential hosts, this was a job crying out for a matrix and what better way to create a matrix than…a piece of scrap paper, a ruler and a pen. What no Excel, you might cry. My other half certainly did when I presented my decision to him later that day.

Decision matrix
Sometimes old school is just better

So why was this better?

  • The first thing that sticks out is that the technology didn’t get in the way of the task. In Excel I would have been tempted to make it a table and learn more about that functionality. I would have had to find a good way of indicating Yes or No and I would have spent time on the layout. In other words, using a piece of paper gave me  space to concentrate on the task in- hand.
  • The second thing is that I had a gazillion tabs open as none of these providers put all the information on one ‘page’. As several choose not to list it at all, I was also engaging in live chats and discussing options by email. Another window, even if it were the safe harbour of Excel, would have been another plate to spin.
  • The third thing is that little note to myself at the bottom of the page. I always have paper and pen to hand to make notes like this – otherwise, I forget. Excel would let me make the note, but would I ever see it again? I certainly don’t go through workbooks looking for notes, whereas a piece of paper right next to my keyboard gets my attention every time.
  • Finally, the sheer handiness. Notice how Freeola was added at the end? I am working with a brilliant web developer and they are his host of choice, so I added them after I started the task. I didn’t have to fire up Excel to do this, I grabbed a pen and added Freeola when I was doing something else entirely.

So that is my story for today. What is the takeaway? Pick the right tool for the job, remembering that the fanciest, most interesting tool may not be the best.

Project Framework
interim management, programme management, project management

Project frameworks – the secret of your success

In my last post, I gave a list of transformation project success factors. It wasn’t a comprehensive list of project management tools, nor did it advocate a specific project framework.

Whether you are well versed in Agile, Prince 2 or the APM Body of Knowledge, you will have recognised the elements. Let’s take the project definition, called a business case in “No mop-ups in here – why planning to mop-up compromises your transformation”, and see how each of the frameworks creates its project definition:

Agile Prince 2 APM
Uses the Charter and Product Data Sheet Uses the Project Initiation Document (PID) Uses the Business Case

  • Purpose
  • Benefits
  • Scope
  • Objectives
  • Deliverables (features)
  • Stakeholders
  • Issues
  • Risks

  • Purpose
  • Costs
  • Benefits
  • Financial analysis
  • Scope
  • Objectives
  • Deliverables
  • Stakeholders
  • Accountabilities
  • Timeframe
  • Project methodology
  • Risks, issues and constraints

  • Purpose
  • Costs
  • Benefits
  • Financial analysis
  • Scope
  • Objectives
  • Deliverables
  • Stakeholders
  • Accountabilities
  • Timeframe
  • Project methodology
  • Risks, issues and constraints

Agile has less content at this stage, mainly because the Speculate stage of the first sprint will work out the timeframes and costs for the overall project.

In all honesty, is there that much difference between the frameworks? I would suggest not. Furthermore, a good project manager picks up and uses techniques from each as she works with other PMs or in new organisations. These techniques form a toolkit to be drawn upon as required – not by rote.

Most Project Managers won’t get to choose the framework they use. Most organisations have encompassed a methodology and made it their own. Pulling together the continuing professional development of a good PM with the need to pick up and run with organisational project processes, we can see that a key attribute of a Project Manager is the ability to adapt to the circumstances of the project.

However, a project framework is no more than a check-list – it’s the way you approach your project that counts.

Next time: The surprising toolkit of the pioneering Project Manager.

No mop-ups
cost of quality, data analysis, efficiency, interim management, programme management, project management, quality

No mop-ups in here – why planning to mop-up compromises your transformation

Do you drive to the supermarket with the assumption that it is okay not to buy, let’s say, 20% of the items on your shopping list? Alternatively, perhaps you prepare Sunday lunch and feel happy leaving out one or two items? You might even get ready for a holiday willing to take only half the clothes you need and put enough petrol in the car to get you 80% of the way to your destination.

You don’t do that? Then why do you accept it in an IT project? Building in a mop-up ensures:

  • A decrease in benefits
  • Overspend
  • Quality issues

Loss of benefits is easy to understand. Miss out some people and not only do you lose their productivity gains, but you commit to legacy hardware and unsupported software. Even more costly is missing out a group of people who are key to a business activity. At best new workarounds are required – at worst they may lose the ability to work with their colleagues. [for example, I once worked in a team left behind in a Windows/ Office update. We could open no attachments sent by migrated colleagues]

As we consider overspend, we have to be honest with ourselves. The original project budget will be spent on the lucky teams included in the scope. Anyone demoted to a mop-up phase will be the subject of another round of spending. The organisation then has the unpalatable choice of leaving a team behind or spending more money. And if you take the former route, the cost of running old systems grows. So you are going to be spending that extra money anyway. [for example, I have seen the decision to roll out geographically have a domino event on the upgrade of a system. Eventually leading to dual identities so that a group of people could work on multiple sites]

Quality issues are the most controversial of these claims. The mentality of ‘fix it later’ is contagious and I contend that a project team that is willing to descope, grows willing to ignore risks and issues. [for example, I mopped up after a project that used a tool to support readiness activities. But the tool didn’t work, rather than fix the tool the first team allowed people to opt out of the project. Many of those who opted out had no need for the tool, but the project team let it ride.]

So, if mop-ups are so bad, why are they common practice? I am afraid this is going to sound cynical:

The IT service industry depends on repeat work and mop-ups are the most lucrative of all activities

Because we accept mop-ups, we accept poor planning and we descope when the work is too hard

Organisations selecting service providers on cost drive the scope down to an assumed core set of activities

“It’s so bad that maybe the government should give up the ghost on trying to do anything and simply accept that multibillion [dollar] failures are a permanent part of the landscape,” said analyst Michael Krigsman, CEO of consulting firm Asuret and an expert on IT project failures – Computer World December 2012

The solution. Start right and be honest; every short cut taken will come back to haunt you (or the poor soul asked to recover the project)

Your business case must set out expectations explicitly. Including the systems to be decommissioned, the people included and the acceptable level of acceptable business disruption. Developing the business case will help you decide if you really can afford to leave part of the organisation behind.

Audit the environment against your assumed ‘standard’. Uncover and document the variations. Understand where all your people are and how they work – are they mobile workers, are they customer facing, do they have project deadlines? Understand the times of the week, month and year that can brook no disruption. Get to grips with the IT literacy of the target population.

Build project governance across IT, the organisation and third-party resources. Foster open, robust risk and issue management. Set up approval processes for the process and plans, and agree go/ no-go criteria. Make sure the responsibilities and purpose for data capture, recording, analysis and reporting are clear. Set data led performance targets.

Apply best practice to the project – you need good people, strong processes and robust data. Agree the Quality up front and ensure compliance.

Learn lessons. Use pilots for customer acceptance and to test your processes. Assess each activity and build improvements into the process.

This list holds no surprises, except the fact that very few projects do all this, let alone do it well. There is one more factor to consider – how well the IT project works with the business.

If your IT team seems to see the organisation as a necessary evil, something that has to happen so that IT exists, you are not going to do well. On the other hand, if your IT team builds relationships with the organisation, listens and responds, you have the potential for success. During every IT project, capitalise on this relationship, ensure contact at every level of the project, from steering group to specialists and their customers, and keep the relationship alive.

If you can do all this, my son, then you will avoid the phrase ‘let’s plan the mop-up’.

Next time: Project frameworks – the secret of your success

cost of quality, data analysis, efficiency, interim management, programme management, project management, quality

Unlock the potential of your transformation programme with simple fixes

Why do so many organisations go through initiatives to make many small changes and then give up? Well, the fact they are initiatives, not a way of life, doesn’t help, neither does a lack of money or time. And frankly, who truly believes we can transform the sales order process (to name but one) with a number of small measures?

So, we muddle along, and then we transform. But that doesn’t work either. Transformation projects run late, they design in exceptions, they plan mop-ups, and the benefits just don’t materialise. Transforming a process that is inefficient or produces poor quality is like sowing grass seed without first pulling up weeds.

The inefficiencies of the old process are mixed up with value added activities; people will resist change that doesn’t recognise and addresses poor working practices. [for example, if the current system produces a report that someone then has to hack about – don’t duplicate the report]

The inefficiencies of the old process throw up risks and issues that shouldn’t exist, ignoring these obstacles always bites the transformation team in the tenders. [for example, the dispatch team must keep the obsolete printer in the corner because they use perforated paper for shipping documents, so it has to be network connected]

Working from a helicopter, the 30,000-foot view, rides roughshod over the hidden requirements of a process, which may be undocumented or fail to reflect written processes. [for example, an Excel macro that converts data to meet a specific, out of process, contractual customer requirement]

Transform often means automation, and anything computer driven is unforgiving of variation. Every discrepancy found during the design phase adds to the pile of change requests. [search on-line for ‘IT project horror stories’ and pick your own favourite example]

Ideally, before a pure transformation project starts, we have:

  • Established consistency – everyone does it the same way, every time
  • Built in efficiency – waste is removed, be that a report no-one reads or reducing rework
  • Used data to set goals for the transformation project

But so few organisations work this way, so do we have to delay a project to sort out and measure the existing process? No, while establishing a solid process baseline goes a long way to guaranteeing the success of a transformation project, you would be spending money on something you plan to throw away. I would suggest that we must approach transformation in a different way. We need to drop the belief that 80% is good enough and set up (don’t roll your eyes, you do it quickly and cost effectively if you set out with the right intentions):

A transformation process that takes the time to listen and to understand what actually happens in an organisation and why.

A system design team that works with the organisation to turn this understanding into requirements (including an agreed operating process: inputs, output and action) and communications.

An implementation team that tests the new system with real people, be it a pilot or a sandpit, and incorporates lessons back into the system design/ roll out plan.

A resolution team that puts the organisation first, analyses issues and feeds back into the design of the system or implementation.

It takes a lot of guts to do a project this way, it starts slowly and deals with detail. It is so much more exciting to take the approach of the hare. Dive in, firefight our way to the end and then let someone else plan the remediation programme. However, the hare can be overtaken and so can transformation projects that target inefficient activities without a sound change methodology.

Next time – why planning to mop-up compromises your transformation

Proof we keep toast bread in the freezer
efficiency, interim management, programme management, project management

How to achieve good quality – Life Hacks

I just made toast. Not to brag, but we always have bread for toast because I learned a Life Hack from a friend of my mum’s (after a boozy night out, which goes to show that life lessons can come at any time). We keep a loaf of thick sliced bread in the freezer. So we always have toast bread and have developed the ability to pry apart frozen slices of bread with our bare hands.

I love Life Hacks, me; this is the new ‘cool kids’ term for the hints and tips you find in magazines. Apparently, calling them Life Hacks give them a modern era vibe.

But, do Life Hacks have a place in the workplace? They surely do. No-one likes having me watch them using Excel. Confession, I get a little frustrated when the simplest job becomes a labour of love (especially when accompanied by the attitude that I am too important or too normal to use Excel). I also stop the flow of jobs to ask ‘what did you just do?’. People who are not geekish about Excel (or Life Hacks) normally look bewildered at this point and tentatively repeat a key stroke or obtuse set of mouse clicks. And I beam with delight as I learn something new that could shave precious minutes off an Excel emergency.

I realise that I have only sold the idea of Life Hacks, or as I like to call them small, productivity gains, to a few die hard process enthusiasts and a bunch of Excel geeks. Should Life Hacks have a place in the heart of normal people? (Don’t be offended, I proudly subscribe to both of the aforementioned ‘abnormal’ categories.)


  • The first recorded success of applying many small changes came in the 19th century and is called the Steinitz Accumulation Theory because it kept Steinitz (its inventor) World Chess Champion for 20 years.
  • The rules of Formula Once force incremental improvements, which has led to amazing technological advances.
  • The German football team, considered by many to be the best national side ever, employed 40 sports scientists to find and implement every conceivable advantage.
  • In business, a key flank of the Toyota Production System empowered all employees to create continuous improvement.
  • Google runs thousands of experiments every year to hunt out small opportunities, like lightening the colour of the Google Toolbar.

However, while suggesting we would benefit from spending more time looking for performance improvement, these examples also propose a rigorous regime that isn’t appealing and has the potential to become a business fad we all remember fondly in years to come.

It is a dreadfully prescriptive science, reducing all the spontaneity of life to a matter of routine. Oliver Brown, Chief Sports Feature Writer, Daily Telegraph (2 March 2017)

However, I would like to suggest that embracing Life Hacks is simply a choice. Once you decide it is cool to work out efficient ways of working, once you take pleasure in being knowledgeable, once you start to share your Life Hacks with a bit of pride, you will need no complex system. No guru will be able to tempt you to exchange your hard-earned cash for a five-point plan, and you will have less frustration in your day.

Next time – Unlock the potential of your transformation programme with simple fixes