Success is not something that just happens. In order to be achieved, success must be planned for. There are certain factors, principles, and disciplines that will have a direct effect on the success of the outcome:
Understand and Define Your Problem Set
Define Your Scope
Establish Guiding Principles
Make Fact-Based Decisions
Understand Your Goal/Define Your End State
Establish Coalitions/Gain Buy-In
Develop a Plan and Stick To It
Common sense, right? You would be surprised at the number of teams who find themselves significantly down the road and cannot remember or clearly articulate what the problem set is or what they are trying to address. The problem set should be understood, well defined, and documented. If you cannot clearly articulate the problem set, I can almost guarantee that it is not understood or defined. If you don't know what your problems are, then you will not know where to focus your portfolio of services.
Defining scope is one of those activities that you may find yourself revisiting a few times before the end of the project. However, do not let this dissuade you from developing an initial scope upfront. As you uncover facts, review results from "benchmark" visits , and in general become educated in the ISD world, you will find yourself adjusting your scope to incorporate "new" services or aspects into your model, or removing some "old" ones. The scope will help keep you on track.
It is essential to establish guiding principles as a team. They provide the framework by which the team will approach all strategy and problem solving. They give the team a common perspective, based on those principles that are most valued. To better understand their importance, it is best to illustrate with the following example:
Maximize Customer Satisfaction
Maximize Level of Service
Optimize for Scalability and Provide for Reusablility
Any output or decision should satisfy part or all of these criteria. Once the principles are agreed to, they should be referred to often, especially if the team is divided on a decision or direction to take.
It is very easy to fall into the trap of making anecdotal-based decisions. It is human nature to yield to emotion, experience, "gut feel," and perception. You will find that if you gather, organize, and analyze the facts, the outcome may be surprisingly different from that originally predicted . This is why any decision or approach should be supported by sufficient data, not so much to be able to defend or explain your position, but to provide assurance that you have truly thought things through objectively. Objectivity is the key.
Much can be said for the benefits of benchmarking. Its main purpose is to provide an exemplar, a high "watermark," so to speak, after which you look to model your specific functional area or business. Two challenges exist with a successful benchmarking exercise. The first challenge is to effectively collect and organize benchmark data so that you are making an "apples to apples" comparison of the operations you are studying . This can be more easily facilitated by developing an outline of the information you are trying to gather and developing an associated "questionnaire" to help you in your efforts to be consistent in your fact collection. The second challenge is finding a business, similar to your business, which truly has what is considered a "benchmark" operation. The whole benchmarking process, along with these challenges, is addressed in detail in a later chapter.
You are probably thinking to yourself that is ridiculously obvious, and we did too when we started out. However, our fact-finding left us "swimming" in so much data that we really found ourselves thrashing about, and when you are "wading" around in this much data you can find yourself losing sight of where it is you are trying to get to. The message here is to not only understand your goal and define your end state, but to refer to it regularly, use it as a guide, and, most importantly, modify it if necessary. Knowing where you are going and where you want to be is more than half the battle.
Developing an ISD model is not without its challenges; however, once it is completed the real work begins: the work of selling the model and gaining concurrence from management. This is why establishing coalitions is so important: gain buy-in early on and continue to sell your ideas throughout the entire project life cycle. An approach we took was to actually pull the management team into the development of the proposal, therefore, it was tailored exactly to how they like to be sold to. Certainly not a new approach, but a very effective one. You will find that when it comes time for final sign-off to move forward it will be a rather simple event if you have done a good job of selling early on.
Total quality management ”an 80s and early 90s concept, right? Wrong! You will find that throughout this entire book we will refer to over a dozen "quality tools" that we used to develop our overall ISD model. Quality really plays heavily into making fact-based decisions, root cause analysis, and in organizing your thoughts in general. It was the basis for most of our work processes and was integral in helping us achieve our ISD model. You will see specific examples of how we used quality tools in later chapters. We are happy to be able to say that quality is alive and well.
This book is not meant to be a Project Management 101 course; however, having said that, I do want to stress that it is very difficult to successfully deliver without a solid plan that is followed and updated continuously. Tenacity is probably the most important quality of a good project team.