Systems and applications are pretty awesome these days…

System implementations? Not so much.

There are two quite different perspectives on system implementations; they belong to:

  • people who have done one, and…
  • people that haven’t.

The divide here comes from a simple starting point: Systems look simple from the outside (which is of course what is so clever about them – and makes them valuable) but, perhaps ironically, creating this simplicity is quite complex and difficult to do.

So, from an outsider or user perspective everything about systems seems to be, and should be, simple. But the reality of both creating and implementing systems is quite different, and this influences the ‘insiders’ view.

This expectation gap is the causes situation and issues which catches many people and organisations out, which flows like this:

  1. Everyone thinks it’s going to be easy – and is excited about a new system
  2. The project is under estimated and under resourced (in terms of people, skills and funds)
  3. Enthusiasm wains as time passes
  4. Those on the inside learn more and understand the resourcing gap
  5. Those on the outside get more disappointed
  6. Opinions are expressed
  7. Fingers are pointed
  8. Wheels fall off
  9. Hopefully, eventually something gets delivered

Role forward three years, imagine that the same people are in the business, and its system review time… Essentially all of the details are forgotten, but none of the feelings. There is now a dread of these kinds of projects.

Projects fail before they start – this is the problem to solve

Our intent with Skopes is to nip this problem in the bud, before projects begin and way before they fall of the rails: At the time of project setup, where (studies show us) around 70% of the causes of project failure are encountered.

If you have skimmed over that paragraph read it once more – if there is anything that you should take away from this article it is this:

  • Over 50% of system implementations fail
  • Studies show that around 70% of the causes of failure have already occurred before the implementation even begins.

The many studies undertaken of project successes and failures point to a small number of potentially surprising factors that undermine projects and the majority of these are to be found not in the work of implementation, but in the project preparation and (macro) situation in which the project is run.

Skopes Critical Success Factors

Why projects really fail: The majority of success factors need to be addressed before the implementation begins.

Aside: What do we mean by ‘Project’?

Here we are talking about medium sized system implementations. So, not a point and click / install and use system; and equally not an enterprise style ERM system implementation. One is too small / low impact to justify comprehensive preparation, and the other categorically requires dedicated teams of project pros to set up and guide the implementation.

We are considering the kinds of implementations undertaken by medium sized organisations (from say 10 to 500 employees), spending from several thousand to several hundreds of thousands of dollars.

There are two common approaches to setting up a new system implementation, these represent two opposite ends of the spectrum one minimises effort up front but runs a very high risk of failure, the other follows the best practice approach. I think of these as the ADHD project style and the retentive.

Why – “Oh Shit”?

There are a number of challenges that we face to go from Oh Shit to Shit Yeah! Highlights include:

I don’t know what I don’t know!

When non-project professionals get the nod to run a project, the wise ones know that there is a whole lot that they don’t know, and they start to find help. Sometimes this help comes in the form of consultants (who can be expensive), sometimes from friends and colleagues and unfortunately sometime people take advice direct from a single system vendor.

Taking advice is certainly a good thing, however it is best to take it from independent and experienced individuals, and this usually comes with a cost.

Where are the templates and how do they work?

Some larger more organised businesses (and government departments) keep templates that elude to a process or at lease show the format into which information needs to be inserted. This is often a step forward however, often there are problems. For example the template is designed for project type X of size Y, but our project isn’t like that. Or, the template is clear, but I don’t know how to get the information or frankly, what much of it means. Or worse, the template is full of onerous terms and conditions, but very little about the requirements of the users.

I don’t even know where to start!

If this is a first project one of the most common ways to start, unless another is offered, is to get online, do a search then trust in Google and the vendors you come across first. This is a common trap, surely Google knows best? The sales person was very nice… etc. Unfortunately Google knows nothing of your circumstances (and can still be gamed into ranking undeserving websites) and, yes the salesperson is nice – but they prioritise their own needs ahead of yours, its only natural.

Documentation… What documentation?

Strong documentation is one of the keys to a successful project, but it is also one of the most tedious, daunting and unknown elements. What type of document do I need? What goes in it anyway? What do I use it for? Who signs it off? When do I use it… etc.

Documentation is as baffling as it is essential – and is often ignored or done badly – and so is often ignored or done badly.

Requirements gathering from terrible and tedious to collaborative and creative!

Gathering and documenting your business requirements (and translating them into functional requirements for matching to a system) is an opportunity to get excited the potential of your project and engage and motivate users. Unfortunately it often becomes a slow mess of discussion disagreement and revision. Again, people don’t know what they don’t know. Is feature X weird or normal? Where do we derive most savings, or greatest benefit, and how do we prioritise?

Requirements gathering should be a fun and creative time – but most of the time it isn’t.

How do we know if we are getting it right?

If you are not a project professional it is very hard to know if you are getting right, you don’t have the experience to compare to, and the feedback loop is too slow. You won’t genuinely know if you did a good job until the implementation is complete and the system in use for some months, way too late to be useful during the set-up phase. Without the budget to involve consultants, asking friend and colleagues and reading… a lot are the only useful steps, and they are not overly reliable.

A generally frustrating and onerous process

It’s true, everyone wants to get on with the project proper, mucking about preparing is frustrating, particularly if you follow a ‘best practice’ and largely manual process. This frustration is compounded if this is a first project (of its kind) for the team, which will slow it down further and result in trips and wrong turns that need to be corrected.

Ideally we would have tools that speed up and automate (the automatable parts) of this process. And more…

There are plenty more niggles, issues and challenges to overcome during a project set-up – which is why it is often an activity that is brushed under the carpet and why subsequently so many projects fail.

From “Oh Shit” to “Shit Yeah!”

How then do we retain the excitement and focus on the rewards and potential of a new system, even for reluctant project veterans?

We have considered and addressed what we believe (through literature reviews, interviews and feedback) are the primary problems, both perceived and real, to create a new way to set up system implementations and move from Oh Shit to Shit Yeah! Here is how.

Scary trouser filling – I don’t know what I don’t know?

This is always going to be an issue – when we are asked to take on a new task, and one we have not been formally trained to do there are going to be unknowns and only hindsight will be 20/20. One way to overcome this (at low cost but with great results) is to use a system designed by experts.

Skopes provides an awesome (and practical) way to see the future and know the unknowns before they get you.
Where are the templates and how do they work?

Templates help by providing a structure; they reduce our need for knowledge and overall workload. Templates are therefore an essential part of a solution, but they have shortfalls. For example, the are often out of date or hard to find, they maybe off-topic and often they contain no advice on how they are to be filled in, and of course someone still needs to create and edit their content.

Skopes incorporates templates, so captures the good stuff, but it also:
1. Automates the creation of the required documentation (by merging your data into those templates)
2. Provides step by step guidance (through it online interface)
3. Allows for (automated) creation of multiple document types (templates) based on the same data

I don’t even know where to start!

It’s always going to be scary/exciting starting something new for the first time, however it becomes a whole lot easier if you have a trusted system that lays out the process before you (in a visual way, like a map, not a wordy manual). A system with help and guidance at every level and one that is specific to the technology or system that you specifically need to implement.

So we made one!

Documentation… What documentation?

There are multiple catches with documentation – putting aside that it just isn’t fun – these include not knowing the following:

  • What document types are needed
  • When to prepare and use them
  • Why are they needed
  • What goes into each document and why

The tool we have built over comes these issues though automating the production of documentation and flexibly use the data collected to produce the different document types.

Requirements gathering from terrible and tedious to collaborative and creative!

As discussed envisioning a better work life that is supported by a cool new system should be fun not stressful and difficult. The Skopes application takes the stress away by providing comprehensive pick-lists of functionality that are intuitively categorised and explained. We have also provided interactive and engaging ways to explore the features and functions available during your workshops.

How do we know if we are getting it right?

This challenge is one that can sap confidence and slow down project set up significantly. To address this Skopes provides a proven (and appropriate) process to follow, it provides pick-lists of common functionality, allowing you to efficiently (and correctly) specify your project. Perhaps more importantly it provides ‘Peer Insights’. It does so by aggregating anonymised information input by your peers, this throws light metrics like popularity of features and estimated cost savings.

A generally frustrating and onerous process

Scoping can get frustrating, particularly if the process is over cooked out of fear (disguised as risk management) or because it is run by first timers finding their way. Skopes is designed to take project set-up from tedious and scary to easy and creative. Here we have described some of the ways it does so (automation, functionality pick lists, interactive explorers, scoring of system matches etc).

Conclusion

Key facts:

  • 50% of system implementations fail
  • Around 70% of the causes occur before system implementation begins
  • Current best practice is onerous, expensive, intimidating and boring
  • Skopes both:
    • Reduces costs, effort, angst and risk, gets better results, whilst simultaneously
    • Making the process engaging and builds enthusiasm and buy-in

Skopes Comms Assets