I am working with a well known media company and I have been charged justifying why they should change their current development process. Right now, there is very little documentation and/or metrics. All of the usual problems exist. I know what the obvious benefits are to enhancing their process, but does anyone have anything more detailed? Saving Changes...
What is the total bottom line impact of these "usual problems" and of dealing/living with them?
What is the ballpark cost of delays, rework, delays, CYA activity, delays, managing to conflicting measures, delays, going too far down dead ends too slowly, and delays?
You don't need a lot of "documentation and/or metrics" to do a good enough analysis of the situation. Simply sit with the key stakeholders individually and discuss the "usual problem" that they would put at the top of their hit list -- people are happy to "bitch and moan" about such things, and a lot of info can be gleaned from such discussions. After all, they know the "costs" associated with their pet peeves...all the things they have to do as a result of its existence.
Once you've collected the big "undesirable effects" of the current system, they need to become the targets of the new system. That way, everyone involved will have "a dog in the fight" and will see benefit from supporting it. As important as any big number total value is in getting peoples attention, the individual problems solved for the stakeholders will be even more so for assuring buy-in, support, and collaboration. (And just because you "know the obvious benefits" doesn't help them see the benefit in their terms.)
The TOC Thinking Processes provide an approach to such analyses. I've facilitated enough of them to have really come to appreciate the benefits of building buy-in along with the solution itself. Without the former, the latter has little chance.
(By the way, notice that the primary issue, in my mind, is not one of cost reductions, but of maximizing the throughput and top line of the system.) Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Too often a Business Process Review exercise stalls because folk become mesmerised by the need for a baseline comprising current process metrics.
As you have found, these don't exist and although it is tempting to do the research to benchmark current performance, often there isn't the time, resources, budget or interest to do so. Incidentally don't misread me, I am actually a real advocate for creating current process performance baselines, but (a) there are various ways to do this, and (b) sometimes it is the straw that would break the project's back.
So a few thoughts on alternate baselines. I currently support a national benchmarking forum in Australia where the members sign up to a CMM maturity-type approach in measuring current project management performance. The reality is, though we use a five point metirc scale to measure performance, it is really more (and intended to be) a qualitative assessment than a true quantitative approach.
But it is ironic isn't it? How frequently do we receive as brief from a client who fundamentally know they need to fix a process, then ask us as externals to justify their opinion before they move on. I would point towards the fundamentals of a process review: . What is the process . What is the purpose of the process . Baseline the current process workflow . Ask the question, where is the process currently failing? . Set a finite set of reasonable KPI's for the process when it works well . Score the current performance against the KPI. . Identify and prioritise improvement strategies. . Conduct the improvement as a project . Remeasure the performance when improvement strategies are in place and have had time to take effect.
Regards
David Hudson, Brisbane, OZ Saving Changes...
Anonymous
A good way to sell process improvement is to leverage Sarbanes-Oxly Act 404 and etc.
Every process improvements should be in a very staged manner - Most of the process Improvement plans fails due to JumpStart syndrome .
Generally a staged plan might help in such a case it is always advisable to take some model help as in CMM or ISO - I would porefer CMM ;
Step 1 would be to look into the Business Goals and Align all process to your buisness goals.. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Just a thought to remember - Don't over complicate PI. By taking the organization's business objectives (these need to be quanitified in operationally understandable terms) and then asking management WHY they aren't achieved NOW you will begin pulling on the threads of what processes are deficient. Use that knowledge to begin the discovery process with the cross functional groups of workers that comprise the processes identified. Pose to them the objectives and facilitate their exploration of WHAT WOULD HAVE TO CHANGE in order to achieve the them. Now you have a context for mapping workflows, developing measurable GAP analysis and developing new workflows, policies and procedures that align with the Business Objectives set forth.
Management becomes the champion because its there goals that are being achieved.
ROI becomes easy to calculate because its foundation is in the achievement of the organization's prime objectives.
All the metrics needed to measure success fall out of the process and are basically FREE.
