This post discusses how a ‘Model Office’ approach to requirements capture, design, build and test can play a significant role in improving the success of an Electronic Document and Records Management System (EDRMS) implementation. As always, I would very much welcome any comments, observations, feedback.

What’s up Doc?

The success of any EDRMS implementation is heavily dependent on the up-take of the solution and buy-in from the user base. However, I think that this success is too often put at risk when implementing EDRMS solutions based on the more traditional ‘Waterfall’ approach which performs the requirements capture, design, build, test and deployment in discrete and largely independent stages.

The problem with the Waterfall approach stems at its source, the requirements capture. For many organisations, a large proportion of its user base will have little or no previous experience of using an EDRMS solution. Even for those users that might consider themselves reasonably knowledgeable of what EDRMS is all about, they are unlikely to be familiar with the latest developments in EDRMS technology, best practices and process.

As such, when it comes to requirements capture, there is a fundamental barrier to overcome in that most users don’t know what they don’t know. Therefore, how can we expect them to provide set of requirements that will form an accurate basis for the subsequent design, build, test and deployment? I don’t think we can, there is too much room for misinterpretation. Their expectations for what they think the solution will provide them might be very different to what we capture as requirements. And it is a bit late to find this out several months down the line when they get sight of the solution for the first time. A humorous analogy that alludes to this problem was written by Lee Dallas in his post WikiLeaks, Expectations and ECM.

In my view, the best way to overcome this barrier is to give users the opportunity to visualise the technology in action and give them time, with the help from experts, to understand how they can best use the technology to meet their specific business needs. Let the requirements naturally evolve based on true understanding of the technology and the impact of introducing it on people and existing processes.

This is the approach that the Model Office takes, overcoming many of the shortfalls of a Waterfall approach, and is the subject of this blog post.

The 2 Franks – my way and the right way

Achieving a high take-up percentage of users for a new EDRMS solution means addressing and conveying the value that the new solution will bring them at both a personal level (“what’s in it for me?”) as well at an organisational level.

The best way to do this is to get users that represent different parts of the organisation involved at the outset of the EDRMS programme of work such that the solution is designed and shaped by the people who will use it.

If this is not done then the chances are that the solution won’t be representative of what the users want, and many will find ways to passively resist using it, doing things their own ‘Frank Sinatra, my way’. It is so much better to catch potential issues, mistakes or ambiguities around requirements as early as possible in the programme where they can be resolved before the build commences. From an architecture perspective, Frank Lloyd Wright once spoke about it being easier to use an eraser on the drawing board than a sledgehammer on the construction site.

This is where the Model Office comes in.

What is a Model Office?

The Model Office represents a controlled ‘laboratory’ environment (one that doesn’t impact the operational business) that facilitates a rapid, agile and highly effective means to capture and agree requirements with key users across different parts of the organisation. It is an ideal means to refine the solution to meet the specific needs of the users that will be using it, allowing them to visualise how the solution can be designed to meet their requirements and new ways of working, and what the ‘wow factors’ and ‘quick wins’ might be to tip the balance in favour of wider user adoption. Importantly, it also identifies the requirements that really matter to end-users (rather than all requirements being mandatory) and ensures that the requirements stick to the overall business vision and objectives, avoiding going ‘off-piste’.

The approach follows an iterative loop around requirements capture, design, and build until the solution reaches a completion state (within the time-box parameters) that end-users are happy with. This gives users a sense of ownership for the solution with the opportunity to shape how it is built and rolled out. It additionally allows users to get a firm grip on the business, people and technology aspects of the overall solution. This is essential as technology plays the minor role in an EDRMS implementation; the major role being business change.

The Model Office is focused on producing a standard implementation blueprint that can be rolled out, with localised configuration, across the organisation. Processes, tools and material for business change activities such as training, migration, and new operational procedures can all be trialled during the Model Office.

By its very nature, a Model Office enables more of an ‘agile’ approach (i.e. incremental delivery of value over shorter iterations) to be taken to requirements capture, design and build. This gives it significant advantages over a traditional waterfall approach

Benefits

From an outcomes perspective, the key benefits from a Model Office tend to fall into two categories:

• De-risking the project, giving it a much greater probability of being a success:
  • Allows users to see what works and what doesn’t work, with constant feedback from users enabling issues to be caught and addressed as early in the process as possible.
  • Users understand why they need it, how they should use it, feel ownership for it and buy into it;
  • More rounded solution based on addressing practical requirements and built in line with key business vision and objectives;
  • Business change aspects explored, refined and agreed prior to wider roll-out;
  • Allows training of super-users to be grounded on practical experience gained from working on the development of the Model Office;
  • Enables a comprehensive evaluation of the product, design and most business change activities without impacting the operational business;
  • Identifies selection of best pilot area(s) to take on solution in operational capacity;
  • Forges a bridge between IT/IS and the business as the Model Office will require staff from IT/IS and the business to work closely together;
• Shorter overall programme timescales:
  • The Model Office will typically yield a 5%-10% reduction in overall implementation timescales;
  • User Acceptance Testing (UAT) is fast-tracked as it is often just a formality as key users will have been involved in the design and build right the way through the Model Office;
  • In general, a Model Office should result in far fewer issues and encounter far less resistance to change during roll-out, all resulting in shorter implementation timescales.

There are, of course, some implications to be aware of when adopting a Model Office approach. For example, it will require key users representing different parts of the organisation to have availability to proactively participate in the Model Office, potentially away from their desks with some disruption to their daily activities. It will also require IT/IS support, infrastructure, space and facilities.

Nevertheless, I firmly believe that the benefits of reducing project risk and shortening the overall timescales that the Model Office provides will significantly outweigh any implications.

Transition to future office

After deployment, the Model Office could then transition into a Future Office to examine how the solution can further evolve and be enhanced going forwards. For example, it could be used to explore the wish-list of requirements that were not feasible to be included in the initial pilot and roll-out waves. In most organisations, the functionality provided within the solution during the initial roll-out is typically kept fairly simple (without all of the ‘bells and whistles’) as there will be enough challenges in rolling out the solution without trying to cater for every requirement. The Future Office could be used to test new ideas around technology, process and people. Analogous to the ‘Ideal Home Show’ that is run annually in the UK, the Model Office could represent an ‘Ideal EDRMS Show’ except that it runs every day.

• ECM