Having personally done extensive work with many Organisations over the years to help them create, adapt and implement various types of SDLCs for specific transformational needs, I found the recent article by Mark Kennaley very insightful as a categorised summary of the types of Methods that exist.
Mark describes how the various Software Development Methods (used during an SDLC) often reflect the culture, structure and processes of the Organisation and promotes either positive or negative characteristics when it comes to Delivery of Solutions that meet Business needs.
He states that the typical negative impact on an organisation manifests itself in various costly ways:
…Each time an organization embraces a new methodology, it triggers a large change management exercise. Within IT, this change typically involves a three-to-five year process that results in the following direct costs for a 1,000-person IT organization:
Consulting, training, and mentoring costs to go from novice to competent, and even expert, using Stuart and Hubert Dreyfus’ skill acquisition model. For 1,000 people, this can cost $1 million to $2 million.
Knowledge management, to avoid the risk of relying on tacit knowledge in the heads of coaches and consultants. If performed, the capture of standard work, or “our way of working,” results in more than $1 million in costs related to process-related software.
Changes in approach can also trigger the need for new process management tools. Cost can range from free to $1 million or more.
Costs related to putting a new software delivery infrastructure in place. Hitting the reset button can cost upward of $5 million.
The recent presentation (with embeded audio) given by Keith Swenson at the 2009 Process.gov conference in Washinton DC on June 19, explains how a process model may or may not change over its lifetime i.e. static business model to execution in a BPMS and what the various considerations and trade offs are.
Keith identifies 3 kinds of change that a process may undergo:
Business Process Enactment: – the business process as it moves from the beginning to the end of handling a single case. The process definition does not normally change here, only the process instance or context that records the state of a particular case changes.
Business Process Lifecycle: – these are the changes that a business process goes through from initial concept, to modeling, to integration, and finally to deployment into an enactment environment.
Business Process Improvement: – the change to a business process that occurs over time through repeated use of the business process lifecycle followed by analysis of how well that version of the business process worked.
I have worked with various organisations to implement BPM solutions at both Enterprise and Departmental levels. A common challenge that I often come across is that both Business and IT don’t always understand how to apply itterative development approaches to support a BPM implementation.
As practitioners, I find we tend to take these types of approaches for granted but customers often need some education, especially if they have not used anything but Waterfall. The most common issue I find with Waterfall is that it instills a mind set of “Big Bang” project/solution delivery i.e. ‘know it all the build it and finally test it all’.
With greater pressure on both Buisness and IT to show value and returns quicker and more consistently, itterative approaches have demonstrated their value with much better ROI and a lower unsuccessful implementation risk ratio, especially if an organisation is new to BPM.
Various itterative approaches exist and the more commonly known one in my experience is SCRUM, XP, Agile and RUP. To help educate novices what its all about I thought the following resources may be useful.
Ken Schwaber co-developed the Agile process, Scrum. He is a founder of the Agile Alliance and Scrum Alliance, and signatory to the Agile Manifesto. Ken has been a software developer for over thirty years. He is an active advocate and evangelist for Agile processes.