1. Introduction

1.1 Welcome to the Course

Have you ever experience a digital project that ran over budget and missed it's deadline? Of course, you have, we all have. But why does that happen and why do so many websites seem to fail to live up to their potential even after they've been launched? My name is Paul Barrack and I would encourage you to join me as I explore why so many sites fail and how it can be avoided by adopting a different approach to how we go about creating those sites in the first place.

2. Improving Your Digital Offering

2.1 The Problem With Digital Projects

Hello, my name is Paul Boag, and I want to welcome you to this presentation on optimizing your digital services. In this presentation, I want to show you how a better approach to your websites and mobile apps will make all the difference. An approach that will ensure that they're operating at peak performance, meeting the needs of users, and fulfilling your business objectives. But before we jump into all of that, you might be wondering what's wrong with the way you're currently building your digital services. Of course, I don't know exactly how you go about doing things. But what I do know is that many organizations experience disappointing results from their digital services, largely because of the way they go about creating them. Many website typically run massively over budget largely because they were created using outdated methodologies that have been used for managing projects for decades. For example, Birmingham City Council, here in the UK went £2 million over budget when creating their website. Meanwhile, in the US, the healthcare.gov website is estimated to cost anywhere between $319 million and 677 million. However, my personal favorite was the Department of Trade and Industry website within the British government. Their website was estimated to cost £11.78 per person who visited the website, per visit. It would actually have been cheaper for people to ring up the Department than it would be to inquire via the website. When I first found that out about the massive cost of visiting the Department's website, I couldn't resist going to the site and constantly hitting refresh. However, I quickly realized that I'm a British tax payer, and so that probably wasn't such a great idea. So, why is it that digital projects such as these fail? Why is it that their sites run over budget and time, but often fail to satisfy either business goals or user needs? The answer lies in the way that these projects are commissioned and built. The typical project life cycle looks something like this. Somebody, normally in senior management, has a bright idea. For whatever reason, they decide that the website needs to be redesigned or they need a new mobile app. After outlining their broad vision for the project, it's typically handed across to some form of project manager who often forms a committee to work out the detailed specification. Huge effort and time is put into ensuring that the specification is absolutely spot on. Everybody has to agree on exactly what the website and app will do so that the budget can be allocated and the resources made available. Once the specification is complete, development can begin. At this point, scope, creep, and change become the enemy. The aim is to deliver to the specification within the project's timeline and budget, all of which have been agreed up front. When the work is finally completed, often over budget and behind schedule, the team and budgets are then reassigned to other projects. Only superficial maintenance is done as required. What's interesting to notice is that this project life cycle is no different from building a factory or some other physical product. It's the project life cycle that has existed since the Industrial Revolution and has really changed very little. However, in the case of digital at least, it's far from ideal. For a start, it's not until a new website or app launches that we really begin to understand how people are actually gonna use it. That is because it's only when we see them interacting with the final product in a completely natural way that we get real insights. Although usability testing will give us some insights before launch, nothing compares to a live site for realistic data. Unfortunately, the very moment that we begin to learn about user behavior is the exact same moment that budgets and people are reassigned. There’s no money or resources available to act on the insights that we have started to gather. However, the sudden disappearance of resources at the end of our project, barring some basic maintenance, also creates another problem. It leads to a boom/bust cycle of periodic redesign. Once a new website has been launched, it's largely neglected in many cases. The design slowly becomes dated, and the technology is supplanted by more advanced solutions. As to the content, well, that becomes increasingly inaccurate and unfit for purpose as the organization changes. Eventually, the effectiveness of the website starts to diminish where it is actually more damaging to the organization than it is beneficial. However, it takes somebody in senior management a while to realize that this is the case and that the website has fallen into a state of disrepair. So, for a significant part of its existence, the website is actually damaging the company. Admittedly, you could argue about exactly how long this is the case. But suffice it to say, the majority of its existence a website is operating below peak performance because of a lack of investment. When senior management does finally realize that there is a problem and frees up some resources to address it, this typically involves another redesign project. This effectively throws out the whole of the old site and starts again from scratch. And that's normally a very wasteful process that results in throwing out both good and bad elements of the site. Also, once this redesign has been completed, the money once again dries up and resources are allocated elsewhere, and we enter yet another period of under-investment. Effectively, many organizations still see their website as a capital expense. They buy a new website every few years rather than continually evolving and developing their website over time. But it's not just how organizations invest in their digital products that is causing a problem. It's also how they choose to run them, as well. An approach that is largely dictated by existing departmental silos left over from the pre-digital era. A typical project looks something like this. A Manager briefs a Project Manager about what he or she wants to see built. The Project Manager then works with the User Interface Designer to create visual representations of that digital service. And after considerable back and forth, arguing over every detail of the design, the Manager eventually signs it off. This is typically the point that the Developer is then brought in from a different department to actually make the design concept a reality. Unfortunately, all too often, the design concept agreed is not particularly practical from a development perspective. However, because such effort has gone into approving the design, the Project Manager and Designer are reluctant to introduce changes at this stage. Eventually, once the Developer has done his or her job, the Content Creator is brought in, and they start to populate the website with content. Again, this causes problems because the tools created by the Developer is not always particularly easy to use from a content creation point of view. On top of this, there's little relationship between the content being created and the visual appearance of the website because they were done at completely separate parts of the project. Effectively, the interface is nothing more than a repository into which you pour the content. This production line approach is where projects are passed from department to department and specialist to specialist. And it creates further complications because, oftentimes, it happens within a consensus based culture that many organizations operate in. And so, there are all kinds of issues with this approach. Often, simply getting agreement over what needs to be built involves endless meetings, committees, and consultation phases. Ironically, the actual team who will design and build the site are very rarely involved in the process of deciding what it is that should be built. And that just strikes me as bizarre. And then, of course, nobody speaks to the user about what they actually need. This high level of consultation makes sense when the cost of failure is high. For example, when commissioning a new factory, everyone wants to be sure that what you're building is exactly right before you begin. And it's because the cost of change, once construction is started, is prohibitive. But things are different when it comes to digital. For a start, the raw materials of digital projects are free. Unlike building materials, pixels cost nothing. That means, effectively, you're only paying for people's time to design and code the website. This allows considerably more experimentation when compared to a more traditional project. Secondly, digital projects provide us with unparalleled amounts of data. By analyzing analytics, carrying out split testing, watching user behavior, and monitoring social media, we're able to get a pretty clear understanding of what users want to achieve. This information should be informing the direction our digital projects take. Unfortunately, more often than not, the process doesn't accommodate any of this kind of data gathering. How, then, should we be approaching digital projects differently? Well, that's the topic for our next video, so make sure you join me then. But until then, thanks for watching.