In a recent post on SCRUM, Adrian McGrath made a comment about the use of a “Model Office” approach for gathering requirements for systems.
This piqued my interest…what is a “Model Office”? So I started reading more.
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.
Adrian McGrath has written an excellent post on the “Model Office” (see link below). In it he points out that the The success of a implementation is heavily dependent on the up-take 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”.
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’.”
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.
“Model Office” Resources
- Adrian McGrath’s excellent post “The Virtues of a Model Office“
- AIIM‘s Knowledge Center Blog – “The Use of a Model Office“
- Expert Program Management – “The Model Office“
- RMS Bulletin – The Role of the Model Office in a Successful EDRM Implementation
- Simulating Business Processes – The Model Office Approach