HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


On the opening up of business models

On the opening up of business models (It seems I am able to squeeze another update into 2015 :D)

Over the years, I've become convinced that the web design market is fundamentally broken. The web has advanced at an incredible pace and I don't think the processes the vast majority of developers follow are fit for purpose any more.

Broken processes

You can't just have a chat with someone about a project, write a specification, cost it out, implement it, and deliver it. More than a bit has been written about agile development, but actually I think at every point (not just development) this process is broken.

Those that do write about agile development are typically in situations where they aren't working on contract jobs – they are instead on permanent staff (either direct employees, or effectively operating as outsourced staff), so their ideas about development don't need to play well with contractual issues and fixed budgets.

Let's break it down…

Have a chat

It used to be you could have a meeting and get to a decent understanding as to what a project would entail. But I no longer think this is true. I think things are now so complicated that any client of a web project (who doesn't have a lot of recent experience) will need to do a lot of background learning.

For example, here are a few of dozens of issues that need to be considered:
  1. What is the best mobile strategy? Mobile mode, responsive, native apps, some combination? The answer is not simple.
  2. What social channels will be exploited, and how? Who is going to create all the social accounts and their cover art, and do social media management? How are things going to be integrated with the website?
  3. Will there be multi-variate testing to optimise the user experience on a continual basis?
  4. How much ongoing search engine performance testing be done? What are the key objectives (e.g. search terms) that are being targeted?

These aren't something you can just ask in a meeting, each requires some intimate knowledge and a lot of careful thought. They certainly can't be done by a salesman in phone calls.

This could be achieved over a series of workshop-style meetings, a particularly detailed and well thought-through proposal by the developer, or otherwise providing some kind of structured approach where the client can look at every factor relating to the project with proper time consideration.
This can put a lot of pressure on the developer and are therefore nearly impossible in a competitive bid environment, due to the high cost and risk of such a large amount of pre-agreement work.

Write a specification

As with the pre-specification analysis, this is very costly when no quote has been agreed yet.

It is also almost certain that the specification will become a massive treatise and hence almost impenetrable to most clients. There's just too much to say. Because of the need to be efficient, lots would always get directly pasted in that would be little more than waffle. At this point style starts to win over on substance, so vendors that have made things pretty, but not done proper analysis, have a distinct advantage.

Cost it out

When there are dozens of peripheral tasks beyond just the main web development, costs can totally run out of control. It's not unreasonable to say that 19 times out of 20 the cost may be substantially higher than the client had in mind. Already at this point the developer may have spent thousands of dollars in lining up plans for their client, which might be their entire budget already spent before anything is designed and any code is written.

Implement it

The majority of customers want a fixed quote for a fixed specification, and hence a true agile process with minimum viable product doesn't quite apply. So now you get at least some of the problems of "waterfall development" that have been extensively-written about. Scope creep, things taking longer than expected, commitments to things that may now obviously not be making sense, things changing around you as you work, and so on.

Deliver it

Okay, but does it stop there? In most cases the client will think so, because developers haven't educated them on what their successful competitors are doing (with their teams of full-time on-staff developers).
On most projects you are likely to get waves of feedback from users, and a need for constant testing and tuning. This is before wanting to do new phases of development, or redesigns to move with the times.

The typical buyer of web services doesn't know any of these pitfalls, or all the things they should probably be doing and thinking about, meaning that the situation is 💩 for them and they don't even know it.

The solution

To solve this effectively, I think you need to first divide commercial clients into a number of categories:
  1. Clients who simply can't afford what they want if it is done to modern standards, so need to go home and have a think, then come back starting a lot simpler
  2. Clients perfectly capable of assimilating all the knowledge if things are properly organised and streamlined for them
  3. Clients who need to have a serious of physical meetings, and to some large extent have the developer lead the way – but the client can pay for it all (local agency rates for their area)

On this basis, ocProducts (my company) is entirely changing their approach with the Composr relaunch. The current model we have (and everyone else doing an online-focused agency has) doesn't meet the needs of 1/2/3 well at all. The need for a reinvention is yet another reason why we are taking so much time to do a complete relaunch – just as ocPortal needs a reimagining for modern times (and a cleanup) – our business needs a step change in how we approach things.

Let's consider each of the cases above, how they happen now, and what will happen with the Composr relaunch.

If too cost is too much

I think right now people would see our product and think, "yeah, it saves me money, I can do this!", but they miss things because we're explaining a product, and not the market as a whole. We have always tried to provide a holistic approach to things, but we stop short of explaining everything about web development agencies, everything about maintaining a website outside primary development, and the web development market.

Follows on…

If learning is needed

We need to provide far more guidance. People may see it and realise that things are too hard, or they might read it and learn what they need for massive success. Some people may have personal success (running their own modern agencies), and some may just learn how to buy services better for the success of their own website(s). Any way it goes, we have to be real and reflect how things have to be done right, not allow a situation where people can only see a part of the picture. Things have moved on a long way – the industry has matured, and quick and simple isn't such an option anymore. It's hard for people (including me), given we all started as enthusiasts, but reality is reality.

Markets evolve:



I am not beating myself up here. My belief is that web development resources universally now don't reflect the reality of modern web development. We need to take some responsibility to correct that.

I also want to be clear, no adjustments we make to how we handle things at ocProducts are going to change our mission to make a product for everyone. I am always ecstatic for people to use ocPortal for their personal home sites and that won't change. But clearly modern commercial websites are a million miles from that.

I have spent considerable time tearing apart half a dozen internal documents built up over a decade, and brought together advice we had strewn around, into a new briefing system for people wanting to contact ocProducts regarding some kind of task or work:
https://github.com/ocproducts/composr/blob/master/pages/minimodules_custom/contact.php
Questions have been streamlined as much as possible so that people get a succinct, organised, and clear view of what needs to be thought about (much better than it ever was before), and so that we can have a much clearer picture of what anyone wants when we are talking to them.

It won't suit everyone, hence the next type of person…

If many meetings are needed

Then frankly ocProducts should not be the primary agency in these cases. This is the majority situation I believe. If a client in Bolivia is creating a website then nobody from ocProducts is likely to keep flying out there (and let's not pretend video conferencing is a proxy for real meetings). Even if we did fly out there, the GDP per capita in the UK is 15 times that of Bolivia, and that's not atypical for most countries – we're too expensive for them.

This probably sounds like crazy talk for a CEO, why would I want to down-sell my own company's services?

Well, many reasons:
  1. I care about ocPortal/Composr far more than I care about ocProducts or my own needs, and always have. We don't have external investors to please.
  2. I care about people too, and I want them to be as successful as possible.
  3. Openness goes to the heart of my soul.
  4. Embracing reality is almost always the best approach – if you are true to facts and true to yourself, good things follow.

ocProducts' expertise and the goodwill we have earned, is our main selling point. There is no reason we can't encourage other companies to take on Composr projects as the primary agency, and then have things come back to us from these skilled areas in particular areas where the very greatest expertise or centralised effort is needed. And, we will always easily win work from US/UK companies with money. It's almost too easy for us to win over enterprise work nowadays, we have had to be pushing back against it. Besides, 2015 has shown just how much ocProducts can get bogged down when we take on major projects, yet another reason for spreading out the opportunities.

Yesterday I finished committing some major changes that reflect our new approach. These changes reflect the plan to keep being more and more open. Note that "open" doesn't only mean releasing free stuff and telling people what they want to hear, it means being real and giving actual information to people to help them make an informed decisions.

There has been a massive information dump of expertise in running projects and an agency:
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_minimum_viable_products.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_marketing.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_developer_relationships.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_choosing_a_developer.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_pricing.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_project_management.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_running_agency.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/sup_complex_projects.txt
https://github.com/ocproducts/composr/blob/master/docs/pages/comcode_custom/EN/tut_software_feedback.txt

This will really help both suppliers and buyers. Mostly this is restructured and recycled from previous blog posts and internal guides developed over years – but also it has been done very carefully to make it as accurate, well structured, and readable, as possible. "Advice & Guidance" will be a major category within our v10 documentation.

If we take a step back and remember we are a CMS product, it does seem a bit crazy to be disseminating and maintaining this much information. However I firmly believe that doing whatever we can do to help people makes Composr a better product. Actually I'll be stronger: it's critical, you can't effectively use a tool like Composr without having the information you need to make informed strategic decisions, and because nobody else is putting this stuff out there, we must be the ones to do it.

We are changing the perception of ocProducts being "the Composr company", to ocProducts being thought of as just the primary project sponsor. Many changes have been made throughout our copy and documentation to reflect this. We're not planning on running Composr with a foundation like other projects do though, because I honestly I still think that that's a poor approach (committee-rule is a terrible thing).

How it will work

However it does work, empowerment is at the centre of it. Maybe someone from Bolivia comes along, and fills in the new briefing system and specifies they want a local agency (we have a question for that). They may not fill in all the briefing questions with detail, but it's enough for us to then pass onto a company within their country. We make ourselves available to that company for subcontracting, and we make our huge amount of guidance to that company. This creates global opportunity, goodwill all round, possible work for us, and new incentivisations for growth (e.g. new maintainers of language packs).

Everywhere we can we are streamlining and simplifying, just as the ocPortal/Composr product is streamlined. Instead of having 5 ticket priorities we're just going to have 2, and we'll add a new "staff secondment" option for people needing ongoing work (which will also help our cash flow, honestly).

It's all about finding the best way for us to combine our centralised planning (to create a very consistent and clean product and ecosystem), with the openness and opportunities needed for everyone to want to join the party. Through all this we "create a new possible" and the world moves forward :).


Happy new year!

Chris :wub:

View all

Trackbacks

There have been no trackbacks yet

Edited