Posts

Defining the difference between a Project & Business as Usual

At Hart Square, we have the great pleasure of working with our clients across the non-profit sector to deliver transformative technology projects that will support and enhance the experiences for members, fundraisers, and beneficiaries. However, it’s important that before our clients embark on a piece of work, they understand the difference between a project and business as usual (BAU). I will set out here the key differences and how to approach both to ensure successful delivery.

When is a piece of work a project?

Defining when a piece of work is a project is a critical element for any organisation to consider. The two key questions to ask are:

  1. Is the piece of work temporary with a clear endpoint?
  2. Is it delivering a unique product with a defined purpose?

A defining characteristic of a project is that it’s a temporary structure with a defined start and end date, so a project will be specifically initiated, then once the activities have been delivered, the project has been completed and will be closed. If there is no defined go-live or end date, then it’s likely this is business as usual activity or process. An example of this would be membership renewals that take place throughout each year where a series of regular processes would occur.

Aligned with this, the second key question is whether the work is delivering a unique product with a defined purpose. A project aims to produce deliverables that address a problem or need that has been identified before it starts. A good example of this is a new CRM or website which would be looking to increase the fundraising income and profile of the charity.

There are several other characteristics that are important to define a project but the above are two things that really stand a project apart from BAU.

Defining Business As Usual

BAU can typically be defined as a standard day to day business operation that ensures continuity within the organisation. This would include a range of activities such as monthly reporting, IT helpdesk or supporter services. These functions operate through a day-day activity, throughout the year, often repeating the tasks and are not time-bound or have a specific capital budget associated with the work.

The cross-over of resources

Finally, there is one area of cross-over to consider and that is the approach to resources. There needs to be an acknowledgement of the resources and people involved across both projects and BAU to ensure there isn’t resourcing gaps and challenges across the organisation and that people have sufficient time to deliver the quality of work that is required.

It’s critically important to understand the difference between a project and BAU, when defining which approach to take to the activity. It’s important to take the time to plan the activity effectively, understand the timings and how you as an organisation define the work required. Projects require a distinctly different approach and mindset; they are solving a problem and it’s important that they are temporary. In time, project outcomes may become part of BAU activity in organisations and become embedded across an organisation.

Is an MVP implementation the right approach for me and my digital project?

With the emergence of Agile as the preferred methodology for most software implementation projects in the non-profit sector, one of the more common early discussions we have with clients who are planning a digital project is now around Minimum Viable Product (MVP). Specifically, the questions we get asked focus on “what is it?”, “what does it mean in practice?”, and “is it right for me?”.

What is MVP?

Before we get in to the detail of the discussion, let’s first reflect on what MVP is meant to be, by taking the purist definition:

A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.

That definition is clear and valid, but it is purist and very difficult to apply in most of our projects, specifically because most of our projects involve the replacement of an existing system upon which a number of business functions and users rely. So could we simply replace “satisfy early adopters” with “prevent any degradation in service”, meaning that the new product or solution only has to enable us to do what the current solution does at the time of MVP launch?

There’s certainly an approach there which could be more widely applicable, in respect of the first half of the definition, but what about the second half, which speaks more to the purpose of the model. We have to have enough of an MVP release to enable us to assess the strengths, and weaknesses, of the solution, such that we can learn valuable lessons which will influence and impact the future releases.

Within that, the solution itself has to be flexible enough that we can adapt to the lessons we learn from MVP, not just in future releases but potentially also in retro-fitting features into the MVP implementation. What’s more, we have to be confident enough in the technology and partner to invest in the MVP release with a fair degree of uncertainty around the composition and nature (and cost) of future releases.

This is starting to sound quite challenging now, to fully understand and to put into practice.  It is though very much on trend to be promoting the model, so we need to think more specifically about how this could benefit the projects we’re initiating. Arguably then, it’s at this point that we need to put the purist definition back in the textbook and focus on the real-world benefits and disadvantages for our projects. The points below are those we discuss with our clients, in a more pragmatic vein, noting they are discussion points…!

What does it mean in practice?

Potential advantages of an MVP approach
  • You may be able to define a smaller, shorter initial implementation, which will carry less risk and involve a reduced initial investment in time and resources
  • You may be able to use MVP as a leader to prove that you can deliver successful projects
  • You will learn a lot from the project as a whole:
    • About the tech how it works, what it’s capable of
    • About the partner
    • About yourselves, your culture, your appetite for, and attitude towards, to change
  • You can identify champions and those who want to develop within your organisation
  • You should get a big data (and/or content) migration hurdle out of the way (as you’re replacing your current solution)
  • The scope can be adapted over time (but this comes with health warnings!)
  • You’ll be able to review business processes incrementally
  • You could go live with a ‘skinny’ but successful MVP and go on to build out a better informed, and de-risked, complete solution
Perceived drawbacks of the model
  • Your project may be seen in some quarters as a once in a lifetime change, which will exhaust you, so it needs to be one-pass generational change and a small MVP won’t cut it.
  • Your funders and senior stakeholders may be underwhelmed at the prospect of an MVP which only replaces current functionality despite them signing off a significant investment.
  • You may create a bun fight for what’s in scope.
  • Some stakeholders will resist and question “Will there ever be a Phase Two?”: you’ll need to give clear assurances.
  • You do still need to fund and resource the full project.
  • The demands you’ll place on your resources will go on for longer.
  • You need to be able to make resource available to run your MVP release as your live system, plus retain a project team for Phase Two – with a particular crunch around key resources, and your project team

Suppose it doesn’t go so well, MVP extends, everyone gets tired, the money runs out…

All of these points are valid for discussion and need to be carefully considered, in your context

By analysing the points above and seeing which weigh strongest on you and your organisation, you’ll start to get a good sense of the ultimate question…

Is it right for me? Or how do I know if it’s right for me?

In light of the pro’s and con’s above, it’s important to asses them against the criteria below:

  • People and the demands you’ll place on them
  • Culture can your organisation cope with the nature of incremental change
  • Budget can your budget be flexible and long-lasting enough
  • Discipline do you and your team have the discipline to manage scope

To succeed with an MVP approach you need a clear vision of the scope of your MVP and subsequent Phases, also based on what you need when.

In the eternal love triangle of time vs scope vs budget, we find that an MVP model works best where Time is the driving factor in the initial project. This is especially effective where you have hard timelines, driven by external constraints

Consider what capacity you have to deploy workarounds after the MVP release, from both a capacity and also user buy-in perspective.

Critically consider what resources you have available to deliver multiple releases, and to transition them into new ways of working whilst working on the next release.

Finally, test out the technology partner you’re working with: is MVP a core part of their model or is it opportunistic? If they’re promoting MVP because it’s on trend as opposed ot being baked into their method then it’s best avoided.

At the end of the day of course, MVP isn’t a new and radical concept.

The principle of defining phased implementations of new technology, as opposed to “big bang” launches, has been around for decades and remains a strong option for anyone. It’s become the current trend on the back of Agile’s current pre-eminence, but you don’t have to adopt a full Agile model to benefit from some components, so maybe that’s the takeaway.

When planning your implementation, break the deliverables out into potential phases and see if that’s viable for you. Can you replace elements of your current technology landscape incrementally, maintaining business-as-usual, without degrading services, and without having to invest significant additional funds to re-work integrations through the phases.

If you can, if you can resource it, and if culturally you buy in to the concept, then consider whether it’s more beneficial for you than one big implementation, including the considerations listed in this article in your decision making.

As a final “if”; if a phased model works for you and your technology partner, you can come back round to the original question, knowing what your drivers are for a phased implementation. Consider how close you are to the MVP minimalism of launching iterations of “what you need, when” with the primary purpose of learning from each iteration and using that feedback to influence the next phase, including building out full feature sets.

By then you’ll have worked out whether you’re going for big bang or a phased approach; whether you’re going for a phased approach or an MVP model; and whether the last point is just semantics!

 

For more insight into what it takes to implement new digital solutions, join our free-to-non-profits Training Programme “How to deliver successful projects”. The whole course is based on our in-depth knowledge of change programmes and project delivery, including Module 5 “Delivering a successful system implementation