Let me start by saying this is a purely anecdotal post. But what is lacks in statistical evidence it makes up for in my own eyewitness accounts of projects doomed to fail. I’m sure you’ll have seen this too.

Time and time again I’ve seen institutions running projects that will significanly affect their day-to-day business, but they clearly haven’t thought about what to call them. They’ve invested in governance processes, supporting tools, getting the right people involved, but not the name of the project.

What’s in a name? That which we call a rose
By any other name would smell as sweet.

Juliet knew nothing about project management. If she’d been better at planning she wouldn’t have been so star-crossed.

The name of the project is the thing that’s most readily communicated to the project team and stakeholders. It’s the daily reminder of the work that they’re doing and the benefits that they’re expecting. And yet the name we give a project typically detracts from its core values, with these examples as the most typical culprits:

The new technology

Why oh why have you called this project the “Social Media Marketing project”? Or the “CMS upgrade”? Or the “Intranet replacement”? What useful information could that possibly convey?

1. Does everyone involved in the project – from the people who’ll use the system to those who have to approve its budget – actually understand what that technology’s supposed to do? Does it really give all the stakeholders a good idea of project scope?
2. Why are you upgrading? Surely it’s not just so that you can say you’ve the latest version running… or is your organisation full of Apple fanbois? You upgrade because you’re missing key functionality, or because the existing system is underperforming, so at the very least call it a content strategy project which has an upgrade component to it.
3. And if you’re replacing a system, you’re actually compounding those two issues: do people understand what you’re getting rid of and why, and aren’t you replacing it with something that does a lot more? So it’s not a replacement, it’s a new strategic platform which enables the business to function more effectively. You’re not just throwing a wad of cash at a technology supplier in order to end up with exactly what you had before.

Naming a project after the technology is missing the whole point about what technology is. It’s an enabler, not an end solution. If your organisation thinks that by updating its technology it will solve its problems, you know that you’ll never meet your business goals.

The website redesign

I’m at a loss as to know where to begin with website redesign projects. As with new technology projects, the redesign isn’t an end in itself unless it’s some pure vanity project. The redesign is about improving how your audience achieves its tasks and that usually necessitates people who create content finding new ways to manage it, as well as identification of business objectives, target markets, persona, user experience testing, information architecture and so forth.

But calling a project a website redesign masks an endemic issue. It sets the expectation that once the project is complete, they’ll be no more work to do. Website redesign isn’t a project. It doesn’t have a start and an end. It’s a process of continuous improvement where your web team analyses audience interactions, responds to them and adjusts the website to improve how your organisation communicates with its customers online. If you turn it into a project, you’re effectively saying that you’re not going to fix what you know to be wrong until the project goes live, and that when it goes live you just need to sit back and measure the benefits. That approach is anathema to everything the web stands for: innovation, engagement, simplicity.

Clearly there will always be website projects that need to be run as projects, not least because corporate governance requires it. But they’re not redesigns. They’re projects to improve user experience, or to update a corporate brand, or to plan out a content strategy. Redesigns are fails before you even pass Go.

The acronym or buzzword

Some project management offices think they’re cool. That’s the only explanation that I can find for organisations that give their projects codenames or buzzwords or acronyms.

And guess what: project management offices aren’t cool.

I’ve worked with at least three organisations that called a project Prism. What for? None of them were about optics. It’s just someone thought it was a good idea to call them something cryptic. I’m pretty sure one was an intranet, another was a finance system but I really can’t remember what the third was… document management, perhaps?

The only thing that I can commend about those projects is that they didn’t fally into one of the first two traps. But they didn’t address the issues either. What on earth is project Prism, or project Orange or project Stan all about? Is it something that’s deliberately meant to exclude the majority of employees? Because that’s what it looks like, and it’s hardly going to get stakeholder buy-in if that’s the case.

Buzzword projects are doomed because they isolate the people working on them from the rest of the organisation and – worse still – they give the impression that actually the people working on them don’t really know what the project is about. I’ve seen many a buzzword project (though not the prism ones) being strategic projects where the organisation felt it had to do something, but it wasn’t exactly clear what that something was, and didn’t want other people to know about it until they’d figured that out so they could deliver the right message.

But they’d already delivered the wrong message. That no matter how competent the project team, they simply didn’t have a clue.

Choosing the right name

So if you can’t name the project after its core technology and you can’t call it a redesign and you can’t call it something you thought was cool, what can you call it?

Call it something relevant.

I realise that’s a boring answer, but you know what, every project you ever work should have a business objective. Call it the project content strategy improvement or expenses streamlining or improving our brand reach.

The name of your project should make transparent to all the stakeholders why you’re doing the project in the first place and keep the team focussed on what it is that they’re meant to achieve. Just because developers have done their bit doesn’t mean that the project will be a success.

So if your project is failing and you’re looking for a quick turnaround that might improve it, try renaming it according to where the team needs to focus. You might just avoid tragedy and a plague o’ both your houses.

L’enfer, Jean-Paul Sartre tells us, c’est les autres. This is so commonly and simplistically mistranslated as “hell is other people” that it’s become something of a fallacy. Hell for Sartre is not other people; it’s others. It’s about our faulty relationship with others and most particularly our psychological other, our id: the basic, instinctual drives that motivate us to seek out pleasure or avoid pain.

Those instinctual drives are very much at the heart of every project. A desire to move the organisation forward, to mitigate against business risks and seize profitable opportunities. And this desire underpins the project team, gives it a sense of togetherness, a common purpose. FTW! WOOT!

But this also means the team can just pile into a project without thinking it through, particularly if it’s being driven by someone with seniority in the organisation. The JFDI mentality prevails in these projects. Let’s just do it, get it over with and watch the cash roll in. Then, as complexity increases and mistakes are made, other emotional responses take over: blame-storming (particularly for teams who aren’t there: third-party suppliers or off-shore), hindsight, and the eventual withdrawal of project budgets. Suddenly you’ve gone from projected heaven to project hell.

Project management can of course help to control these urges. It provides the rational ego to counteract the emotional id. By introducing formal methodologies, you can moderate the project team’s urges and lead them to a more successful outcome. Theoretically, you could take any project and use ego-based techniques to deliver it. But that doesn’t mean you’d actually be delivering the right thing…

For that, you need a superego, a conscientious faculty to ensure you do the right thing. For projects, this means a governance process that ensures you have a reliable business case and that you continue to measure the business value of features that you implement, so you’re asking whether they’re valuable, rather than just whether they work or not.

• Super-ego-driven, conscientious projects will ask “is this worth doing?”
• Ego-driven projects will ask “is this working?”
• Id-driven projects will ask “why don’t I have this stuff?”

That’s an instinctive question, but the wrong question. It’s a question that’s asked by others and the question that will lead you to project hell.

Also worth reading:

Failure is not a positive by Piewords

When you reach the end of a sprint, you look back and consider what went well, what went badly and what can be improved. There’s a similar process for waterfall projects when you produce a lessons learned report to share with the rest of the PMO. While I’m sure you floccinaucinihilipilificate about this company’s 12-month performance, allow me to highlight three things I’ve noticed come to the fore in the last 12 months.

You need to demonstrate the tangible benefits your project will deliver as quickly as possible.

Of course, this has always been true. But the pressure to be lean and value-driven is greater than ever, driven I think not just by wider economics but also because the technologies we work with are more mature and with that, so are customer expectations.

Many people are in the third or fourth significant implementation of a content management system, whether for web or across the enterprise. Marketers have already made their initial forays into social media. Not seeing returns on information systems or web engagement simply isn’t good enough. So before putting their hands in their pockets, they’re quite rightly asking what they’re going to get back. As an industry, we need to answer that question quickly and credibly.

Events are being stretched.

People are increasingly participating in events from a distance and after they’ve finished. Television has stretched beyond the screen by broadcasting with hashtags which allow an audience – not all of whom are actually watching – to discuss programme content beyond the control of the programme’s producers. Whether this is music or politics, it’s a long way from the controlled comments policies of newspaper discussion forums. Huge numbers of people are using tablets and smart phones to communicate as they watch TV.

This applies to football matches too, whether from the armchair or the stadium; and very much to music, be it at a festival or on Spotify. The discussion extends way beyond the geography and the duration of the event; supported by the fact that the media doesn’t need to be watched there and then either. There’s gold in those hills, I just haven’t figured out how to extract it yet…

We could understand our market a lot better if we just took the time.

Sales people and analysts have been harping on about big data as the next big thing without too much detail around what it is or why it’s useful. But consider this. People now reveal huge amounts of personal information under highly obfuscated terms and conditions. If you could join up Facebook profiles, Flickr, Amazon, loyalty cards, credit ratings, browser history, and online social interactions, you’d have an incredibly complex and potentially frighteningly accurate picture of your market and how to sell to them.

If you’re a D2C organsiation or want to become one, getting that kind of data and being able to process it in a meaningful way is going to make your current online engagement look… well, pretty poor. Start thinking now about how you can get more data legally and how you might exploit it to reveal business information that will give you a competitive advantage. You can be sure that if you don’t, your competitors will.

1. Blanket cull

The easiest way for a board to implement austerity is just to withdraw funding for all new projects. This approach may be the simplest in the short term, but it’s also the most destructive. Any board that proposes this kind of cull is tacitly admitting its own incompetence. How can you engage effectively with an online market that requires you to respond to emerging trends without investing? Be under no illusions: cutting projects doesn’t mean a loss of new revenue streams; it means conceding market share.

2. Stick to your guns

Marginally better than stopping all new projects is permitting just those that conform to your corporate strategy. This is the typical approach of an executive that is totally convinced its strategy is correct. They’ll probably have the market research to support this conviction too. But this kind of tunnel vision is fraught with risks. Who wants to place all their eggs in one basket? You’ve got to have some room to hedge your bets. It’s not just that you need to respond to market trends, it’s also that people in your organisation innovate, and by applying a rigid strategy you effectively block out those innovators. They’ll be demotivated and, if their ideas are any good, guess what: they’ll take them to your competitors and you’ll be in no position to respond.

3. Additional governance

If the board is a touch more enlightened but still clinging to its purse strings, it will introduce extra governance procedures. This is a classic ploy in most large organisations: create some new hoops to jump through and hope that this puts off anyone who hasn’t completely thought their proposition through. But this recreates the same problems: you’re satisfying your existing bean-counting processes rather than trying to discover what potential benefits might emerge as a result of a project.
When an executive introduces more stringent procedures for budget approval, it’s often because it wants to appear strong but is actually completely disengaged. It’s handing over responsibility for key decisions to a set of formulae. When the project goes wrong it will blame a poorly-constructed business case rather than the more obvious cause of project failure: lack of executive involvement.

Budgetary control is not the same as leadership

All projects rely on the executive to be actively engaged: making decisions when they’re required, providing leadership and assuring that the project continues to be aligned with organisational objectives. Fundamentally, if your executive is adopting one of the approaches outlined above, it’s only thinking about the money, not about the project. And that’s likely to mean the project’s going to fail anyway.
So if it’s a bad idea to stop new projects, stick vigorously to your existing strategy or introduce extra governance, what can you do to save money?

You’re in a hole, stop digging

Organisations are littered with zombie projects: those that have been running seemingly forever but that have never delivered benefit. These are the projects that sap the morale of the teams working on them and engender snide remarks from other teams struggling with lesser budgets yet more likely to deliver.
If your project has already been running for more than a year, has missed major milestones (or, worse still, has no major milestones), has had more than one change of project manager or systems integrator, or is just setting a strategy for other projects to follow, you can be pretty sure that it’s not going to deliver against its original brief.
Why force everyone else to tighten their belts when you’re continuing to squander money on a project that has had an opportunity to deliver but failed? It seems so obvious when you’re stood on the outside, but I think most organisations can be honest and say they’ve let some projects go on too long when they should have pursued others.
Good programme management isn’t about relentlessly pursuing the same objectives with an ever-diminishing budget. It’s about the ability to shift focus and point your organisation towards new benefits. Imposing arbitrary rules just gets in the way. So be rigorous in your budget management, but be dynamic in going after new opportunities. Be less fearful of abandoning something that hasn’t worked than missing out on something that might.


See also Alan Pelz-Sharpe’s article on UK budget cuts and public sector IT and re-assessing the value of Enterprise Licence Agreements.

The attempts of Johnston Press, a publisher of local news in the UK, to implement a new content management system have spectacularly backfired. How can the selection of a CMS lead to a vote of no confidence in the managing director and a ballot on strike action by employees? That’s a pretty colossal project failure by any measure.

Johnston Press selected the Atex content management system. Atex, whose product is based on the acquisition of the Swedish CMS Polopoly, has carved itself a niche in the newspapers vertical and Johnston Press would no doubt have been reassured by their client list. However, the company imposed the choice of CMS on employees at a number of its titles and more importantly, inextricably linked the CMS to changes in working practice. The Guardian provides more background to the dispute.

So where did it all go wrong?

No stakeholder involvement

It’s truly crass management to push through a project without consulting those people who have to live with its consequences.  Johnston Press wanted to cut costs with an integrated cross-channel publishing environment and employees were right to fear that this would put their jobs at risk. So the CMS became an enemy, rather than a product that would help staff to work better and secure the company’s future. There may have been no way to get around job losses, but if there had been consultation about the reasons for the CMS, how it was going to work and the benefits that it would have, there could have been a more constructive dialogue and a greater chance of a decent outcome.

No content strategy

One reason why Johnston Press thought the CMS would bring cost savings was because they thought they could replace the role of sub-editors, getting the journalists who’d researched the stories to also place the stories and create the headlines. This may well have been possible, but it doesn’t look to have been that well thought through. The journalists were interested in gathering stories and information gathering. The sub-editors were interested in promoting the right messages and maintaining editorial standards. These objectives can conflict.

Again, had the management approached the project by identifying a content strategy issue – positioning the kind of tasks they wanted from their readers and establishing relevant journalistic and copy-writing processes to support these tasks – they would have stood a better chance of selling the benefits to their employees and having a successful project.

Lessons learned?

I would hope that your content management project failures haven’t been as extreme as this one, but I wanted to take two highlights from this project.

Firstly, it demonstrates the importance of an inclusive and transparent selection process. You need to involve the people who’ll receive business benefits from the system, the people who’ll support the system and the people who’ll use the system. And you need to communicate the business case to them transparently so that they understand the purpose of the CMS and don’t feel threatened by it once it’s been implemented.

Secondly, you still need people to assure content quality. The CMS can certainly help you build in those processes that assure quality, but you need real writers to write good content and achieve your business goals.

There’s a lesson for the supplier too. This publicity hasn’t been great for Atex. When a project goes so spectacularly wrong, it’s easy to assume that the software is the root cause. But there’s an onus on the supplier to deliver against a clear brief and ensure that the client isn’t being stupid. You may have got your commission, but at what cost?

If you have a more spectacular case of CMS failure than this, I’d love to hear it.

According to Douglas Adams’ Hitchhikers Guide to the Galaxy, the population of planet Earth was formed by a spaceship full of middle managers, hairdressers, marketeers and account executives. It’s easy to lump project managers into this mix. When Ford Prefect complains about this group’s inability to get stuff done — “This is futile! 573 committee meetings, and you haven’t even discovered fire yet!” — you can be sure that a project manager was there, maintaining the rolling action item log.

This is often exacerbated by project methodologies that foster a generic culture of project management, where all project management problems are essentially the same and if you can fix the issues around business case, stakeholders, executive sponsorship and resources you’re well on the way to project failure prevention. I’ve no doubt that these rules do apply for all projects, but I wonder that if you have a culture of just focussing on these issues you simply encourage project management by numbers where you get unthinking, standardised responses. As usual, Scot Adams got there first:

Even where you have a good project manger trying to help, it’s usually soft skills. Plant any management consultant in there and there’ll come up with the same answers without really having to get to grips with the fundamental issues. Why is the project struggling? Let’s not call lack of sponsorship a root cause when it’s just a symptom.

Sponsors are reluctant when they don’t understand project goals. You can see this for nearly any social media project. The business case is difficult to prove, the executive don’t buy into social media as reducing costs or increasing revenue, and the rigid formulae of business case definition help no one. This isn’t a sponsorship failure where the project manager can go in and mitigate against lack of funding. It’s fundamentally about whether an organisation is culturally ready to adopt social media and understand how they might use it. The project manager can facilitate this debate, but really you need a subject matter expert rather than a journalist who has read a couple of reports from the big analyst firms.

Jerry Manas recently wrote an article in which he suggests that project managers who run agile projects bring a completely different style to the table that’s much more concrete than traditional approaches. While I don’t agree with the entirety of his article, I think the main hypothesis is right. If you can get project managers who are close to the stakeholders, intimate with the issues and prove that they’re not just some glorified secretary, they can bring real value. Specialist projects require specialist experience and expertise and the world (of IT in particular) is littered with projects that have been delivered to industry best practice, but to abject failure.

The better generic project managers will continue to mitigate against failure and they’ll deliver their projects. But it the end, you’ll be judged on what you’ve delivered, not how you delivered it, and that’s where domain knowledge is essential.

My son will be just as precious to me whether he comes via forceps or scalpel. But it’s the people with the hard skills, not the soft skills, whom I’ll to put my faith in to ensure that he gets delivered safely.

Further reading

A recent presentation I made to the J. Boye community of practice on speeding up project delivery using techniques from Scrum and Prince2.

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’s tragic when you have one of those projects which seemed like a great idea at the time, but the longer the it goes on, the less enthused people become and everyone despairs of achieving success. Managing these is not a cathartic experience: it’s a time to pity the stakeholders and fear for the project benefits.

On the other hand there are laughable projects where you took so long to define requirements that your implementation and testing are squeezed into an impossibly short period. These would be funnier if wasn’t for the fact that as a stakeholder, you’re the one being mocked.

So how do you avoid plunging into despair or feeling ridiculous? Here are three theatrical tips:

1. Get adequate direction

Your governance structures are there for a reason. Use them. If you think the project is going off track, then engage with the project board and escalate issues for them to make a decision on. Stick to the script and resist the temptation to ad lib.

2. Engage with the whole audience

If only some of your stakeholders know what’s going on, your project will be in big trouble. Project reporting needs to be broadcast, not sent to individuals. Set up a project repository where anyone can read reports and documentation, ideally with RSS feeds, and let any stakeholder subscribe. That way everyone can engage with the project and show appreciation, or displeasure.

3. Use actions, not just words

The performance of your project won’t be measured by how much you talked it up. Take on the role assigned to you, step up to the front of the stage and perform as best you can.

Finally, remember that acting and project management are both about empathising with people’s emotions without succumbing to them yourself. If your project’s going badly, you should be able to understand why your stakeholders are upset without getting upset yourself.

But the operational savings that can be achieved with ECM are significantly greater than those typically made by rolling out WCM: there are time savings in information retrieval, cost savings in storage and reduced risk of compliance failure. You would expect these savings to be worth a great deal to most large organisations. Consequently, vendors can sell licences and services at a far higher cost than WCM.

Greater web content management costs can be justified in environments where devolved authorship, strong version control and compliance with web publishing standards are all required. This means that vendors can sell product licences at £200,000 knowing that what they offer can’t be achieved simply by installing WordPress. Commercial open source follows the same approach, but with pricing focussed on support and services.

It’s basic economics, but it’s worth recalling when you feel the costs of your implementation are running out of control. Products and services cost so much because clients tell suppliers that’s what they’re worth. It’s not up to your supplier to calculate your ROI; it’s up to the person paying the bill to do that.

The buyer sets a budget based on the benefits the project will bring, or the cost of not doing the project. Suppliers try to provide a solution that will bring about the benefits within the budget constraints. Together, they set up governance to ensure that the project doesn’t overrun or overspend, so that the business case remains viable.

The goal is not to deliver your project as cheaply as possible. It is to deliver the project in line with the specified business case. If you can save money then great, but if you’ve achieved your objectives, don’t worry that you might have been able to do it cheaper. Just bask in the contentment of having completed a successful project, an achievement that eludes so many.

See also Peter Sejersen’s article on whether you should reveal your budget when inviting tenders.

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