Paper publications, Web publication, Roles and Project Management
In a previous post I touched on how web development has a lot in common with software development. In ‘development’ I am talking application development, site design, layout, etc. The roles in software development are well documented but why would you apply them to web development? Especially when we are talking content. After all a web page is an ongoing project, it has nothing to do with project management since there is no beginning or end.
Publication Process
Content publication on the web, or web site development for that matter, is no different than paper publication except that with the web you do not have the commitment of paper. For example the Daily Bulletin (DB). The DB has a daily publication schedule that requires the editor to go through a ‘project management’ exercise daily to ensure the publication appears on time, accurate, within budget, and complete.
The process the DB goes through is essentially similar from the paper publication it grew from, the Gazette. The Gazette had a weekly (later bi-weekly) publication schedule that was a ‘project management’ experience repeated along the publication process. There is in fact a clear project process except we add a one other ‘advanced’ step – rebirth.
The roles in a weekly paper publication (Gazette):
- Editor,
- Writer(s),
- Pagination,
- Graphic Artist,
- and printer.
Then you have to think about distribution.
The roles in a daily web publication (Daily Bulletin):
- Editor,
- Writer,
- Page design/layout,
- Graphic Artist,
- Server admin,
But you don’t have to distribute it, just upload new material and update a link on the homepage.
Name a publication, paper or web, and you will see these five core roles being taken on by anywhere from one to x-number of people. If you don’t you likely see obvious problems with the publication – more likely with web sites.
Creeping Scope
Scope changes can throw a project into turmoil. What is know as ‘scope creep’ plagues many web pages for the simple reason that a web site was initially designed based on the content and requirements placed on the site at the time a ‘web site (re-) design’ had taken place. But since then the content has been added to, new content created, and maybe even the audience has changed. The web site’s architecture is now stressed, images are dated, information may be misplaced or lost or not properly classified, and technology changes could be leaving the site with inconsistencies.
An unknown is when to update your site in order to fix these problems. The Internet is too young, technology changes too rapidly, and the audiences’ needs are in constant flux. There are also legal responsibilities such as accessibility or privacy to take into consideration in many cases.
Why don’t we see this problem in paper publications?
With paper it is really easy to see the start and finish of a publication cycle – when the paper is printed it’s over only to start again (rebirth). I am not just talking newspapers either. On campus we have many publications like the course calendar, We’re Waterloo, Waterloo Alumni Magazine, Keystone Campaign newsletters, view books and other recruitment materials, and many more. All of these have obvious project/publication teams and a process that is followed. Some are better than others at this process but they all have a start-finish-rebirth cycle.
Publication and design cycles
I should mention that there are two clearly different cycles in paper publication as there should very well be for the web: publication and design. With a publication cycle you are looking strictly at content and its layout within a given template. In design you are looking at changing the template from logos to colours to paper to fonts. That is design. On the web it is pretty much the same thing from code to logos to colours to fonts.
Publication and design cycles vary but often in news papers you see subtle changes over time that if you look at a paper five years ago you really notice. On the web it can happen in a blink of eye that can result in massive user interface changes which is not ideal but is really the norm currently.
Road to improvement in 3 steps
The first step is let go of the thought a web site can be perpetually updated but the content layout never needs reconsideration. When a site is never updated I like to say it suffers from ‘drop down syndrome’ where new content is simply stuck in categories that had been labeled years before and don’t really fit, often drop down menus.
The second step is identifying a publication process. If you update content in sync with a paper publication then you have a process but you have yet to acknowledge it. Formalize the process, identify what content will appear on your site, who is responsible for it, when you expect it to be updated again, and why is the content there in the first place? Just because you can update your content right away, do you really need to?
Web project roles that are recognized by the industry include (From Web Redesign – Workflow that Works by Kelly Goto & Emily Cotler);
- Project Manager – Organizes the project from start to finish.
- QA Lead – Takes care of Quality Assurance, identifying and squishing bugs as they appear. Responsibilities include building a test plan and checking browser compliance, HTML, and content placement.
- Information Designer – This person develops the site map and structures the way content navigation is laid out on a page – all of this in a non-design-oriented manner. The information designer defines site navigation, functionality, and user interaction.
- Usability Lead – The usability lead gathers firsthand information about how users actually use a site and analyzes what works and what doesn’t.
- Production Lead/Production Designer – The production lead heads a team of HTML production designers to facilitate HTML production and testing, while keeping an eye on scope and schedule at all times.
- Copywriter/Content Manager – Expert in web-specific writing that includes style and tone.
- Art Director/Visual Designer – Basically does the stunning graphics that are found on the site.
- Programmer/Backend Engineer – This person worries about the server side code and architecture.
In web projects, any team member depending on the size or scope of the project often takes on more than one role. Very few universities have people assigned to these roles at the time of this report. The ones that do often are found inside medical schools or other specific departments.
The third step is to ask for help. There are a few web experts on campus and even more project management people around that can offer advice. I would also recommend talking to people involved in publication of paper-based projects. Communications and Public Affairs have decades of experience to share with those interested. Remember publication is not a new just the medium has changed.
I would like to encourage some discussion on this topic so please send me an email or comment below.
