The future of the web is mobile. And by mobile I don’t mean mobile phones. I mean browsing through devices that people carry around with them. All these devices, irrespective of form factor, have a common problem: they are prone to lose connectivity to the internet.

If you’re on the move and keep losing your 3G signal, or just happen to live in an area with a poor reception, or in a house with brick walls which slow wifi, or suffer from terrible contention rates in your Starbucks or conference venue, you’ll know that cable-less connectivity is fallible. So you’re in the middle of a transaction, just trying to get to the next step when… enter tunnel / lose packet / connection error and you have to start over.

There is a solution to this problem however. As Michael Kowalski tells us, the future of the web is JavaScript. Or perhaps not JavaScript in its current form, but client-side scripting nonetheless. Why? Consider the options.

If you want interaction that will run reliably on a device with poor connectivity, you can’t keep expecting the browser to go back to a server. So you might make your functionality available as a downloadable app. But it had better be a killer app the user wants to rely on, because otherwise they won’t want it taking up real estate on their phone. And it’ll have to run across operating systems if you want to reach a broad market, not just Steve Jobs’ latest toy.

You could use a rich internet application such as Flash or Silverlight. But the client platform has to support these and the user has to install them, although they’re more likely to do so for a generic RIA than for a specific tool. The big issue with these applications however is that the content is embedded in the interface, which makes them both heavy to download and difficult to make accessible to other applications, such as screen readers and content aggregators. So you’d probably have to create two versions of the content: one embedded in the RIA, the other standalone. That’s not great.

JavaScript has the advantage that it can be used to enrich content, but not contain the content itself; for example, to provide better interactivity on maps. There are also libraries of JavaScript functions that can be re-used and downloaded to the client device with the user barely noticing. Take jquery: Google hosts a copy, so if you use these functions on your site, you don’t even need to host the file. Reference Google’s copy and you’ll save bandwidth and, if enough websites follow the same path, there’ll probably be a cached copy on the user’s machine even before they get to your site, which will significantly improve response times.

Google is of course moving beyond jquery to complex client-side scripting which its own browser / operating system will be capable of handling, but some other browsers may struggle with. Chrome is a replacement for off-line scripting using Gears. It should not only enable mini applications such as Wave to run faster in a browser, but will enable online transactions to continue to function better when connections are poor. Opera has been developing similar functionality for its browser too.

So if you want to provide audiences with a better experience irrespective of platform and location, a lightweight client-side tool that separates content and function and runs in a browser seems like a future-proof idea. And for the moment at least, that means JavaScript.

Let’s say you try to consolidate to a single content management system. The smaller the user base for that CMS, the more likely you are to meet its requirements. As soon as you extend the CMS to multiple teams with different ways of working, different audiences and different kinds of content, you have a change management programme on your hands. The focus has shifted from where it should be, online engagement, to training existing users in new ways of working.

Over-rationalisation tends to lead to over-generalisation, and that in turn leads to a poor fit to requirements. If you generalise too much, you’ll necessarily have to introduce customisation to your system, which was precisely what you were trying to avoid in the first place.

This isn’t the only area where too much rationalisation fails to reduce costs. While preferred supplier lists brings down the cost of procurement, they’re unlikely to reduce the cost of implementation. Qualification to be a preferred supplier is strenuous, but once you’re on the list there’s very little incentive to control your prices. Preferred supplier lists can make procurement inflexible and frustrating for the business users too. New entrants to the market are seldom present, so it’s nearly impossible for government departments to be early adopters. This makes government look like it’s off-message, when in reality many civil servants are swimming against the tide to provide a good service.

What government and many other large procuring organisations end up with is a possibly cheaper but probably riskier solution: over-ambitious projects that take too long to implement and that can’t meet emerging requirements. The larger the project, the more changes to requirements will emerge and the less rational it will become. These kind of strategic rationalisations are doomed to failure. To paraphrase John Maynard Keynes, your project’s business case can stay irrational longer than your project can stay solvent.

Rationalising your web presence is a great aspiration to have, but your have to rein in your ambitions. Rationalise a feature, not the whole system, then you’re more likely to see some cost savings.

It appears to me that organisations try to introduce too much web 2.0 culture into these projects while continuing to have rigid expections.

The objectives for social media on the web are emergent: they are the result of uncoordinated initiatives, with the benefits only becoming apparent as the site is used. Business change on the other hand is typically vision-led: there’s a clear idea of the business benefits before work starts and these are based on evidence derived from organisational learning. Moreover, on the web, adoption of new tools is viral. Within organisations, adoption is typically enforced.

Many organisational social media projects are sold to the business by middle management, early adopters who use similar tools outside the office. They believe that because a tool is widely used externally, it will be rapidly adopted internally too. This is rarely the case. The web provides a user base that far outstrips any organisation’s and staff have more pressing priorities than trying out a new technology. Moreover, executives need a concrete business case to approve a project. Saying “Twitter’s great” simply doesn’t cut it. The differences in approach are transparent:

Promoters of social media within organisations must meet pre-agreed objectives and promote the tool from the lower rungs of the management ladder. This guarantees frustration all round: project advocates believe executives are being obstructive, but executives wonder why the project isn’t achieving its business case.

You need to shift the axis. Don’t focus on the problems social technologies will solve. Compel your staff to use them as a communications channel and find out what benefit they bring. You can reduce the risk of failure by constraining your spending, so the tool is less painful to throw away, but you need top-down leadership to drive the programme or people will just focus on their day job.

A few practical steps:

1. Choose something that’s familiar and frequently used.
   Staff need to grasp the tool’s basics quickly. If it’s overly complicated, your efforts will be invested in training rather than measuring benefits. It’s also got to be something that’s used on a daily basis. If you have a wiki on best practice, for example, it’ll get contributions for a week or two then just become forgotten about.
2. Make sure it’s throw-away.
   To prove the concept, select something cheap or hosted, with low start-up costs. And make sure that you don’t put content or data in it that’s critical to your business strategy that you then can’t get out again.
3. Don’t customise it!
   The world is littered with pilot projects that thought they knew better than the software before they’d used it, or tried to integrate it with other tools and turned into never-ending testing. Just run the technology as it is, in the simplest way possible. If it works, then consider how to improve it.
4. Engage key users.
   Your trial should certainly get the executive to put their mouth where their money is. If they lead others will follow. Your sample group of users — you weren’t going to roll it out to everyone at once were you? — should include different departments so that it’s not seen as anyone else’s “baby” when you finally roll it out.
5. It’s a trial people must follow.
   Using the new tool is not optional. Ideally, they’ll use it instead of something else, so a wiki instead of a file system, blog instead of broadcast email, micro-blog instead of instant messaging. If you think of how CRM software is typically rolled out in a business, you’ll see how important this kind of enforcement is to making adoption of the software a success.

For social media to be effective in your organisation, you can’t expect it just to be taken up by the user base. You have to drive it through. But you do need to be open-minded about what it will achieve. Hopefully, you’ll be pleasantly surprised.

Some further reading:

• Janetti Chon – Enterprise 2.0 Adoption Survey
• James Robertson – Implementing enterprise 2.0 in the real world
• Shawn Callahan – Collaboration consulting—fostering a collaboration culture
• Dion Hinchcliffe – 12 Rules For Bringing ‘Social’ To Your Business
• Erik Larson – The Future of Work
• Anne Berkowitch – Private Social Networks (podcast)

But what the books don’t tell you is that while piglets 1 and 2 were sheltered by their less than robust housing, piglet 3 faced rocketing costs, toil, tears and the emergent threat of swine flu.

In the seldom-told sequel, pigs 1 and 2 are forced to vacate the house that was designed for one small piglet rather than three growing hogs. They lack the skill and resources to build their own brick houses and end up destitute and living in fear of Tom the piper’s son.

As an architect, piglet 3’s end vision is certainly the right one — or would be if he foresees having to accommodate his two brothers. But in order to fulfil that vision you need the skills, resources and time.

If you’ve an immediate problem finding the right shelter for your content, then long-term strategic planning for a robust future vision is likely to be the wrong approach. You need to find a quick way to protect your resources, assess the situation then plan your next step. You’re unlikely to face a fatal threat – it’ll just be lupine bluster – and even less likely to have enough time and money to mitigate against the problem anyway. Start building, see if it works and, if it doesn’t, tear it down again. Being able to manage even a small amount of your content in a robust way is better than just having a visionary strategy.

Those three tips:

1. Choose two high-value objectives; one that should be simple to achieve and the other likely to be complicated.
2. Select a technology to deliver these objectives that is in your existing skill set and technology stack. Only buy licences required to meet the project objectives.
3. Implement the project as quickly as possible and evaluate the success or otherwise six months later.

ECM doesn’t have to be a swine to implement. As long as you don’t try to go the whole hog from the start you’ll avoid making a pig’s ear of the project and be sure to bring home the bacon. It’s a ham-fisted analogy, but it’s no fairy tale.

Further reading on the failings of web strategy:

1. Anthony Bradley – Your Web Site Strategy is Destined to Fail
2. Dennis D. McDonald – How to avoid common strategic planning mistakes
3. Maish Nichani – Mapping your website redesign strategy
4. Gerry McGovern – Web redesign is bad strategy

A previous project I ran was to implement an internal knowledge management portal for a company that had been through several rapid mergers of some pretty small companies into a pretty large one. The company’s success is based on its staff expertise and wealth of project experience, but the full range and depth of this knowledge lay fragmented across a few people from the various entities that constituted the new whole. As a consequence, the sales team didn’t know that they could use staff who’d already engaged with a particular client, or that there were case studies for similar projects including case studies and lessons learned. The wheel was being reinvented. It was obvious that some kind of networking tool that enabled staff to identify expertise in people and projects would lend the business a helping hand and could be implemented with relative ease.

Instead, the directors decided that a search engine that could span all the company’s file servers would be more cost-effective. But how many useful results did the staff get from keyword searches? For all the typical reasons – little classification, poor naming conventions, poor security, inappropriate technology – close to none. The content was there but the information wasn’t.

Just as art only becomes art once you place it in a gallery, content only becomes information when you identify it as useful. The quality of the information, like art, is debatable, but it has no chance of being used if you don’t suggest to people that it’s useful information. Following a merger, staff need to know: these are the kind of people who work here and this is what they know about. To find out more, ask them.

Yet even in the most obvious of cases for implementing simple information management tools, their raison d’être can be by-passed. The company in question didn’t implement a networking tool and nearly two years later still doesn’t know some of its clients, the skills of many of its staff or the scope of most of its past projects. Many staff have left. Yet is the company bothered? Absolutely not.

The directors simply changed the strategy. If the sales team weren’t paying attention to certain clients or types of projects, it’s because they weren’t important enough. The strategy dictated that employees focus on bigger and better in their portfolio, as befitted the newly-merged company status. Who needs the past when you have the future?

It’s a bullish policy in a bullish market, but when things inevitably turn bearish, there’ll be a scramble to avoid repeating the mistakes of previous engagements, find people with relevant knowledge, return to reliable clients who weren’t in the big league. By then, both employees and clients could be long gone, and gleaning information from fragmentary content may well prove impossible.

While your work is easy, information has little value. As soon as your work gets tough, it’s the people and companies with the information who’ll profit.

Updated: Alan Pelz-Sharpe has also written about ECM technologies and recession.

A typical example is to implement folksonomies for relatively small websites. Folksonomy (or social tagging) works for large sites with an engaged readership. The sheer volume of tags and people tagging supports rather than counteracts other classification systems. But this simply won’t work if your editors are adding more content than your audience is actively classifying.

Similarly, you may look at other websites with rich media and think that’s what’s driving visitors to their site, when the opposite may be true. Just look at what happened when The Register introduced video reviews for an audience that browses the site while at work.

These kinds of implementations are often driven by the fear of being left behind, losing audience and revenue. Many organisations feel they should be on Web “version 2.0″ by now, irrespective of whether they can articulate what that functionality is or what purpose it will solve. So how do you fight the fear? You need to set out some clear business-driven objectives for the web.

These objectives are common across practically every organisation: increase market share, reduce costs, reinforce brand, improve communication with customers and so forth. Every system requirement that you specify will need to meet one of these objectives. If a requirement is completely off the wall, then it’s either not relevant for the organisation or the organisation needs to reassess its objectives. When you record your requirements, these should be mapped to an objective and validated by the body responsible for meeting the objective: the marketing team, customer relations, IT, etc.

Once you’ve recorded all your requirements, you can develop functional solutions for each one. Again, the relationships between requirement and functionality should be tracked, so when you come to decide about functionality that will be in project scope, you have a clear idea why you’re implementing any given feature. You’ll then be able to ensure that requirements are driving functionality, rather than the other way around.

Just as your organisational objectives will corroborate your organisational strategy, so the requirements you document will inform the technical strategy you adopt. Do your requirements suggest the need for a web content management system, or an enterprise version to manage documents, or federated search, or wiki tools? You should be able to design a technical strategy once you have an overview of the requirements. This strategy will also inform the functionality you specify to meet the requirements. If your strategy dictates project teams should collaborate using blogs, this should be consistent across your web presence; you shouldn’t end up with a mix of blogs, Word documents and forums. If you can achieve this level of consistency, your technical and organisational strategies will be appropriately aligned.

So stave off your fear of being left behind technologically. Being at the technological bleeding edge will bring you little reward, as Get Strategic points out. Focus instead about meeting your business goals and ensuring that your technology is being designed with these in mind. Didn’t you want business 2.0 rather than web 2.0?

Your readership and advertisers may have surprisingly divergent requirements. Advertisers aren’t necessarily interested in your audience: they’re interested in your audience’s money and in their own reputation. We’ve all been to deeply unattractive sites with great content (this site may well be one of them) and we’re satisfied with the look and feel because we know our way around.

But when it comes to advertising your product on an ugly page, it’s a quite different proposition. You can attract loads of traffic to your site, but why would a prestige supplier want to promote their product on an ugly page? Advertisers are attracted by things that are new: rich media, web 2.0 functionality (whatever that may be), boxes with curved edges, regular font sizes in Helvetica… All right, that’s quite a cynical view, but it’s hard to sell space on a site that is visually unattractive.

So even if your audience are telling you that they like the simplicity of your pages, pause to think. If they’ll put up with ugly pages, they’ll put up with beautiful pages as long as the content is good. And if you have beautiful pages, you may even make some money out of your content.

Hedgehog concept
Collins describes at length what he calls a hedgehog, so don’t expect me to plagiarise the concept, just read the book. The main thrust of the concept is that businesses and — I propose — websites must focus on one big thing and be great at it; don’t dip into other peripheral activities. If the core activity is well-founded, this is where you’re going to achieve sustained success, not somewhere else.

How do you define what that one big thing should be? There are three questions you need to ask:

1. What you can be the best in the world at?
   And conversely, what you cannot be the best in the world at? This is not about a strategy or desire, but about an understanding of where your strengths and opportunities lie.
   I’ve previously criticised clients who declare in their tender documentation that they want to build a world-class website when they don’t have a world-class budget, but I’m reconsidering this position. The web is of course worldwide, so if you’re going to compete, you need to be providing something that your global competitors don’t. Now that may well be a local view: a local commercial service or information specific to a geography. But the salient point is that if the website isn’t attracting its target audience and at least challenging both its online and offline competition, then it’s not doing its job. Moreover, if it isn’t a website you can be proud of, you’re not doing your job.
   The web is still a relatively new economy, with all kinds of business models that are still in their infancy. There’s room for more world-class websites out there and yours should be one of them.
2. What drives your economic engine?
   In Collins’ world, this question involves a deep understanding of the economic models in your sector. In the web world, it translates to a relatively simple question: What makes your website worth visiting?
   Is it the information you provide, the way you collate information from multiple sources and present in one place, the brand your visitors buy into, a need to participate and engage with like-minded people? You have to be able to identify why the website is important to other people.
3. What are you deeply passionate about?
   Just as important as ensuring your web presence is important to other people is ensuring that it’s important to you and your organisation. If you’re not interested in producing content for your site, you shouldn’t bother. Just get rid of it. Don’t pad it out.
   Let the website reflect your organisation’s professional integrity. Let it be something where your teams can prove they’re the right people to be setting a vision. Let it reflect the outputs of heated debates you’ve had with your stakeholders about what the website should say about your organisation and how you want to be perceived. Show that you’ve encouraged input and that people believe in what’s on the web. Don’t let your website become straplines and mission statements.

You’ll find the big thing for your website where the answers to these three questions intersect. Put all your effort into this one thing and abandon everything else. Collins suggests having a “stop doing” list.

Culture of discipline
Content management systems were invented to cater for two main problems: providing editors with the means to publish content efficiently without needing to know about web technologies like HTML, and providing a means of controlling the content that is added by those editors, so that it conforms to predefined styles and patterns appropriate to the website.

This rigour is often welcome, allowing you to remain on brand, but you need a degree of entrepreneurship too. What does a site where all the content looks exactly the same say about your organisation? Perhaps that it’s completely process-driven and unlikely to ever dig its way out of a hole…

The system may be able to constrain your editors, but that doesn’t mean that it should. The editorial team should actually understand why those constraints are there: the benefits of consistency, or of an informed approach to information architecture and navigation, of being on-brand. Once they understand and agree with these principles, you won’t need to build systems to enforce standards: the editors will do this for themselves. You’ll be able to de-systematise the constraints as a culture of discipline pervades the way content is produced for the web. If someone then breaks the mould, you’ll know that they’re doing it for a reason, because the mould is too rigid or insufficient for emerging needs.

Just as the project sponsors and stakeholders needed to cast off empire-building and egotism, so the editorial team need to espouse the ideal of a common good. Their professional integrity will translate into a disciplined approach and your website will benefit as a consequence.

Technology accelerators
We haven’t even mentioned technology yet. Cultures rather than systems of discipline may prompt ideas of Enterprise 2.0, wikis and blogs. But Collins tells us that in his team’s analysis of business success, technology was never the primary cause of either success or decline. This is almost certainly true of websites.

So many times you’ll see organisations where the technology tail is wagging the business dog. Someone will tell you that they need a portal, or SOA, or ECM, or the semantic web. Why? What are you trying to achieve? Are you just trying to increase the IT budget?

There’s nothing intrinsically wrong with these technologies, indeed they may be the best way of supporting the one big thing you’re trying to achieve. But they are absolutely not an end in themselves. Collins found that in businesses, technology could accelerate momentum, but could not create it. Tellingly, he also found that “Those who turn good into great are motivated by a deep creative urge and inner compulsion for sheer unadulterated excellence for its own sake. Those who build and perpetuate mediocrity, in contrast, are motivated more by the fear of being left behind.”

Only pick technologies that will help you deliver your one big idea. If you don’t need to deliver information in a single place aggregated live from diverse systems, why are you even considering portal technologies? If you don’t need to link documents, email and web content, how will ECM help you achieve your goals?

Conclusion
Good to Great is really based on just two concepts: teamwork and focus. You need to form a team to identify and challenge the problems that your website poses. You then need to focus obsessively on the one thing that is most important for fixing those problems, casting everything else aside. Collins doesn’t tell us that this is easy. But if you can follow his process, you’ll be well on your way to having a really great website.

Level 5 leadership
Collins found that all the top-performing companies he analysed were led by people who combined personal humility with professional willpower. It’s easy to extend these characteristics to websites, where a major barrier to success is vanity. If the website is your “baby” or reflects the parochial concerns of your departmental or organisational structures, it will never be a great website.

While sponsors and stakeholders empire build, or focus too much on the website and not enough on the web as Gerry McGovern points out, you cannot achieve your potential. The message should not be “when I was in my last job, I did it this way”. The message should be “we need to improve, we need to stop doing things badly”. This is a matter of professional integrity and resolve, not a way to boost egos.

First who… then what
If you recognise that you don’t have the skills or time to do everything yourself, you’ll also see the need to be supported by a good team of editorial, information design, creative, technical and project management people. You just need to get them on the bus. If they’re any good and have encountered similar problems before, you won’t need to set directions for them. They’ll see the need to improve and will be able to start advising you where the problems are.

For example, when Contented Management staff go into a project, we don’t expect to be told the big vision or what a project should look like. If you know that already, you don’t need us. You just need a bunch of body-shopping coders to implement the changes. You bring us on board because we sign up to helping you the best way we know how.

So don’t decide where the bus is going before the right people are on board. A strong team can set a common vision; whoever came up with the idea in the first place is immaterial. If the idea is right, everyone should buy into it and pursue it relentlessly, just wanting to be a part of a website they can be proud of having helped to develop.

Confront the brutal facts
Above all, the common vision needs above all to be well-informed. There’s absolutely no point in speculation. Collins talks about the importance of a climate where the truth is heard.

Many people just want to know what’s convenient: that your WCM is a great platform for managing content, that it’s robust and performs well, that the users love it, that the websites it generates are standards compliant, that your projects follow best practice methodologies, and so forth. The reality may be quite different, but how do you find out?

Collins proposes four ways to get to the truth:

1. Lead with questions, not answers.
   Hopefully previous posts on requirements will give you some indication of what you should be asking, but I think an important point here is that people won’t simply accept the truth just because you tell them it’s staring them in the face. Site owners may tell you that they have high bounce rates, where visitors come to a single page and then leave again, because they’ve found all the information they need on that one page. But is that really what’s required? What about cross-selling opportunities, or more complete views of the information, or suggested further reading? Do none of your visitors want those things?
2. Engage in dialogue and debate, not coercion.
   Just because there are standards out there, doesn’t mean you have to use them. A CMS can compel editors to display their content in certain formats, but there’s not much point if the editorial team doesn’t buy into it. Discuss how your audiences consume your content now and how you want them to consume it in future. If you choose to standardise, do so because your stakeholders agree with the obvious benefits. But give yourselves some leeway, so that stakeholders can have a non-standard feature if they can prove its business case.
3. Conduct autopsies, without blame.
   Undoubtedly one of the toughest things to do is to figure out why something went wrong. I’ve had assessments carried out on the projects I’ve run, and I’ve had to run many reviews of failed projects that someone else has been responsible for. But how many projects ever run smoothly?
   You need to accept that things are going to go wrong and that a collective effort is required to put them right again. We prosper and suffer together. If a person makes a mistake, someone else should be there to support them.
   This brings us back to leadership style. Fixing problems is a matter of professional integrity, not of ego-bashing. And if the right people are on the bus, they should be looking out for each other.
4. Build “red flag” mechanisms.
   Being able to confront the brutal facts depends on having the facts in the first place. I’m going to talk about Key Performance Indicators at a later date, but you need to know when something is going wrong as soon as possible. This could be lack of site traffic, high drop-off rates, people preferring other information channels (such as print, or even call centres!), difficulties in estimating and planning enhancements, high costs… anything associated with running a website.
   One of the first tasks you’re going to have before you embark on real improvements to your web environment is to be able to determine just where things are going wrong, so you can either fix them or abandon that activity entirely.

As Collins repeatedly notes, great companies don’t focus principally on what to do, they focus equally on what not to do and what to stop doing. If you get this right, you’ll get the breakthrough, which I’m going to cover in the next post.

SWOT analysis is a long-standing if relatively simple technique used across many types of business to provide the executive with a summary of the current situation. It should be easy to read and quick to determine, rather than involve weeks of assessment and long reports. It should be a couple of pages document or four slides that highlight the most salient issues. You can find some templates on Business Balls.

The contents of your SWOT should cover all the facets of WCM: commercials, technical, design, operational.

Strengths and Weaknesses

• Does your WCM meet performance and availability expectations?
• Is the site W3C compliant and accessible?
• Does it meet usability criteria for both consumers and contributors?
• Does the content meet quality expectations for target audiences?
• Are you able to track key performance indicators? What are they telling you?
• Are the business objectives for the WCM in tandem with organisational objectives and strategy?
• If so, are these objectives represented in the site’s look, feel and functionality?
• What extra functionality are your competitors offering? What advantages does this give them?

Opportunities and Threats

Porter’s five forces for competitive advantage provide us with a good baseline for assessing opportunities and threats. In WCM terms, these translate as follows:

• Potential entrants: Are you considering all the delivery channels: syndication, mobile, widgets, etc.
• Buyers: Which markets could you expand into? What are your audience expectations as they begin to consume other web technologies (Facebook, Youtube, iGoogle)?
• Substitutes: Do collaborative tools like blogs and wikis threaten your content management processes? If you have a large Enterprise Content Management platform, is this challenged by Software As A Service, or by Basic Content Services?
• Suppliers: How dependent is the system on a single supplier, whether internal or external? What contingencies do you have in place should you lose this resource? If you’re going to make enhancements, what sort of training or procurement implications would this have?
• How do I exploit all the content which might be relevant to my audiences? How do I make the information I’m presenting be cohesive and comprehensive?

Who should make the assessment?

Lots of questions, but who should answer them? You need someone sufficiently distanced from the site as it stands that they won’t simply rubber-stamp the current situation or rubbish it completely. But the person (or people) undertaking the SWOT also needs to be engaged with the site and its users.

So you need to engage an independent expert who then runs a brainstorm with stakeholders around the bullet points listed above, but who you give sufficient licence to that they can be completely honest about your implementation. You’re asking someone to take a sword to the site not to themselves, so expect to hear things that you’d really rather not have known.
Why is this approach useful

Too many times, project teams are given a brief that’s just an abstract assortment of ideas. A SWOT analysis provides a structured way of getting to the root of the problem. As I said at the start, this is just the first step. Steps two and three are about identifying requirements that tackle the issues the SWOT raises and prioritising those requirements so that you can figure out what’s worth changing. I’ll tackle these two steps in subsequent postings.