Improve user acceptance with the “Model Office”

In a recent post on SCRUM, Adrian McGrath made a comment about the use of a “Model Office” approach for gathering requirements for systems. A Model Office approach is also useful for encouraging user acceptance.

What is a “Model Office”?

This piqued my interest…what is a “Model Office”?  

In comparison to the “Waterfall” method, which involves capturing requirements, designing, building, testing and deploying, the “Model Office” approach offers a far more “collaborative” way of designing a system.

the “Model Office” approach offers a far-more “collaborative” way of designing a system.

Adrian McGrath has written an excellent post on the “Model Office” (see link below). In it he points out that the success of an implementation is heavily dependent on the uptake of the solution and buy-in from the user base, and further to that, during requirements gathering, most users “don’t know what they don’t know”.

How does this improve user acceptance?

By using the Model Office approach, the “end product” is created, and the users are allowed to interact with it and become familiar with it. Changes are made iteratively until the end-solution is something that the end-users are happy with.

My initial reaction to the “Model Office”

Most of the large projects I have been involved with have made use of the “Waterfall” approach.

As a result, in my mind, the “correct” way of designing a system was first to get the users to define their requirements, independent of any specific end solution. Then a suitable solution was designed that would meet these requirements.

Even though I had discussed SCRUM methodology earlier, I didn’t think that it was suitable for a large system, which required a more formal approach to design & development.

However, as Adrian pointed out – “a user doesn’t know what he doesn’t know”. This makes me think about Henry Ford’s quote “If I’d asked customers what they wanted, they would have said ‘a faster horse’.”

A Faster Horse

When dealing with new technology that offers a totally different way of working, it is a bit unfair to ask the users for requirements. Often they can only describe what they want in terms of what they know. This means there is a risk of missing the full potential of a system. And, as Adrian also mentions, it means that the adoption of the new system by the end user is very slow.

And, in terms of the “Technology Acceptance Model“, because the user has not been truly “involved” with the design process the “perceived usefulness“, and the “perceived ease of use” are not great.

Taking this all of this into consideration, I find the concept of the “Model Office” an exciting one. I can certainly see advantages of it in terms of user adoption.

“Model Office” Resources

• Adrian McGrath’s post “The Virtues of a Model Office“
• Virtusa: Why you should consider ‘Model Office’ for large transformation programmes

Want to learn more?

Below is a selection of resources that I personally feel are relevant to this blog post, and will allow you to get more in-depth knowledge. I do earn a commission if you purchase any of these, and for that I am grateful. Thank you. (Important Disclosure)