Dan Lockeretz, Purple Vision Project Delivery Director shares his experience of delivering CRM implementation projects – something he’s done quite a lot of in the years he’s been a Purple Vision, and even before that in his previous life charity-side. This is the first in a series from Dan looking at project delivery issues.
When talking to organisations about implementing a new CRM, one of the most common questions we’re asked is ‘what implementation methodology do you use?’.
Sometimes, the question is very open as an organisation may never have delivered a technology implementation before, or previously experienced projects in the days before cloud technology when things were quite different.
More frequently, the organisations we work with have done some research or have more experience and will be expecting us to say that we use one of the two best-known methodologies for system development – agile or waterfall.
Waterfall is described as a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.
Agile is described as an iterative, incremental method of managing the design and build activities of information technology that aim to provide new product development in a highly flexible and interactive manner.
The Purple Vision approach
Over many years and hundreds of project, we have learned that the best process to adopt for a technology project is not necessarily one approach or the other, but a blend of both.
If your organisation has significant legacy systems, then there is often a need for a specific ‘go-live’ point – a moment at which the legacy system(s) should end and the new one starts. A project like this will benefit from a waterfall approach.
The alternative to this is to manage multiple systems for a period of time, which can be complex, costly and risky.
Agile development takes a more phased approach to delivering implementations, and so is ideal for those who have little in the way of legacy systems and therefore no need to make a switch-over at a single moment. There are lots of advantages including:
- It engages the system users in the project at an early point and throughout the project. This means by the point of go-live those users have a good understanding of the system and have gained knowledge of the build and use of the system
- It reduces the risk of the end product being the ‘wrong’ solution. Experience tells us it easier to manage lots of small adjustments on a frequent basis, than it is to manage large infrequent adjustments.
- Progress is more tangible to the Project Team and engagement in the project may remain higher as a result
The disadvantage of an agile development methodology as we have experienced it, is that is requires a high-level input from process experts on the client side and can therefore impact heavily on business as usual. If this is planned for in advance however, we believe this is the most effective way of engaging staff in the project and building a successful system with successful user adoption.
Best of both
Our best of both approach gives us flexibility to manage a project in line with an organisations requirements and needs, staff availability and other factors.
An example is a project where an organisation is planning to replace a system it has used for a number of years with something completely different – such as an out-of-date server-based system with a move to a cloud-based solution.
As the server based system may be out of date the team using it may not be able to deliver all of their key functions via this tool and may be using other tools or managing complex work-arounds. In this situation, we would spend time looking at initiation, analysis and design of the new system (waterfall approaches) to make sure we’re developing and delivering what is needed today and not just copying what has gone before.
We would then be ready to construct and test using a more agile approach.
Which takes longer?
Neither approach is longer or shorter than the other necessarily – the critical factor is not time to deliver, but the project which is being delivered. To identify a project timescale, we need to consider issues like the technology you’ll be using, how much work needs to be done to tailor the tool to your unique situation, how prepared you are (see another blog for more about this) and availability of key resources (like developers, trainers etc).
Other project terms you’ll hear
- Iterative – iterative is a fancy word for repetition or frequency. Essentially, for agile developments which are iterative, the project is broken down into set blocks or sprints where work is completed.
- Sprints – rather alarmingly for non-runners, sprints area often talked about as part of a technology implementation project. Don’t panic! This term refers to the blocks of time in which work is developed and delivered. It’s more common to have sprints in Agile development but it is possible to have sprints in waterfall but for different phases. It’s as much a way of everyone planning their time properly as anything else.
- Legacy systems – this isn’t about giving money in your will. This refers to systems that you have already that may be in use that you are replacing as part of your technology project – be that an old CRM, a series of spreadsheets or anything in between.
- Scrum – a scrum is a process used by a project delivery team to allocate work out to deliver the project – eg technical work such as things that need building, information needed from project management team, user testing, etc. Scrums cover a set period of time (eg a week, two weeks or sometimes longer).
- User stories – this is simply a process of mapping out what the users need to be able to do in a system or with a set of functions. Mapping out and agreeing a user story means we all know what we’re working to achieve.