We’ve started working on an intranet for a government agency. As with most redesign strategies, the basis for the project is to improve the site. In a 21st century world, though, with Agile and UX being so popular, is there anything we can apply to this fairly straight forward project?
When it comes to redesigning a website, whether its an intranet or internet project, content and its migration presents the biggest challenge and greatest risk. Using Agile (Scrum) and Lean thinking, we’ve decided that we don’t need to migrate all of the content in one go.
Applying Agile & Lean to Content
Agile methodologies like Scrum require that you create an order in which to deliver features and functionality to users. Of course, with a new website, there’s a minimum required before you can potentially go live. The same can be said for the site’s content. Not all the content needs to be there from day 1, particularly given much of it is out of date, poorly written, and needs re-work. The question, though, is how to decide on what content to migrate?
- Understand what content is currently used the most – The website’s statistics can tell you this. We discovered that about 90% of the traffic was attacehd to about 10% of the current intranet’s content
- Understand what content isn’t often used, but is important to your organisation and the website’s users – We noted that there was an amount of content that needed to be accessible for legislative and policy reasons. There are, though, other knowledge and information repositories in the organisation, so we made the conscious decision that if content wasn’t in the ‘most used’ category, then we would store it in the agency’s recordkeeping system.
- Rank that content from most valued to what is less valued – We then applied the rules of Scrum and created a nominal list of content from the content item that would be worked on first and migrated to the new site, and then the next most valued, and so on.
Ranking and Value – but everything is a priority!
One of the hardest things I’ve found to get people out of the habbit when teaching them Scrum is that rank doesn’t equal priority. This seems to be because of a mentality that everything is priority #1 insofar as the business users are concerned. This entrenched behaviour then forces them to make decisions about what features in a software project are ‘nice to have’ and what are ‘mandatory’ the result of which is trying to cram everything possible into the mandatory category. In leveraging Scrum, though, we’re forcing people to re-evaluate content simply an order of delivery of content — what content do they want now, next and then later — based on what they value most.
The factors that we’re using to contributie to the rank of content are:
- Frequency of use
- Relationship to policy
- Relationship to legislation
- Usefulness
- Desirability
Moving something when it’s important to do so
There’s bound to be content that is important that people have forgotten about because its just too hard to find in the existing intranet. Once the skinny solution for the intranet goes up within an 8 week period using Scrum, we’ll then assess what demand there is for additional content, and add new content as its required, until the end of the project. At that time, if additional content is required it will be the business area’s responsibility to find it and put it up on the intranet.
Continuous improvement
To keep away the biggest problems of the current intranet — i.e. outdated content — we’re introducing activity-driven feature sets. In plain-English, these are the social tools you see on blogs and wikis. Not everyone will use them, but given the Forrester technographics data we know that Gen-Xs and Gen-Ys have about a 30% behavioural tendency to create, comment, review and critique content. These tools will provide these keen individuals low-barrier mechanisms to assist content authors keep their content current, or at the very least, give people a mechanism to ask the question of its producer.
Conclusions
Applying Scrum and Lean thinking to content migration has turned a 100,000 content nightmare into something that can likely be migrated by hand in only a week. This has significantly reduced the project’s risk profile and, of course, the time in which we can deploy a skinny solution to the organisation. It’s an approach I’ll definitely be recommending to our clients next time.
M
