I have thought about some pointers you should consider when looking at methodologies, and more specifically toolsets.
1. Our methodology philosophy:
1.1. A toolset.
A methodology is purely a toolset to enable one to deliver the required results fast, accurately, with precision and with a guarantee of success, and to enable the elimination of risk. There are a large number of methodologies available in the market that share domains in what they can be applied for.
1.2. Lots of methodologies and toolsets, often components of what is required or sold incorrectly.
There are also a large number of ‘methodologies’, or components relative to more complete frameworks to problem solving, that can provide valid business benefit, provided that they are not utilized in isolation. Often brilliant components relative to larger frameworks are published. It often happens that ill-informed sales forces position these methodology components incorrectly and often sell them to customers and do not ensure that they are not utilized in isolation.
1.3. Most businesses have adopted some.
Virtually all businesses have at this stage adopted methodologies of some sort, to some degrees of success, and to different levels of maturity of utilization and readiness of the business.
1.4. Organizations have methodologies that cannot necessarily be replaced.
When one embarks on projects with these customers it would be fatal to attempt to roll out what is there, in the format of existing methodologies, and replace that with yet another ’World Class and Complete methodology’. Organizations already utilize their potentially incomplete and potentially fragmented methodologies with varying degrees of success, but more importantly, they have already spent vast amounts of money to embrace them and have grown emotionally attached to them. These ‘methodologies’ have also already delivered solutions to certain measures of success.
1.5. Integrate into a broader framework if necessary.
What needs to happen is that one has to integrate existing methodology components that a customer utilized into a more complete methodology framework to ensure that the desired value is derived.
1.6. We don’t sell methods and started with a meta-model.
We do not sell a methodology; we provide a philosophy and a framework to methodologies. Our point of departure was the establishment of a meta-model to provide solutions to business problems. This meta-model was then objectised into true object oriented methodology objects. For all of these methodology objects we have developed methodology techniques of which some are already strung together in hundreds of methodology recipes, tailor made to specific problems.
1.7. Some recipes can be re-applied.
Some of these recipes have also been re-applied on other projects where they were applicable.
1.8. You need project dependent, customer specific, evolvable methodologies.
We are of the opinion that there does not exist a single methodology that can be applied to solve all kinds of problems, for all sorts of businesses, across diverse industries. What we do believe is that a methodology potentially has to be created for each instance of a project within each organization. So, methodologies are not only organization specific but are also project specific within each individual organization. We also believe that a methodology for a project has to evolve over time to accommodate changes in what a project has to deliver, as a result of pressure exerted on the project from its External and Target Environments. Thus a project specific methodology must also be time dependent.
1.9. Our framework is object oriented which accommodates change.
The fact that our methodology philosophy is reflected in an object oriented methodology meta-model enables us to incorporate different methodology components that are existent within customers, or that are at that time better than our existing components. This is accommodated without obscuring the larger methodology framework and encompassing philosophy.
1.10. Object Orientation enables change without obscuring the framework.
As a result of an object oriented methodology meta-model we can also string methodology objects together to represent new recipes as they are required for unique individual projects, again without obscuring the larger methodology framework and encompassing philosophy.
2. The Criteria for methodologies:
Methodologies should ultimately conform to the set of criteria that is documented in the Business Engineering, an Object Oriented Framework manual from page 9 onwards.
1. A holistic Business Engineering approach, including Strategic Positioning through to Application System Implementation and the alignment of the other required resources. The solutions must be ‘switched on’, executed and monitored to ensure that the results which are required are delivered by the new business processes and their enabling resources like skills, information, etc.
2. It is an object-oriented or component based approach
• The methodology consists of methodology objects/components that can be plugged in and out of a true object oriented framework.
• The solution that is delivered has to be component based.
3. The approach covers three architectural levels in an integrated manner.
• Business Architectural Level. (What do we want to do in business)
• Procedure Architectural level. (How do we want to do it)
• Technology Architectural Level. (With what infrastructure do we want to do it)
Three main architectural levels represent any business. To deliver a new business it is necessary to effect changes across all three architectural levels. The sequence in which the architectural levels are addressed is of utmost importance. The business architectural level, which represents what we do, has a major influence on which processes, as well as what they look like, the new business will have. The technology and/or process architecture layer consists of the information technology; hardware, software etc., as well as the production plant equipment of the organisation. Changes in this architecture layer will definitely have a major impact on the new business’ process architecture layer in terms of which processes it will consist of and what they will look like.
4. A continuous dedicated Business Engineering function set.
A continuous, dedicated Business Engineering function set needs to become part of the organisation. This will ensure that one does not have to venture into a business engineering exercise frequently.
5. An organization specific methodology that you leave behind. This methodology will also consist of objects.
6. Business Engineering object queues and/or pre-developed solutions.
7. Business Engineering of this nature requires a single framework that integrates three thrusts, architecture, project management (the governance of the project) and organization behavior/human engineering/change management (changing the governance and mindset of the business).
3. Ensuring the Strategic Fit:
3.1. Express strategy accurately and conduct changes directly to it.
In addition to that one should look for ways to ensure that the business' strategy is facilitated through a thorough approach that will ensure the delivery of a comprehensive strategic expression, consisting of the correct components to enable one to utilise it to deliver change accurately. It is very easy to deliver mother-hood type strategic statements that nobody can accurately utilise to deliver change. These types of strategic deliverables are components like Mission and Vision statements, SWOT analysis, etc. All of these types of components of strategy are valid and useful, for what they are designed to do. It is virtually impossible with a number of strategy components to ensure that one changes business processes to accurately be in line with the business' strategy, let alone ensure that the applications facilitating these processes are reflective of the business' strategy.
3.2. Processes and technology have to contribute directly to strategy.
It is important that process designs are derived from strategy in an integrated manner. It is also important that the technological componentry that will be derived has to enable the business' strategy in such a manner that it can be mapped to prove direct contribution and completeness thereof.
4. Technological Architecture:
The style of technological architecture that we derived when we built the systems like the license being used by DealerNet is clearly similar to what is required in your case. It is an architecture representative of a different level of abstraction. The normal UML type of modelling techniques cannot guarantee delivery of an abstract architecture like this. By using UML type of approaches such a technological architecture would depend entirely on the consultant's capabilities and historical frame of reference, which is not necessarily the bias one would want. The methodology that you choose should enable, in a natural way, the delivery of this level of technological architecture, extrapolated out of the business' strategy.
5. Architectural Completeness:
In addition to that one needs mechanisms to ensure that the entire required architecture is covered through the reference to a complete architectural framework, the Zachman Framework, that of META or Gartner, or others. This still does not ensure that one does actually cover the entire scope of the component of the value chain that is required in your project. Different types of cross reference and completeness mechanisms are required that are not represented by UML.
6. The Project Management implication:
Ultimately the methodology that you choose should facilitate Project Management in the following way:
The current problems organisations face today:
6.1. Incorrect projects are executed.
In Organizations today too many incorrect projects are being ventured into that simply will not make any contribution to the success of organisations. These project waste scarce resources and prevent organisations from executing the correct permutation of change initiatives.
6.2. Often budgets are allocated subjectively.
Often the budgets for projects are influenced by factors like political alliances within the organisation, or the fact that individuals have an excellent capability to articulate the need for a particular project, versus individuals that don’t have that capability to articulate themselves. Often in these cases the project budget is granted to the ones that can express their requirement for the change initiative better, or those that are politically well aligned with the individuals that control the budget. That does not imply that these particular projects will make the biggest business difference.
The challenge we face:
6.3. Projects have to return value and contribute to strategy.
What is challenging today is the quantification of the proposed projects' returned value, with respect to business and its underlying processes’ improvement. Not only that, but the quantification of the change initiative's contribution to the strategic positioning and strategic differentiation of the organization.
6.4. Projects must depart from strategy.
If a project does not contribute directly to the strategic position of a business it should simply not happen. The point of departure for any project is the correct mandate for the correct project. Simply too many projects are launched into by organisations that should never have happened.
6.5. Projects have to change over time.
In addition to this it is of critical importance today that we equip projects and project resources with an accurate capability to deliver projects within an ever-changing business environment. In this context projects cannot simply deliver exactly what they initially set out to deliver. It is necessary today to enable projects to accurately change their direction relative to changes in the direction of the underlying business Strategy.
What our Programme and Project Management method sets provide:
6.6. Our programme and project management philosophy.
The above mentioned problems and challenges are exactly what our Project Strategising recipe, an extract from ‘Business Engineering Project Management, An Architectural Bias’, ensures that we deliver. This represents but one of the differentiating factors of our Programme and Project Management to the traditional project management principles.
6.7. IT, IS and other resource shortcomings.
Also see how we identify IT, IS and other resource shortcomings and ensure that their 'Fix-it' projects are aligned with the strategy of the business.
6.8. Additional aspects are required than just traditional project management.
DISCON Specialists in its approach to Programme and Project Management has extended its approach to not only include classical or traditional Project Management, but by also including additional Project Management aspects, specifically to be based on Business Architecture and Business Strategy.
7. What we should consider when looking at other tools:
A number of other factors you could consider when investigating the Rational toolset:
1. Depending on company need two Studios are available, Development Studio & Design Studio, and extra tools.
2. Not to say that a Studio will give all the tools needed - if an application is needed like Rational Rose or Soda then it is an extra cost and annual license fee.
3. Rational is only recommended for big companies that can afford it.
4. If a Company goes over 10 licenses they would need to employ a Rational Toolset that would constantly look at integration of all packages, implementation issues (constantly) and load new updates.
5. The Tool overall is very cumbersome, complicated and needs a huge training investment for every user.
6. Overall Rational is consultant driven and intensive like SAP.
7. Licenses are per CPU and a dedicated License Server must be implemented. This locks down the domain, if server is down everybody using RUP are unproductive.
8. There are initial procurement and annual licenses associated to Rational.
9. The tool relies alot on documentation (Word & HTML templates) and is very laborious - most of the time not necessary at all, but due to the prescribed methodology it is needed.
10. Buying the tool does not initiate a project right away and it has a very long ROI if any.
11. There are code-generating models but a big training investment has to be made before the full potential would be realized.
12. The steps that the methodology provides do not give any OO benefit or mathematical proven methods, by default.
8. How we provide methodology:
8.1. What differentiates our philosophy.
What differentiates our methodology from a tool approach like this is that we train your employees to utilize the methodology at the lowest rates available. There is no licensing required for the use of the methodology. The methodology is tailor able per project, per organization. Our consultants are available to initiate and participate on projects with you in a mentorship manner, if required. The consultant rate applicable here is again of the lowest available. Together with that our automated modelling toolset is deployed at your site at no extra license cost. In addition to that our methodology is integratable with other methodology techniques.
8.2. We have already integrated UML and others into our framework.
The utilization of the UML techniques, and other methodology techniques, are catered for, where they are applicable and should you choose to use them, within the context of our much larger methodology framework and philosophy.