Do you know this story of the drunk who had lost his key on his nightly way, and then focuses his search to the lit spot around a street lamp post because that's where he sees best? Browsing community and expert forums on how to increase the success rate of IT system implementations, I regularly have the feeling we all must be on our way home from a blasting party. The key to successful implementations - most seem to agree - lies in choosing the right method for turning clearly defined requirements into software. There are those swearing by waterfall, others by agile approaches, and others again swear at either. IT centricity through and through.
In contrast, I argue that the key to any successful implementation is understanding what the (business) customer really wants and needs, and enabling efficient, regular alignments for fine-tuning and integration across communities. And that is where I see a process-centric approach as project methodology as THE winning factor.
Especially for larger systems, numerous technical and business experts need to collaborate on highly specific questions with abstraction levels ranging from business strategy and operating models to execution and monitoring alternatives within individual (sub-) processes. Business process management (BPM) provides a framework to capture and connect requirements across theses orders of abstraction - if you do it right. (Please do not limit BPM to automation and overseeing automated processes here!)
The integrated process models will provide the coordinate system to structure the requirements definition and their continual refinement as more processes and their stakeholders get considered, and as the functional and technical design progress.
End-to-end sequences of integrated models are 'Ariadne's thread' making sure that requirements are comprehensive, test cases meaningful and relevant, and change management is user-oriented. Understanding the requirements in context of their processes enables fact-based and risk-based decisions for adopting a standard solution or investing in customizations. Without the process context, the project is bound to become a maze and neither waterfall nor agile practice will secure a successful implementation. With clearly structured and documented requirements in place however, you can set up your implementation methodology to match the team's experience, working style, location distribution and other criteria that will guide your choice.
Now, certain implementation partners and integration managers may claim that their experience will carry the project, and that building an integrated process model itself would be a wasted effort creating a maze all by itself. However, from my experience, I'd be surprised if they could conclusively demonstrate to you how they will keep up reliable transparency to all stakeholders on aspects like business fit, requirements and test coverage, and avoid the disconnect when talking to users during alignments and training.
Obviously, the process-centric approach goes well with involving your business customers early as Dr. Russell Gomersall discussed previously and keeping them involved as I wrote about in Why is Change Management dropped so often during implementations, and how can this be prevented?
With Business Flows we at bpExperts GmbH have built a reference architecture, process model content, and project templates which enable the business to stay in control of the business transformation. With that in place and the project methodology clarified, you can leave the choice of the implementation methodology to the implementation team.
We care, we act, we deliver!
