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:
This document describes and provides plans 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.
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:
This will likely be a trial by fire and difficulties are bound to arise, but it's preferable to zero progress.
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.
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.
|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.|
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.
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:
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.