- What Is a Methodology?
- Methodology Structure
- A Case in Point
- Build Your Own?
- Selecting a Methodology
- Implementation and Rollout
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Selecting a Methodology
Often the most difficult and important task that any IT department can make is to select and implement an all-encompassing and necessary methodology. Most IT organizations flounder for lack of standard methodology practices, but they often adopt tools, packages, and other software with false expectations, poor selection processes, inappropriate training, and half-hearted implementation support (eventually leading to shelfware rather than effective product usage). Managers should carefully prepare a selection process to ensure a meaningful implementation of methodology tools.
Fundamental questions need to be asked and answered by every organization considering an IT methodology:
- What dominant trends in IT practices are available to my organization and will increase productivity significantly (30% or more) in the next five years?
- What proven methodologies, project management tools, and repeatable processes are available to meet this goal?
- What are the benefits of a methodology to my organization?
- How do I go about selecting and implementing a methodology?
- How can I convince my senior management that methodologies are not another IT gimmick, buzzword, or silver bullet?
- How can I produce metrics and definitive data on productivity?
- Will our end users be able to use a methodology?
- What training do we need to be successful?
The most difficult step for many organizations is in choosing a methodology. The 1980s and 1990s were filled with consulting organizations armed with foot-thick methods and proposals (Andersen's METHOD/1, GE's OMT, TI's Information Engineering Methodology, and so forth). Along with these systems came very expensive consulting contracts. Perhaps one of the best examples of modern IT methodologies is IBM's Rational Unified Process (RUP). Rational's process combines the original work of three scientists (Grady Booch, Ivar Jacobsen, and Jim Rumbaugh) with its product suite, which implements the lifecycle steps. In comparison, methodologies such as the more-radical Extreme Programming and others have a narrower scope and less formal style. However, RUP is a framework that enables various lifecycle elements to be substituted.
Organizations must consider a methodology as a good overall guideline for the entire development process, but fit it to their needs and evaluate it against truly iterative paradigms. In developing a process, focus on what's important. A process defines who does what and when; it must allow flexibility and not be for the sake of producing documentation only. The overall process should be developed with the input of the user constituents, and post-mortem reviews should be conducted to discover areas that work and areas that need improvement. In short, an iterative process should also evolve toward flexibility and customization. Assess your organization to see where you experience the most pain and where the methodology needs are the greatest. Which best practices should you adopt to get the biggest bang for your buck?
Following is a basic list of areas to take into account in the methodology selection process:
- Direction and planning. Clarifying what needs to achieved. Involving IT management and end users in deciding what needs to be done. Communicating the vision for the policy initiative.
- Action. What actions need to be taken? What is the approach, what tasks need to be undertaken, and by whom? Define the tasks in detail.
- Resources. Staff skills and numbers, necessary infrastructure and budgets. Agree and have in place to start.
- Communications. Tailored to the stakeholder audience. Communicate regularly what's happening and what to expect.
- Motivation. IT must listen and take into account any diverse views, praising achievements and celebrating successes.
- Timetable. What needs to be done, when, and to what standard. Describe the deliverables and outcomes and when they can be expected.
- Monitoring. Progress should be assessed at regular points and performance measured against required standards and preset criteria.
- Risks/dependencies. Include program, strategic, and operational risks. Dependencies should include all tasks and deliverables required but not provided directly by the methodology program team.
- Project structures and types. Define roles and organization of the methodology team, management, and reporting structures. Explore relationships of projects to the program. Analyze the different types of projects that the methodology addresses. How will ongoing support be provided and used?
- Leadership. What leadership skills do the key members of the program team and the management committee need to be successful?
- Completion. A robust plan of how this change will be brought about: Who is responsible for what? When will it happen? How much will it cost?