This is the second in a short series of articles exploring my current state of thinking around implementing learning technology solutions.
In the first post, I looked at the scoping & kick-off stages – the essential foundations for a successful project.
This time I’ll focus on the “Project setup” stage. This is a piece of housekeeping that is often forgotten in the rush to get started building something. It includes:
- Agreeing the quality standards
- Setting up the project infrastructure infrastructure
- Defining what will be done first
I’m using terms that come from Agile development practices, but don’t let that put you off… Even if you’re using other project management methodologies these ideas should still be applicable.
Agree definition of user story ready
Whether you’re defining all the software requirements up front, as per the typical “waterfall” project, or defining them as you go in an agile project, you will still need to document how what needs to be done.
These are your user stories.
Ideally they would contain an overview of what should be created from the user’s perspective, and then some detail which provides enough information to be able to do acceptance tests.
For example, the overview statement might be:
As an administrator, I need to be able to allocate users into groups so that I can efficiently manage who is doing which course.
And the subsequent detail might then be:
GIVEN that I am logged in as an administrator
AND some users exist
AND a group exists
WHEN I add a user to a group
THEN the group records the new user without errors
This (highly stylised) example is an illustration of the Given-When-Then pattern, which is designed to help write requirements that can be easily tested against.
User stories like this often benefit from screen designs or mockups to help the developers.
The key thing at this point is to agree what quality will be expected for the user stories. What level of detail will be required?
Agree definition of task done
In a similar way to defining how you know a user story is ready, you’ll need to agree how you know a task has been completed, the definition of done. It’s not just about saying something is finished, it’s about making a statement that the task has been finished to a certain standard.
The definition of done sets that quality standard and should be published and known by all team members.
Agree definition of ready for release
Often this is called the definition of done done. It means that all the functionality is in place, the user interface has been fully built, it’s been through unit, integration, accessibility and systems testing, there are no blocking bugs, the documentation is complete etc.
Again, those quality standards should be published and accepted up front.
Setup visual management board
OK, not everyone will use visual management boards to run their projects. In traditional environments, you’ll most likely still find the project managers use Gantt charting software like MS Project or Merlin. These are incredibly powerful pieces of software, that do far more than just the basic visualisation of a project. They also help manage resourcing and budgets.
However, in a fast moving environment, you’ll often find that a visual approach to management works best:
- Save time by simplifying the complex – Visual management helps people understand complex information at a glance, like what work items should be prioritized and why.
- Reduce waste by communicating effectively – Take the guesswork out of teamwork by letting people see their work.
- Overcome impediments – See where work has slowed or stopped and take steps to fix it.
- Collaborate and improve – Visual management encourages collaboration among a team because everyone can see what everyone else is working on.
The best example I’ve seen of visual management in practice is when the Swedish Police needed to completely rebuild their case management software. The book Lean from the Trenches is an easy, but challenging read as may totally change your perceptions on how projects should be run.
For a flavour, take a look at the author’s presentation to a developer’s conference a few years ago:
Setup development environment
If you’re going to have multiple people creating code for your project, then you’ll need them to have the identical environments in which to do their developing. Otherwise you run the risk of the code working for one developer, but not for another.
Vagrant is one of a number of tools that may help.
Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.
Of course, if you’re just configuring SAAS software then you don’t need to worry about this!
Setup development servers
Apart from the small, low budget projects, it’s very rare that you’ll find a software implementation project that just puts the software on a live server and does all the development, configuration and testing on there.
Normally you would want to have three server environments at a minimum. These are in addition to the developers’ local installations where they do the basic functional unit testing.
- Development – the place where all the code that the developers release is tested against the other parts of the system – particularly relevant if you are integrating with other applications
- Staging – a mirror of the production environment, where you place code just before it gets released to production, for final testing
- Production – where the real users are
Agree code frameworks to be used
Again, if you’re not developing code, this may be irrelevant.
If you are, then it’s important to decide from the outset how you’re going to be building the project.Most languages have a range of frameworks which are designed to get you started quickly and avoid re-inventing the wheel. For example, if it’s a Javascript app, then will you be using Meteor, Angular or React (or one of many others)?
Developers often have strong preferences, so it’s good to air these at the beginning…
Agree software architecture
Even if you’re not developing code this is still important. In most implementations you’ll be wanting a number of software components to talk to each other. For example, you might have an HR system, a Learning Management System and a content repository.
Software architecture looks at:
- Which system holds which data
- How and when data will be transferred between systems
- Where there may be gaps in functionality that need to be filled
It normally starts at a very high-level, focussing on the things that are going to be difficult or expensive to change later, and then moving into requirements analysis – the lower level of detail that developers and configurators will work with.
Define user stories for the first iteration
Your developers and configurators will need something to do when the project starts, so this is the point at which you define those first tasks – following the quality standards you’ve already set out.
Each user story should have a rough size attached to it. I use the Fibonacci method for sizing, as it helps to show the relative sizes very easily. Anything that is an 8 or above should really then be broken down into smaller user stories, to make it more manageable. This is especially true if you’re working in 2 week sprints; aiming to complete a number of user stories within each sprint.
Prioritise tasks for the first iteration
Prioritization is a bit of an art form. You’ll be guided by:
- What will show off new functionality most quickly
- Any dependencies on other pieces
- What you can fit within the iteration
The aim is to build something that works and is usable. It might not have all the bells and whistles, but it gives the customer enough to get going with.
Note that there are caveats to this “incremental development” approach. See: The myth of incremental development
It might be that you can build something suitable in a 2 week sprint, or the first iteration may take 6 months. However, the shorter you can make the iterations the more easy it is to respond to changes in the the requirements.
Posted: 17 April 2015
Tags: System implementation