Category Archives: Better Results

Timesheets: some observations on observation

Just as a throwaway in my post on understanding your team’s progress I said something like “everyone hates timesheets”. And it’s true, they do. They’re onerous, boring and they’re usually seen as invasive, “big brother”-esque, make-work. But, as I also said in that post, good quality time recording is vital to understanding what’s going on within your teams.

Feeling the need

We first started looking at timesheet systems nine or ten years ago when it was becoming abundantly clear that we weren’t making the progress we were expecting on certain projects, but we didn’t know why.

The teams were skilled in the tools they were using, they were diligent, they’d done similar work before, but they just weren’t hitting the velocities that we had come to expect. On top of that, the teams themselves thought they were making good progress. And every which way we approached the problem we were missing the information needed to get to the bottom of the mismatch between expectation and reality.

At that point in the company’s life timesheets were anathema to us; we felt very strongly they indicated a lack of trust, and in a company built entirely on the principles behind the Agile Manifesto… Well… You can see our problem.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

But however we cut it we really needed to understand what people were actually doing with their day. We trusted that if people thought they were making good progress then they were, but we definitely knew that we weren’t making the same kind of progress that we had been a year ago on the same types of project. And back then we were often on fixed price projects and billing by the day, so when projects started to overrun our financial performance started to dip and the quality of our code went the same way (for all the reasons I outlined in that previous post).

So we hit on Harvest (at the time one of the poster children of the burgeoning Rails SaaS community) and asked everyone to fill in their sheets for a couple of months so we could generate some data.

We had an all hands meeting, we explained exactly why we were doing it, and we asked, cajoled and bullied people into using it so that at least we had something to work on and perhaps uncover the problems we were hitting.

And of course we found it quickly enough, because accurate timesheets filled in honestly expose exactly what’s going on. By our nature we are both helpful and curious – that’s how we ended up doing what we’re doing. But helpful and curious is easily distracted; a colleague asking for help, an old customer with a quick question, a project manager from another project with an urgent request, the account management team asking “can you just…” And all of this added up. In the worst cases some people were only spending four hours a day on the project they were allocated to; the rest of their time spent helping colleagues and old customers… However, how you cope with these things is probably the subject of another post.
My point here is that once we had that data we realised how valuable it was and knew that we couldn’t go without it again. Our key takeaway was that timesheets are a key part of a company’s introspection and without good data you don’t know the problem you’re actually trying to solve. And so we had to make timesheets part of our everyday processes.

Loving the alien

Like I said; people hate timesheets. They’re invasive. They’re time consuming. They feel like you’re being watched, judged. They imply no trust. They’re alien to an agile environment. And the data they produce is a key part of someone else’s reporting, too. So how do you make sure they’re filled in accurately and honestly? And not just in month one, when you first introduce them, but in month fifty seven when your business relies on them and you may not be watching quite so closely.

We’ve found the following works for us:

  • Make it crystal clear what they’re for, and what they’re not
  • Make it explicit that timesheets are for tracking the performance of estimates and ensuring that progress can be reported accurately
  • It’s not about how much you do, but how much got done
  • Tie them together with things like iDoneThis, so that people can give context to their timesheets in an informal unstructured manner
  • Make sure that everyone who uses the data throughout the management chain is incentivised to treat it honestly – this means your project managers mustn’t feel the need to manipulate it or worse manipulate how it’s entered (we’ve seen this more than once in other organisations)

And Dan, one of our project managers, sends round a gentle chivvying email each evening (filled with the day’s fun facts, of course) to make sure that people actually fill them in.

[Photo by Sabri Tuzcu on Unsplash]

External agencies vs. in-house teams

As you’ll already know because you’re windswept and interesting; we record a semi regular podcast where we look into an aspect of life in a technical agency that we think will interest the outside world. We’ve just finished recording the latest episode about internal versus external teams and honestly I think it’s one of the most interesting chats we’ve had.

Joining us on the podcast are Andy Rogers from Rokker and Dan Graetzer from Carousel Group. Both Andy and Dan have tons of experience both commissioning work from internal teams and navigating the selection of external agencies. They were able to speak with clarity about the challenges that each task can bring.

One of the interesting things for me was getting a glimpse ‘over the fence’ into some of the thought processes and pressures that lead people to keep work internal – something that I’ve really only been able to guess at in the past.

Here’s a quick summary of things we speak about.

Agencies developing symbiotic/parasitic relationships with larger clients.

This tendency of larger agencies to act almost as though they are internal teams is becoming more and more common. There are upsides and downsides to this, obviously, in that while bodies like Deloitte et al can mobilise 200-strong dev teams, they also make it more and more likely that their customers will have to keep going back to them in future. (We discuss this subject mostly in terms of how Isotoma are not a larger agency!)

Good agencies are expensive but not as expensive as bad recruitment

The cost of hiring an agency for a given software project is likely to cost around the same as the annual salary of a developer and/or development team. Given this, it can seem galling for potential customers that they’re spending the right amount of money in the wrong place. We discuss how a good agency can help mitigate both the opportunity cost and assume all the tricky recruitment risk in the relationship. (Aren’t we nice?)

Continuous delivery shouldn’t necessarily mean continuous agency billing

One of the goals of any software project should be to build and develop the skills to support it in-house. If you’ve had a key piece of software in production for 18 months and you’re still relying on a third party to administer, fix or deploy it then you might have a problem.

Asking an agency to do something is the easy bit

Commissioning work with third party agencies is one step in a multi-step journey. This journey needs to include understanding how you’re defining your requirements, how you plan to receive it when it’s done and how you’re going to give the project good governance when it’s in flight.

Also there is a good deal of talk about werewolves

We’re not mega sure why.

Hopefully you’ll find it as interesting as we did. You can listen to the podcast and subscribe!

A blog post about estimating

First of all, a provocative but sweeping statement about the subject to kick us off: If your agency won’t talk to you about how they estimate projects then they’re either liars or fools.

You’ll have heard of Zeno’s Paradox. The one where a journey can theoretically never be completed because in order to travel the full distance you must first go halfway. And then once you’re halfway, you must then go half the remaining distance and so on.

The paradox is that in order to do something as simple as walking across a room, one must complete an infinitely regressing set of tasks. And yet, without wishing to boast, I’ve crossed the room twice already today and I managed it just fine.

Software estimation is a bit like that. If you analyse it closely you’ll see the tasks you have to complete multiply infinitely until even the simplest thing looks impossible and the budget is smashed to smithereens. And yet, as a company, we’ve got a track record of delivering on time and to budget that goes back years.

The various methods that we use are described in the episode of our podcast that this post supports (Why not go and check it out?) and we won’t go into detail here suffice to say that the process is always time-consuming and rarely problem-free.

So it’s hard. And prone to error. And time consuming to even do badly. So why do it?

The obvious answer – so you know how much to charge – is not actually all that applicable. More and more of the work we do on agile projects is charged on a time and materials basis. Additionally, there are a hundred good reasons why an agency might want to charge a price that wasn’t just literally [amount of time estimated] multiplied by [hourly rate].

No, the real reason that we put so much effort into estimation is that estimation is a great disinfectant. Everyone who works in this industry has a story about a project that went from perfectly fine to completely awful in a matter of seconds. Estimation helps us expose and resolve the factors that cause this horror: hidden complexity, differences of assumption, Just Plain Goofs etc.

It’s important to note though that even a carefully produced estimate can still be wrong and so the other key tools an agency needs are mature processes and procedures. You need to be able to effectively communicate how the estimate failed, assess what the impact of the failure will be to the broader project and, vitally, put all this information in a place where it can’t be forgotten or ignored.

This last step is effectively giving the organisation an institutional memory that lasts longer than 10 working days and it’s the vital step that ensures that by the end of the project the stakeholders can remember that there was a problem, see that it was resolved and how it affected timelines overall. Mistakes are always going to be made but the key thing is to ensure you’re always making exciting new ones rather than repeating the old ones.

All of the above is discussed to some extent in our Estimating podcast. Myself, Andy Theyers and Richard Newton spend around half an hour discussing the subject and, honestly, it’s quite interesting. I urge you to check it out.

“What CMS?” is the wrong question

When I meet new customers, I often relate a story about CMS work.

It goes like this:

A decade or so ago, CMS projects used to make up the majority of Isotoma’s output.
These days the number is much lower. There are a few reasons for this but the main one is that back in the day, CMS work used to be hard. The projects were complex, expensive and fragile.
As an illustration of how much things have changed, the other day I built a website for my sister’s business using Squarespace. It took longer for me to upload photos to the gallery than it did to plan, build, populate and deploy the entire site.

This peppy anecdote disguises the fact that there is complexity still in CMS work; projects that involve content management have the ability to stymie organisations and put their digital roadmap back years – but almost all of this complexity resides outside of CMS platform choice.
This post looks into why that is.

“What CMS should I use?” is a boring question.

People still tend to start with the question “What platform are we going to use?” because, historically, it’s been a really important one. Back in the day, progress was slow and the costs of being wrong were astronomically high.

These days though, compared to some of the other decisions you need to make, platform choice is a relative doddle.

Why do I say this? Because the CMS market is commoditised, modern and highly competitive.

  • There are free/open source solutions that are as good as (or better than) anything you pay through the nose for
  • There’s a huge number of agencies who will compete with each other for your business and this keeps prices constantly low
  • The majority of features you could ever want from a content management system are now standardised and distributed across the marketplace. Anyone telling you otherwise is selling you something
  • As features increase; costs shrink. As costs shrink, the traditional organisational worries about sunk costs and having a product that’s wrong become less important

Indeed from a given list of modern, open source content management systems, you’d have to be going some to get a bad fit for 99% of organisations.

So having made a broad and eye-catching statement like that, let me now run through a brief list of actual interesting questions to ask about your CMS project.

1. What is my content strategy?

Back in the day, agencies would be asked by their customers “Will the section headings be editable by admins?” and then we’d go to quite a lot of trouble to make sure that the section headings were in fact editable by admins.

What agencies should have been doing instead was investigating why the section headings needed to be editable in the first place.

If you nail the content strategy – if you develop content and a structure that speaks to the requirements of your actual customers – then the need to make structural changes to your site should be, while not removed entirely, at least put on a slower and more predictable timetable.

2. Who is driving this project?

This is somewhat related to content strategy but deserves its own section. One of the reasons that a content strategy is needed is that the fundamental question “Who is the audience for this site?” can have multiple, arguably correct answers depending on who inside the organisation you ask.

And sometimes the reason that you have multiple answers to the question is because two (or more!) departments or individuals within the customer’s organisation have competing opinions about the fundamentals of the project: what it’s for, what the outcomes and priorities should be… etc.

Resolving these tensions can be difficult, even for members of the customer’s team. For employees of an outside agency the difficulty increases exponentially but, worst of all is when an attempt is made to solve a problem like this with the top down application of a technology choice. Drupal has many skills but senior management negotiation is not one of them.

3. Who are the audiences for this new CMS?

Is this a site made to make the company look attractive to customers? Or is this a site that is designed to make an internal task easier for the admins of the site? Or both? None of these answers are wrong but failing to ask the question can result in tens of thousands of pounds being spent on something of little demonstrable value to the customer.

So in summary then…

Asking the above questions is a far better use of your time in the run up to starting a project than asking questions about Wagtail vs WordPress.

You can take this one step further and use the same approach in selecting an agency: When you first engage with them, do they talk about the platform and technology choice or about how they’re going to help you increase your reach, or implement a content strategy? Or how they’ll help affect change within your organisation?

Why the hell is my project over-running?

As a project manager, I rank a C+ at best. That’s why I work in sales where the damage I can do is more limited. However, where I differ from a lot of not-very-good project managers is that I know exactly how bad I am and am happy to share my hard won experience with you all. Lucky old you, eh?

The topic for today is the most-asked question in agencies up and down the land: Why is my project over-running and what can I do about it? (It’s kind of a companion piece to Andy’s previous post “How do I know my developers are on track?”)

One of the reasons why this question is so often asked is that it is a defining feature of so many digital projects. Managing overrun is often one of the key tasks of any senior management team within an agency. This blog post is an not an attempt to exhaustively catalogue all the reasons why it happens. Instead I thought it’d be useful to discuss some of the less discussed reasons.

Let’s start with an easy one:

The estimate wasn’t an estimate

There are as many ways to generate an estimate as there are uses for that estimate. All bodies will develop their own idiosyncratic approach and – fun! – multiple approaches to estimation can also exist within an organisation at one time.

This tendency often leads to confusion or amnesia about what the estimate was for in the first place. Two extreme examples here are an internal estimate of developer effort and an estimate of price meant for an external, customer audience. The developers might estimate, say, a 6 week build for a given feature At the same time, for reasons of political expediency, you might only want to charge for 4 of those.

There’s nothing necessarily wrong or even surprising about a calculation like that, but it’s vitally important that you have the organisational memory to remember that the devs need 6 weeks in the resource planning and reporting areas of your business. In a month’s time when you’re looking back on the project and reporting its profit/loss, what tools are available for you to track this information beyond your fallible, over-worked brain?

How much are you losing to churn?

There are countless posts on the damaging effect that context-switching can have on a development team. If you’re delivering work into a team of generalist developers who are having to switch from one project to another over the course of a day, then you’re going to be having an impact on productivity from the get go. I can think of countless examples from my day to day life where an hour of timesheeted development somehow managed to cost a whole day of my precious budget.

So we all instinctively know this – but what I see agencies do again and again is both fail to develop tools and processes to compensate for this tendency *or* build any of this into planning. Spending time and resource developing ways to automate the build/deploy process, for example, can save a ton of tooth-grinding right at the most stressful moment of the ‘task-switching’ process.

The only other solution is to plan projects sensitively enough that the plans take into account the workload of other projects and/or assign an amount of ‘dead time’ to a developer on the assumption that they’re going to be doing nothing profitable for a proportion of the project.

From a commercial point of view, this is a more or less indefensible position. From a practical point of view it borders on the hilariously implausible. (Show me an agency with a resource planning horizon of more than 4 weeks and I will show you the authors of the greatest work of fiction the world has ever seen.)

And speaking of which…

Your developers have an outside-context problem?

This is really common across the industry but is particularly true where you’ve got a team of middle-weight generalists – which is where dev teams in marcoms agencies naturally tend to gravitate.

The problem goes like this: The client asks for something new. You’ve never built it before but you’ve built something like it. The team diligently estimate the project based on the thing you’ve built before and everything is going fine until, suddenly, horribly, it isn’t. The differences that seemed so small from a distance are, up close, suddenly yawning and irreconcilable. This thing isn’t like the other thing at all. This thing is like nothing the team have seen before. It’s an outside context problem; outside the context of the team to estimate, deliver or support.

And now, not only are your estimates wrong, but you’re two thirds of the way through the budget and three quarters of the way through the allotted time.

There are a number of related issues here – and they really need to be unpicked in a longer post – but briefly it can be incredibly difficult to spot these things before you’re in their grip.

The short-term obvious preventative here is to review progress against budgets religiously and provide your teams with enough space and time to estimate properly in the first place, however there is a more long term and harder to spot solution too.

You need to foster an internal atmosphere where teams can feel both empowered enough to speak up when things are going wrong and can be sensitive enough to human weakness to know when “I don’t know how to estimate this” is the only correct answer.

In my experience, even senior devs can have a tendency to nail themselves to the crosses they manufacture in the project initiation stages. (I’ve seen management help make these crosses too.) In a healthy company there should be no need for this.

Get help

Watch now, reader, as I pivot effortlessly into an advert for my company’s services here: Mid-sized, mid-weight dev teams are, by their nature, prone to making the kinds of mistakes outlined above; it’s the downside of fast-moving, flexible team.

As a software agency of some 13 years age, we have seen pretty much all the ways that a digital project can go wrong and we’re happy to use this knowledge to help make sure that yours don’t. Our team of developers and project managers is experienced and mature enough to be able to give accurate, actionable advice that will be good for the duration of the project.

If you want to give us a shout email me, Joe or pop along to our contact page.

How do I know my developers are on track?

We’ve talked about how hard it is to estimate a software project on this blog before and – no doubt – we’ll talk about it again. Estimation is, after all, the fire in which all agencies are forged. In this post I want to talk about the other side of estimation: tracking the progress of the project against estimates. And not burndown charts; they’re only good if you’ve got good data. This is about generating good data. Then you can draw all the burndown charts you like.

All too often we find ourselves helping people who start our conversations with things like “It’s been ‘another two weeks’ for the last two months” or “I was sure we were on track until a fortnight before we were supposed to go live” or just simply “I don’t know when it’s going to end”

All of these are signs that progress tracking might not be up to snuff. And bad progress tracking is more than merely a frustration. More often than not it does serious damage to your relationship with the client, and over the long run it ruins the profitability of the agency. If a project is going wrong good progress tracking means you get early warning and hopefully it’ll give you the time to fix it.

So how do you get good tracking? We have a few pointers that have helped us out.

On ticket estimates: a third pass at estimation

Good estimates are hard, and hard is expensive.

Generally people we meet have a process that involves two goes at estimating. The first pass is done as part of the sales process, while the second happens during “Discovery” (or “Specification” or “Pre-sales” or whatever you call the process of nailing down the requirements). Up to this point it’s likely the customer’s not fully committed to the project and you’d struggle to get anyone to pay for three devs, a pm and a tester to sit in a room for two or three days to put together the estimates. Even though that’s what it actually takes.

Our advice? Instead of starting coding on day one, sit down with the entire team and break down your specification (whatever form it’s in) into tasks and subtasks in your ticketing system of choice and put a time estimate on each ticket. Also, mark these estimates with a confidence level. It’ll take a long time, but it’ll save you an age later, and crucially it’ll give you concrete numbers to track progress against as the project progresses. And those confidence scores will remind you when you’ve still got some hairy unknowns left to do.

“Done means done”

One of the tenets of Agile is done means done. But, a bit like Brexit means Brexit, what does that actually mean? If those tickets I described above are too big, or cover too many moving parts, then it becomes very hard to tell when they’re actually complete. And if it’s hard to tell when they’re complete, it’s going to be nigh on impossible to give an accurate idea of how much of the ticket is actually done. Make sure your tasks are small. Make sure they’re atomic. Make sure the acceptance criteria are concise and achievable. And encourage a culture of ticket completion.

A culture of openness and honesty

Talking about culture, let’s talk about openness and honesty.

Firstly, I know Hacker News and the like keep talking about “10x devs” and “ninjas” and “rockstars” and all that macho bullshit, but if your team has a culture where people can’t admit to being stuck then you’re never going to get an honest assessment of progress.

Secondly, make sure people are honest in their time recording (you do have a time recording system, don’t you?). Time sheets are boring and onerous and everyone hates them, but if you don’t have accurate time sheets then you literally have no clue what is going on. Put a time sheet system in place, make sure everyone uses it, and that they’re using it accurately. How you go about this is a challenge, but it’s one you’re going to have to overcome.

Take pleasure in mastery

Everyone wants to try the new shiny. But if every project is using a new CMS, a new framework or even a new language then estimates are going to be wrong, and people are going to genuinely struggle to know how close to completion they are. Specialise, get experience. Don’t reach for something new each time, however amazing that series of video tutorials made the thing look.

And I don’t mean this just for the developers, either. Project managers are just as susceptible to the new shiny. Decide on a process and tools. Master them. Take pleasure in it.

The MVP is not a myth

It’s your responsibility to get the shape of the project right. Make sure you tackle the biggest business benefits first. That way if the project goes adrift or the budget runs out there is a good chance that there’s some useful software.

And make sure you’ve got a plan B. If there are some genuinely scary parts to the project be honest with the customer about them and make sure that everyone’s signed up to a plan B if things don’t come off. Not every project deserves a formal risk register, but make sure you’ve got something in the back of your mind ready for if things don’t go as planned.

No silver bullets

Even if you do everything I outlined above there are still a million ways to lose track of a project. But… Each of them is incredibly valuable, and your projects will improve immeasurably if you can implement them.

Start ups: launching a marketplace

A year or so ago we signed up for a bunch of free Cycle Alert tags. They’re RFID tags you attach to your bike that ping a sensor in the cab of suitably equipped vehicles, warning the driver that a cyclist is nearby. We even did some truly adorkable PR to go with it. If we ignore the subtle whiff of victim-blaming it’s a nice idea; after all, who doesn’t want to be safer on their bike?

Twelve months on though, and it’s all fallen a bit flat.

Why? Because not enough cyclists have the tags on their bikes and not enough vehicles have the sensors installed. Like so many businesses the Cycle Alert model is predicated on making both ends of a market simultaneously, and therein lie some serious problems.

Your business is a different beast

Around half the start-ups that reach out to us for help have a business model that relies on taking a percentage from transactions occurring on their platform. The idea might be a new twist on recruitment services, or fashion retail, or services for motor tuning enthusiasts; who knows? But they share that same problem. Without vacancies on the site why would I upload my CV? Without CVs on the site why would I post my advert or pay a fee to search? Without beautiful shoes on the site why would I visit? Without shoppers why would I upload my beautiful shoes?

This isn’t to say that applications that rely on making a market are bad ideas, but they need treating quite differently. If your business is a straight product build you can pretty safely build an MVP (for your personal definition of M, V and P, obviously) and start marketing the hell out of it, but a marketplace of any sort needs more careful planning; it’s a marathon, not a sprint, and founders – and their funders – need to plan their resources accordingly.

What is your focus and what should be your focus?

There are a few things we see over and over again with this type of business idea. First up, founders regularly focus on trying to attract both classes of users at the same time. After all, you need both to start making money, don’t you? This can have a bunch of effects, but the two that are absolutely certain are that user numbers won’t grow as fast as you hoped and that you find yourself spread too thin.

At this stage more often than not our advice is to focus on one class of users and build secondary features that draw them to the platform before the marketplace is up and running. In the recruitment example get candidates on board with a great CV builder. Or get the recruiters on board by offering great APIs to publish to all the other job boards. One way or another you’ve got to get a critical mass of one side to attract the other and get the transactions flowing.

It can feel completely arse about face – and expensive – to be building features that aren’t core to your main offering, but unlike a product build you need a critical mass before you can start generating revenue. Like I said, it’s a marathon, not a sprint, and you need to look after your resources accordingly.

Are you doing the last things first?

Secondly, founders can’t help but want to build the core offering straight away. If the business model is selling premium listings for shoes then – obviously, right? – we need to build all the controls and widgets for uploading, managing and billing those listings… Haven’t we? Right?

Well. Not necessarily. See my point above. You need to phase your delivery, and when looked at through the lens of generating critical mass those widgets probably aren’t necessary yet. I know that you’ve got a limited budget and once the product is “finished” it’s those widgets that will be the core of you making money, but if you haven’t got anyone to use them yet perhaps the budget is better spent getting users on the site some other way?

A corollary to this is that, insensitive as I’m about to sound, it’s important to make sure your site is attractive when it’s empty. If your logged-out homepage is an infinite scrolling mosaic of tiles, each made up of images uploaded by your eager users, it’s going to look awful bare on day one. Getting the first dancer onto the dancefloor is your most important job; leave worrying about the layout of the bar until after you’ve got people dancing.

Don’t underestimate. It’s never as simple as you think

Thirdly, and lastly for this post, is the biggy. Everyone we’ve ever met has underestimated what it will take to get to critical mass. They underestimate the time, the money, and the sheer volume of changes they’ll need to make along the way.

I’ve said “marathon not a sprint” a couple of times already, so I won’t labour the point… But. Well, you know… Just make sure you’ve got access to more than you’re currently planning to spend.

Your goal here is critical mass, so alongside user acquisition your focus has to be on user retention and reducing churn.

Make sure you’re swimming in analytics, analytics, analytics. These will tell you what your users are doing and give you real insights into what’s driving uptake (and drop off). And be responsive to your users’ behaviour; be willing to change the offering mid flight.

Finally, make sure you’ve got the marketing budget to keep plugging away. You’re going to need it.

We’ve got a ton of experience helping web businesses get from first idea to funding and sale, and we work in every which way, from short term advisory roles through to providing an entire team. If any of what I’ve said above rings true give us a bell; find out how we can help your business take off.

When to WordPress; When not to WordPress.

We like Postlight. They’re really good at talking about the reasons they do things and exposing these conversations to the world. In Gina Trapani’s recent post (Director of Engineering at Postlight), she gives some really useful advice on when and when not to use WordPress.

I thought it’d be useful to delve into this topic a little and expose some of the conversations we’ve had at Isotoma over the years. We’ve done a lot of what you might call ‘complex content management system’ projects in the past and, as a matter of policy, one of the first things we do when we start talking to potential customers about this kind of thing is ask “Why aren’t we doing this in WordPress?”

This is one of the most valuable questions an organisation can ask themselves when they start heading down the road to a new website. Trapani’s excellent article basically identifies 3 key reasons why WordPress represents excellent value:

  1. You can deliver a high number of features for a very low financial outlay
  2. It’s commoditised and therefore supportable and by a large number of agencies who will compete on price for your business
  3. It’s super easy to use and thus, easy to hire for

Complexity issues

For us though, there’s a more implicit reason to ask the question ‘Why not WordPress?’
The more customised a software project is, the more complex it becomes. The more complexity there is, the more risk and expense the customer is exposed to. Minimising exposure to risk and reducing expense are always desirable project outcomes for everyone involved in the project – though that’s rarely an explicit requirement.

So all of a sudden, just understanding these issues and asking the question “Why aren’t we using WordPress?” becomes a really valuable question for an organisation to ask.

Good reasons not to choose WordPress

Through asking that question, you’ll discover that there are many valid reasons not to use WordPress. I thought it might be illuminating to unpack some of the most frequent ones we come across. So I thought back to projects we’ve delivered recently and teased out some reasons why we or our customers chose not to use WordPress.

1. When the edge case is the project

If you overlay your CMS requirements onto the features WordPress offers, you’ll almost always find a Venn Diagram that looks a lot like this:
wordpress-Venn

The bits that jut out at the side? That’s where the expense lives. Delivering these requirements – making WordPress do something it doesn’t already do, or stop doing something it does – can get expensive fast. In our experience, extending any CMS to make it behave more like another product is a sign that you’re using the wrong tool for the job.

In fact, a simpler way of thinking about it is to redo the Venn diagram:

wordpress-venn-02

If you can cut those expensive requirements then fantastic. We’d always urge you to do so.
But ask this question while you do:

What’s the cost if I need to come back to these requirements in 18 months and deliver them in the chosen platform?

  • Is it hard?
  • What kind of hard is it?

Is it the kind of hard where someone can tell you what the next steps are? Or the kind of hard where people just suck their teeth and stare off into the middle distance?

The difference between those two states can run into the thousands and thousands of pounds so it’s definitely worth having the conversation before you get stuck in.

If you can’t get rid of the edge cases; if, in fact, the edge cases *are* your project, then we’d usually agree that WordPress is not the way forward.

2. Because you need to build a business with content

We’ve worked with one particular customer since 2008 when they were gearing up to become a company whose primary purpose was delivering high quality content to an incredibly valuable group of subscribers. WordPress would have delivered almost all of their requirements back then but we urged them to go in a different direction. One of the reasons we did this was to ensure that they weren’t building a reliance on someone else’s platform into a critical area of their business.

WordPress and Automattic will always be helpful and committed partners and service providers. However, they are not your business and they have their own business plans which you have neither access to or influence on. For our customer, this was not an acceptable situation and mitigating that risk was worth the extra initial outlay.

3. Because vanity, vanity; all is vanity

There is nothing wrong with being a special snowflake. Differentiation is hard and can often be the silver bullet that gets you success where others fail. We understand if there are some intangibles that drive your choice of CMS and broadly support your right to be an agent in your own destiny. You don’t want to use WordPress because WordPress is WordPress?
Congratulations and welcome to Maverick Island. We own a hotel here. Try the veal.

Seriously though, organisational decision making is often irrational and that’s just the way it is. When this kind of thing happens though, it’s important to be able to tell that it’s happening. You should aim to be as clear as possible about which requirements are real requirements and which are actually just Things We Want Because We Want Them. Confusing one with the other is a sure-fire way to increase the cost of your project – both financial and psychic.

If you want to know more about migrating CMS’ and the different platforms available, just contact us or send an email to hello@isotoma.com. As you can probably tell, this is the kind of thing we like talking about.