Contented Management

Want to improve your project? Change its name

Street sign - Casa di Giulietta - covered in stickers and graffiti

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?

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?
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.
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.

Philippe Parker on Adoption, psychology | 17 February 2012 | Tweet this | Follow @proops

Comments Off

Contented Management

Project hell is others – not other people

Devilish ducks

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

Philippe Parker on psychology | 10 January 2012 | Tweet this | Follow @proops

Comments (2)

Contented Management

A 2011 retrospective

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.

Philippe Parker on big-data, ROI, Twitter | 21 December 2011 | Tweet this | Follow @proops

Comments Off

Contented Management

Culling web projects in the age of austerity

Statue of an emaciated Buddha

Austerity is on the agenda. Across Europe, business and governments are making cuts in spending. In the UK, this means a further “clampdown” on the number of central government websites, while many private sector organisations are looking to reduce the total cost of their web presence.
Shareholders and taxpayers will applaud budgetary asceticism, but there has to be a middle way. Cut budgets from the wrong projects and you won’t achieve your online goals. Cut too far and you’ll undermine your ability to respond to new market challenges. Short-term gain will lead to long-term pain.
So what’s the best way to decide which budgets should be protected and which should be culled? I’ve found executive boards typically consider three propositions.

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.

Philippe Parker on Government | 16 September 2010 | Tweet this | Follow @proops

Comments Off

Contented Management

CMS fail: how not to implement a content management system

Envelope stamped with a fail

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.

Philippe Parker on Adoption, Atex | 9 April 2010 | Tweet this | Follow @proops

Comments (2)

Contented Management

Is my project management useful?

Delivery has been uppermost in my mind recently. My wife is expecting a second child but this one decided he doesn’t want to head in the right direction. Next week he’ll be “from his mother’s womb untimely ripp’d”. Consequently I’ve been thinking heavily both about caesarean delivery and about a number of projects which now share a common delivery date. If I were project managing this birth, I’d just be cajoling the baby to get into position but quite frankly wouldn’t be offering much value. Is this the same for web projects? Do project managers actually help and how can you get more out of them?

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:

Case 1: Dogbert the generic manager: Ted - We need more people on the project. Case 2: Dogbert - Figure it out. Work smarter not harder. Make a plan. Move some things around. Adjust priorities. Just get it done. Give me a status report. Case 3: Ted - That did nothing but make me hate you. Dogbert - I can replace you with someone who will pretend to be inspired.

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.

Contented Management

Does rationlalisation reduce cost?

It’s a fair assumption to make that some organisations haven’t procured their content management systems as effectively as they might have done. Poor procurement is particularly frustrating when it’s done with our money, i.e. by government. But government in the UK is steeling itself for a major cost-cutting exercise. The Transformational Government agenda is already well underway, seeking to reduce the number of government websites and streamline online services. Meanwhile the political parties have competing missions to rethink procurement, particularly of technology. You can’t argue with the idea, and as Ian Truscott points out, there are good reasons for reducing the number of websites from a user experience perspective as well as just costs. However, you can certainly question the approach.

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.

Philippe Parker on Government | 19 October 2009 | Tweet this | Follow @proops

Comments Off

Contented Management

Theatrical ways to improve project performance

I wish I could remember who wrote that in tragic theatre events start quickly but slow down as they draw to their inevitable conclusion, while in comedy the action start slowly then build up pace. There are definitely parallels with projects.

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.

Philippe Parker on 27 August 2009 | Tweet this | Follow @proops

Comments (1)

Contented Management

Why do projects cost so much?

Why do Enterprise Content Management systems cost about five times as much as their top-tier web content management equivalents? Do they offer five times as much functionality? Are they five times less likely to fail? Are they significantly more usable? Generally, not.

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.

Philippe Parker on 20 August 2009 | Tweet this | Follow @proops

Comments (1)

Contented Management

Three little tips to reduce huff and puff

My two-year-old son is pleased to live in a house made of bricks. It affords him protection from the Big Bad Wolf.

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:

Choose two high-value objectives; one that should be simple to achieve and the other likely to be complicated.
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.
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:

Philippe Parker on Fairy Tales | 15 May 2009 | Tweet this | Follow @proops

Comments Off

Contented Management

Lao Tzu, on agile development

Taoism tells us that it is practically impossible to understand the world fully. Everything we describe falls short of what it actually is, since our language is limited. We naturally want to see things as complete, but everything is part of a wider whole that we are incapable of relating accurately and completely.

The way to understand the world is through continual contemplation. We actually begin to understand by comprehending what we have not yet understood.
A waterfall approach to gathering requirements would therefore be anathema to a Taoist. How can you say a requirement is complete without understanding how it will be met, or indeed what it will look like once its complete, or if the requirement was correct to start off with?

Requirements, design and implementation are part of the same whole: what the project will deliver. Instead of engaging in a futile activity to capture every requirement before you move on to designing how you’ll meet them, you need to engage the whole team in assessing what a requirement really looks like tangibly in the target system. That means discovering the requirement, prototyping and reviewing through a series of iterations, until the feature meets its objectives. These are the principles of agile development.

The subtlety of individual requirements is almost impossible to capture in a strict, documented fashion. If you want to see your requirements met, rather than your project brief adhered too, a more contemplative and iterative approach is necessary.

Contented Management

Content management lessons from China: Sun Tzu

China is in fashion. The Olympics, with its spectacular opening ceremony, has brought the Middle Kingdom and its culture to the fore. So we’re going to hop on the bandwagon by looking at some of the better-known examples of Chinese thought and consider how they might influence on web content management (WCM).

Sun Tzu, on effective management

The Art of War was a favourite text for the Reagan-ite wannabe executive who viewed business as a perpetual battle. Yet effective management is rarely about deceiving others and taking control over their realm, despite what some departmental managers may think. Indeed, Sun Tzu stresses the need for delegation as a means to enjoying more control. Management is about delivering an end product.

There are five main obstacles to success:

recklessness: consider what impact your decisions will have before you enforce them;
cowardice: don’t be afraid to implement what you know is right;
hasty temper: don’t be provoked into arguments with stakeholders or suppliers;
delicacy of honor: you don’t need to appear all-knowing; recognise your weaknesses, be open about them and engage people to help;
over-solicitude for the team: people will be unhappy during the project, but if they see that what you’re doing is right, they’ll buy into the cause.

Successful implementations are about pursuing a common objective without having to appease people along the way. So delegate responsibility to your implementation team and ensure that they enforce your decisions for you.

Contented Management

PICKing the fishbone

So, you have your SWOT and your fishbone, now you need to prioritise your requirements.

There are lots of ways of doing this, but I think you’ll have gathered from my previous posts that I’m always keen to do things the simplest way possible and refine things from there.

Take all your requirements from the end points on your fishbone, and write them all down on post-it notes.
Hold a couple of rapid, 15-minute sessions with business stakeholders and ask them to stick the requirements to a flipchart sheet, with the most important at the top and the least important at the bottom, so you end up with a kind of requirements priority ladder.
Hold a follow-up session with the technical stakeholders who will need to deliver the project: designers, developers, project manager. Don’t tell them that the requirements are prioritised by importance (although they’ll probably guess). Just ask them to review the requirements and move them further to the right of your sheet depending on how time-consuming or difficult they are to achieve.
Draw a 2 x 2 grid around the post-it notes. The 2 x 2 grid is a business analyst’s cliché, but also a friend. The vertical axis is benefit and the horizontal axis is difficulty. You’ll end up with a PICK chart, shown below.

Requirements charted against benefits and costs
You should just implement the requirements in the top left of the grid. They’ll bring value and are relatively easy to do, so they should be in your project scope right away. Conversely, those in the bottom right should be scrapped as their value is questionable and they’re hard to do, so the business case will never be proven.

Requirements in the bottom left grid should be challenged. Just because we can do them, doesn’t mean that we should. What real benefit will there be for the organisation if we implement them? Won’t they just divert our focus from our main project objectives?

We may well implement requirements in the top right of the grid, however. We know from the outset that their implementation will be difficult and costly, but if we can prove their benefit then we shouldn’t rule them out. These requirements may involve some prototyping and benchmarking, but shouldn’t be excluded just because they’re hard to do.
If there are lots of requirements in the Possible group, you can always repeat the exercise just for those requirements and include only those in the top left. You should also retain a record of those requirements that were in the Kill group, as in future there may be more value in doing them and they may be easier to implement with changes to work practices or evolving technologies.

The advantage of the approach articulated in this and the previous two posts is that it’s relatively quick and simple, while retaining a focus on real problems and how likely you are to be able to solve them. Obviously, there are more refined approaches than this, but if you just need to get things done, this approach is worth trying.

Philippe Parker on 22 November 2007 | Tweet this | Follow @proops

Comments Off

Contented Management

Projecting failure

There are countless reasons why project fail, which you’ll doubtless be able to Google if you haven’t experienced them for yourself already. Poor requirements definition, lack of leadership, weak controls, over-ambition and poor communication are among the reasons cited. But the real reason that many projects fail is because they are projects.

They fail because they’re difficult; that’s why they’re projects.

You don’t create a project for things that you know are easy. Maybe if you started creating projects for each person to start-up their PC each morning, you’d have some impressive project KPIs… This isn’t about being flippant, however, it’s about setting expectations. You run projects to exercise some degree of control so that you understand when something will be delivered, at what cost and who needs to be involved in delivery. Other work can be written off as business as usual, but a project needs its own attention. So you already know that it’s going to be tricky, that you’re not sure how best to address the problem… why then do you think that by putting in some kind of methodology everything would be hunky-dory?

They fail because the controls you have in place tell you they’re failing.

What the methodology does provide you with are the controls to monitor the work you’re doing. You should be able to monitor effort, milestones, risks and then manage these. But more importantly, if things are going wrong, the controls should be telling you sooner rather than later, so you know your project is slipping. With business as usual where the controls don’t exist, you don’t know things are going wrong until it’s too late: for example, you’re losing market share.

So the fact that it’s a project means that it’s more likely to go wrong and it’s more likely to tell you that it’s going wrong. So why are we so surprised when it breaches tolerance?

It’s not about defeatism: we have worked on successful projects. But let’s challenge the expectations before the blame-storming begins. Could we have implemented the system without running a project? Did we get any benefits from running the project at all? What can we learn from this project that went well, that we can implement in future?

To run your projects successfully you need honesty, clarity and experience. The first step is to be honest, clear and experienced enough to recognise that it ain’t easy, and that decent project management will tell us just how tough it is.

Philippe Parker on 18 October 2007 | Tweet this | Follow @proops

Comments Off

Contented Management

Is it “what” or “how” that broke it?

A typical question I get asked when assessing failing CMS implementations is whether there’s a fundamental flaw in the product or in the way it’s been implemented. Some products are more difficult to implement than others, but businesses can be hasty in wanting to throw technology away when the implementation has failed to meet expectations.

While you can make any product do anything if you have an endless supply of time, money and ingenuity, it’s useful to have some idea about whether you need to throw your core product away to achieve your goals feasibly. So I thought I’d list a few typical warning signs that might prompt you to initiate a technology selection project:

Wrong technology stack — You’d have thought this would be obvious; but if you’re living in a Java world and you have a .Net, ColdFusion or LAMP product, you’re in trouble. This also applies to legacy systems coming out of support.
Unfriendly URLs — You could get around this with some clever rewrite rules, but it’s extremely tricky to do this in a really scalable and cost-effective way.
Incompatible workflow — If your CMS doesn’t allow you to implement your online publishing processes, you have a serious problem. Integrating a distinct workflow tool could be more trouble than it’s worth.
Running Active X components on a Mac — This is a way to alienate your user base. Don’t use anything that relies on Active X. Even if you’ve locked down all your editors’ PCs to use the same version of Windows, these components can be a headache. There’s plenty of tools out there that use cross-platform, browser-based technologies, so why give yourself this burden?
Auto-generated non-compliant mark-up — Many portals (including MOSS Sharepoint) provide you with default templates into which your content is published. Trouble is, they rely on HTML table layouts and JavaScript that are a long way off best practice for being well-formed and accessible. If this is important to you, it can take a lot of effort to fix. You have to weigh up this level of effort against the advantages the product gives you, or against simply throwing the tool away.
Poor security — A requirement that’s more obvious to some organisations than others. Some CMS (dynamic-delivery products tend to be more susceptible than those using static delivery methods) are prone to brute force attacks, so if you could be vulnerable to DDoS you should get this evaluated. You should also ensure that your product doesn’t suffer from SQL injections.
Lack of integration standards — If your CMS doesn’t work with your LDAP directory, you’re in for a world of pain…
Poor version comparison — As with workflow, does the CMS provide you with versioning and audit capabilities that match your business processes? If not, there are tools you can integrate with no little effort, but why wouldn’t you just pick a CMS that does all the red-lining and version comparison for you?

This isn’t an exhaustive list. What characterises these issues is that while you could address them with some outside-the-box thinking, the problem is likely to be so ingrained in the product that dumping your current technology is a more viable approach. And at that stage, when you look to select a new technology, all the points listed above should be the technical prerequisites you have when inviting suppliers to tender. During the selection process, you can then concentrate on organisational fit. This is a subject I’ll return to later.

But what if the reason your implementation is struggling isn’t listed above? It could well be down to the implementation. Most common things people blame on the product, but are actually a problem with how the product has been implemented are:

Performance — Hardly ever down to the product, in my experience. Can almost always be improved, if not completely solved, by improving infrastructure (not necessarily more licences) and information architecture.
Unfriendly WYSIWYG editorial interface — There are lots of free or cheap tools out on the market which provide friendly and standards-based ways for editors to add rich content to your CMS.
Poor classification systems — Products have limitations about implementing taxonomies and classification systems, but typically if you’ve trouble managing these in enterprise products, it’s more likely to be because of how you chose to do it rather than a fundamental flaw with the product itself. It may well require some bespoke work, but doesn’t mean abandoning your entire system.
Having to publish in multiple places to generate a single piece of content — This problem is more often found with component-based content management systems, such as Tridion and Percussion. Editors have to publish blocks of related content that then go through independent workflow processes only to be assembled on the same page. There’s an advantage that these are re-used elsewhere on the site, or translated into other languages more efficiently, but the big disadvantage is that editors are confused by what needs to be published in order to make one simple update. In my experience, the business blames the technology when it’s just down to how it’s been put together.

Hopefully this will steer you down the right path when you need to decide whose arse to kick: software supplier or systems integrator / design agency. But more than that, it should give you an idea about where to focus your energy for new requirements: do you need to run a technology selection project or can you build on the platform you have currently? We all know that things break, but if you know whether it’s the what or the how that’ll do it, you should be able to put some contingency in place, saving some blushes and some money.

Philippe Parker on Percussion, SDL-Tridion, SharePoint | 16 October 2007 | Tweet this | Follow @proops

Comments Off