User Tools

Site Tools



Technical Devolution (project cancelled)

Phase A: Content Management


This is the first of two phases, A and B, for devolving the technical responsibilities for The National Association of Writers' Groups. To recap, the phases are:

  • Phase A: Content management: devolving responsibility for managing the content of the website.
  • Phase B: Technology management: devolving responsibility for managing the systems and software for the website and other information technology.

This document describes and provides plans for Phase A.

Goal for Phase A

By the end of this phase, the website's content should be able to be managed by a number of people, rather than a single individual with particular technical skills.

Revised Approach

Important: Due to insufficient interest in this project, it is in a stalled state. For this reason, there's going to be a change in approach, as outlined below.

The project plan in general seems sound, so it will not be broadly altered unless the need arises.

The main issues are the lack of stakeholders and lack of motivation. The following measures will be taken to address this:

  • Kevin will no longer be responsible for any website content, with the following two exceptions:
    1. The “100” competition, which is too technical for beginners to handle.
    2. The writing groups directory, for similar reasons.
  • This means the remaining stakeholders, along with anyone else who cares, will need to deal with website content.
  • Kevin will continue to provide technical support for systems, software, backups, email and the like.
  • Kevin will provide help and support for new content managers, where he can.
  • Pam will not be a stakeholder, as she's also stepping down and devolving her responsibilities.

This will likely be a trial by fire and difficulties are bound to arise, but it's preferable to zero progress.

Next Steps

These will need revising in the light of the revised approach, described above.

These steps, although initially sequential in nature, will be done in parallel where possible.

  1. Make this wiki available to staff.
  2. Allow time for reading and absorbing.
    • Collect any initial feedback.
    • Correct any large errors, e.g. approach/methodology problems.
  3. Generate ideas for initial methods of discovery. Some initial thoughts are:
  4. Plan the first iteration A01 – probably mostly discovery and requirements gathering.
    • Form a team of people to work on A01.
    • Approximate time scales.
  5. Carry out iteration A01. Details to be discussed, but probably along the lines of:
    • Identify barriers that currently deter or prevent content management.
    • Devise ways to break down or overcome these barriers.
    • Create tasks to address these.
  6. Document specifications, based on the findings of A01.
  7. Plan further iterations.

What's Content Management?

If you think content management is just about editing a few pages, you might be in for a surprise. There's a lot more to it than that. Please see the content management page for more information about what's involved.


Here are some general preferences for how we go about the project.

Agile over prescriptive: allows us to be more responsive to changes, rather than taking forever.
Collaboration over one-way communication: ensures we stay on track with what everyone wants, rather than one dictating the way.
Constant involvement of stakeholders: enables early discovery and feedback, rather than late delivery of an unwanted or unsuitable solution.
Parallel activity over "waterfall" process: avoids bottlenecks and lengthy delays due to dependencies.
Iterative delivery over fait acompli: allows us to quickly respond to mistakes and changes in requirements.


Here are a few concerns I have with phase A and with the project in general.

Concern Description Possible Remedies
Lack of stakeholders Not enough people on the project could mean we end up providing a solution that's tailored for particular individuals, rather than suitable for all. If this were to happen, then we'd not be any better off than when the website and technology were the remit of just the current technician. Wider recruitment – invite from the membership as well as staff, even if only during development and testing.
Lack of involvement If people aren't sufficiently motivated and in the loop, then it could mean we provide a solution that's suitable for nobody. Rewards? Wine? Ice cream?
Too much work The amount of development, refactoring, testing, documentation and training, that Kevin is tasked with, in order to achieve the goals of this project, may turn out to be unmanageable. Devolve this work as well. Somehow.

Parallel Activity


This is where we work together continuously to find out what's actually needed, rather than what we think we need. Learning by doing, to my mind, is the only sensible way to gather our requirements and come up with specifications for what to work on.


In many ways, documentation plays an important part of this project. Not just the documentation of the project itself, but general documentation about how to manage content for the website, so that people in the future can learn how to do it.

It's imperative that we document things as we go rather than after the fact. In my experience, “document later” very often means document never.

With this in mind, I'm attempting to evolve a website manual alongside this project. As others get more involved, they can contribute to the manual too.

Learning & Training

Making the software and systems easier to use will hopefully minimise this, but the stakeholders of this project phase will need to learn things. There may be many ways to go about this, which are not mutually exclusive, for example:

  1. Learning by doing.
  2. Learning by reading documentation.
  3. Learning by training.

Unless the first one one the list is predominantly successful, then this could mean a great deal of work for the current technician to write the necessary documentation and devise and provide the appropriate training methods and material. This gives rise for another thing to add to the concerns for the project.


This provides us with clearly understandable definitions for what we need. In terms of project documentation, the specification may provide a focal point for what we work on.

Having said that, it's important to remember that we want an overall agile approach to the project, rather than getting stuck on the specification details – a symptom sometimes referred to as analysis paralysis.


This is mainly for me, to help with the implementation of the project. However, I'll try to document things here, for those who are technically minded.

A more important aspect, will be to document the overall website design, rather than just the changes needed for this project. This will probably be more important for phase B, but some aspects may be helpful for content management as well.


This is where I get on with things and get the website in a more usable state, in terms of content management.

Don't forget that this will be done in incremental, iterative steps. Don't expect it all at once.


This needs to be done by as many people as possible. The reasons should be obvious.

It's important to be aware that development and testing will not be done on the live website, so as not to disturb things there. Instead, the test website will be used.

Note: when not in use, the test site will automatically redirect visitors to the live site. If this happens, it simply means that no testing is currently under way.


This is where approved changes are rolled out to the live website. Again, this will be done in incremental steps, as the project proceeds.

projects/devolution/phase-a.txt · Last modified: 2018/07/05 15:31 (external edit)