Risk Management

Sound risk management regimes help people avoid disasters, rework and stimulate win‑win situations on software projects. Some of the benefits resulting from implementing risk management include:

• preventing problems before they occur;
• improving product quality;
• enabling better use of resources; and
• promoting teamwork.

  

Function	Description
Identify	Search for and locate risks before they become problems.
Analyze	Transform risk data into decision‑making information. Evaluate impact, probability and timeframe, classify risks, and prioritize risks.
Plan	Translate risk information into decisions and mitigation actions (both present and future), and implement those actions.
Track	Monitor risk indicators and mitigation actions.
Control	Correct for deviations from the risk mitigation plans.
Communicate	Provide information and feedback, internal and external to the project, on the risk activities, current risks, and emerging risks.Note:Communication happens throughout all the activities of risk management.

Enterprise Architecture and Change Management

When an organization embarks on Enterprise architecture, there is no doubt that senior management is looking for a change. Change is a natural by-product of Enterprise Archiecture. Effective Change management is required for the success of EA. This is where people skills of an Enterprise Architect are put to test. More often, EAs get bogged down in details, processes of EA implementation and tend to pay less attention to change management.
I admire Mike Walker a lot and agree with his assessment of how EA can bring about change in an organization. Quoting from his blog ( a must read for any EA)
http://blogs.msdn.com/mikewalker/archive/2007/07/03/can-enterprise-architecture-be-a-catalyst-for-change-management.aspx

“Enterprise Architecture (EA) can definitely be a catalyst for organizational change management. EA methodologies include processes and tools for managing both the people and the technology sides of an organizational. EA helps in raising and recording of architecture changes, assessing the impact on the enterprise, cost / benefit analysis, risk management, supportability concerns, alignment with business objectives and facilitates justification and obtaining approval from both IT and the business. “

Broadly speaking there are four change management strategies that can be employed. More often in real world, you would employ a combination of the four strategies, depending on organizational realities.

Strategy	Description
Empirical-Rational	People are rational and will follow their self-interest — once it is revealed to them. Change is based on the communication of information and the proffering of incentives.
Normative-Reeducative	People are social beings and will adhere to cultural norms and values. Change is based on redefining and reinterpreting existing norms and values, and developing commitments to new ones.
Power-Coercive	People are basically compliant and will generally do what they are told or can be made to do. Change is based on the exercise of authority and the imposition of sanctions.
Environmental-Adaptive	People oppose loss and disruption but they adapt readily to new circumstances. Change is based on building a new organization and gradually transferring people from the old one to the new one.

Factors in Selecting A Change Strategy

Generally speaking, there is no single change strategy.  You can adopt a general or what is called a “grand strategy” but, for any given initiative, you are best served by some mix of strategies. 

Which of the preceding strategies to use in your mix of strategies is a decision affected by a number of factors.  Some of the more important ones follow. 

·         Degree of Resistance. Strong resistance argues for a coupling of power-coercive and environmental-adaptive strategies. Weak resistance or concurrence argues for a combination of Empircal-Rational and normative-reeducative strategies. 

·         Target Population. Large populations argue for a mix of all four strategies, something for everyone so to speak. 

·         The Stakes. High stakes argue for a mix of all four strategies. When the stakes are high, nothing can be left to chance. 

·         The Time Frame. Short time frames argue for a power-coercive strategy. Longer time frames argue for a mix of empirical-rational, normative-reeducative, and environmental-adaptive strategies. 

·         Expertise. Having available adequate expertise at making change argues for some mix of the strategies outlined above. Not having it available argues for reliance on the power-coercive strategy. 

·         Dependency.  This is a classic double-edged sword.  If the organization is dependent on its people, management’s ability to command or demand is limited.  Conversely, if people are dependent upon the organization, their ability to oppose or resist is limited.  (Mutual dependency almost always signals a requirement for some level of negotiation.)

Enterprise Architecture and Communications Management

Communications Management

As mentioned in my previous post, effective communication is part of the overall plan for management of the Enterprise Architecture.

A communication plan should be developed to outline what gets communicated to whom and who is responsible for the communication. This plan should remain a living document, and as such should be updated on a regular basis to reflect new stakeholder groups, new information needs, and new communication strategies.  It is important that the Enterprise Architecture Program be held accountable for implementation of this plan, and that the Enterprise Architecture Committee regularly review implementation progress with the Program Director

For example, what information gets communicated to the Vendors, System Integrators, partners, even for that matter competitors with whom you may be working on a collaborative project?

 Sponsor Meetings – regular meetings should be established with sponsor to ensure they are aware of project status. Frequency should be based on project size and turnaround time. The larger the project, the more infrequent (monthly) the meetings should be. Format of agenda should be consistent.

Team Meetings – regular meetings should be established with project team to ensure tasks completed, that they are aware of important deadlines etc.Agendas should be developed and minutes should be completed with action items.

Point of Contacts – POCs should be identified for major groups (i.e. IT, testers, business areas etc). The POC is responsible for ensuring their area is aware of information relating to them.

This communications plan is based on the following principles: 

Principle	Corresponding Plan Features
Communication strategy and communicators must have credibility with audience	·         Ensure plan is followed to the extent resources allow ·         Ensure information is accurate and timely (no “shelf-ware”) ·         Incorporate learning back into the plan on a regular basis
Favor strategies that involve the audience over strategies that only inform them	·         Review plans, status reports, and architecture elements in face-to-face meeting settings ·         Encourage feedback and interaction ·         Make sure every communication tool includes a feedback/contact mechanism
Favor face-to-face communications over remote, indirect, or electronic communications	·         Review plans, status reports, and architecture elements in face-to-face meeting settings ·         Encourage feedback and interaction
Avoid information “overload”	·         Tailor communications to the stakeholder group ·         Only communicate as often as the stakeholder group is ready to be involved and act on the communications
Use communications strategies to manage audience expectations	·         Include workplan and release plan in communications ·         Be clear about when decisions will be made
Respect the fact that architectural information is inherently inter-linked; make sure information is stored in one place (avoid redundancy and associated maintenance burden)	·         Leverage Web presentation technologies whenever possible ·         Choose repository solution that facilitates common storage and inter-linked web presentation
Support balance between making decisions in a timely fashion and permitting adequate feedback to promote sound decision-making	·         When presenting materials for stakeholder review, establish a fixed review deadline beyond which “silence indicates consent” ·         Ensure that review period is adequate ·         Target review (and direct follow-up) for key stakeholders on each issue

Enterprise Architecture and related fields

With due respects to the original author and my professors at UVA’s McIntire School of Commerce who introduced me to enterprise architecutre and the definition, I like the following defintion“Enterprise architectural approaches include EA principles, EA frameworks, EA methodologies, EA processes, EA tools and techniques, and EA body of knowledge. Enterprise architectural approaches emphasize aligning elements, harmonizing relationships, optimizing locations, streamlining interactions, coordinating timing, and connecting past, present, and future to make the entire enterprise more productive, efficient, and in harmony.”From the same setting, I learnt undersanding of  following fields is crucial for the success of an Enterprise Architect.  In practice, I have not found any other field that can be added to the list. The list below in my opinion is exhaustive.

• Strategic planning
•  Enterprise management
•  Business management
•  Finance management
•  Enterprise resources planning
•  Business process engineering
•  Information management
•  Information Technology management
•  Asset management
•  Security management
•  Change management
•  Investment portfolio management
•  Compliance management
•  Program management
•  Project management
•  Performance management
•  Quality management
•  Risk management
•  Record management

In my future blog postings, I will try to cover above bulleted items using my experiences. As one can notice success of any Enterprise Architecture is dependant on many factors, I see “Human” factor as one single factor that probably affects success of any enterprise architect.

Enterprise Architecture via Zachman’s model

Zachman’s model is really a framework designed to assist in the development and management of comprehensive and aligned Enterprise Architecture models 

Essentially it is a classification schema based on questions (what, how, where, who, when and why) and comprised of 36 cells.  These cells represent all levels in the organization (operational and strategic), all players in the architecture (owners, builders, stakeholders, vendors, users etc) and all components (models, data, networks, application programs, security protocols, business goals and requirements, workflows and overall strategies).

Zachman’s rationale for developing the framework in the first place was because of the increasing size and complexity of the implementation of information systems – therefore requiring some logical construct (or architecture) for defining and controlling the interfaces and the integration of all components of the system

The framework  is independent of any one methodology or tool, and the organization determines how best to use it in the development process. One of Zachman’s key messages is that systems architecture depends on the perspective of the person involved with it be they a developer, owner, or analyst

If you are:	Then you probably think architecture is:
A programmer	A structure chart
The database administrator	Data design
An analyst	A data flow diagram
A planner	Some combination of entity/relationship diagrams and/or functional flow diagrams
The communications manager	The business logistics infrastructure and/or the distributed systems architecture
An operations manager	The system architecture
A network administrator	The network architecture
A program support representative	Detailed data and program descriptions
A computer designer	Machine language
The president	Entity classes, process classes and/or a map

Business Process Architecting

Business process models describe how a business works, or more specifically, how they accomplish missions, activities, or tasks.  A single model shows how a business accomplished a single task.  It would take many process models to fully detail the “hows” of most real world enterprises.A single process can be quite involved.  It can consist of many actors (people, organizations, systems) performing many tasks.  In order to accomplish the overall task, the actors must complete specified sub-tasks in a coordinated manner.  Sometimes, these sub-tasks can be performed in parallel.  Sometimes they are sequential.  Some processes require repetition of sub-tasks.  Most processes have decision points where process flow can branch depending on either the condition of the system or the particular process execution.  In cooperative processes actors must pass information.  This information transfer can be the trigger for an actor to begin a sub-task.  Other triggers are possible, such as time or interrupts.  Some processes are ad-hoc.  That is, the sub-tasks do not have well defined triggers.  Actors may not need to complete all of a subtask before they or another actor start work on another dependent subtask.  Finally, a process can look differently when described from the viewpoint of different actors.  A business process modeling methodology needs to be able to represent these different aspects of a process description.  A good methodology will present the representation in a manner that is easily transferred into the tacit knowledge of the viewer.

Process Modeling Benefits
There are many potential uses of process models:
(a) Program planning
(b) Baseline for continuous improvement
(c) Knowledge retention and learning
(d) Process visualization
(e) Training
(f) Framework for metrics
(g) Compliance, audit, and assessments
(h) Program execution

  

There are three different modeling strategies that can be employed: 

 1.Process-oriented
2.Resource-oriented
3.Data-oriented.
 Process-oriented strategy starts with the workflow of an organization (i.e., the behavior).  The resources or “roles” within an organization are modeled first in the resource-oriented approach.  The data-oriented strategy starts by first describing the data items that comprise the inputs and outputs of the business process

Who Is An Architect And What Do They Do?

Who Is An Architect And What Do They Do?
Below are six major “parts” of constructing an Enterprise Architecture that an Enterprise Architect would be responsible for:
•  Identify the current state of how IT is currently being used in the organization, what technologies are being used and how they are deployed along with the business value that IT is providing.
•  Examine and document any current initiatives currently being planned or implemented that involves IT resources.
•  Document the future state if the current plans execute and business continues as usual.
•  Document the desired future state, where the business would like to be from an IT perspective.
•  Document the “gap” between the two future states. This is the difference between where the IT organization is heading and where it would like to be.
•  Construct a list of projects and initiatives to put the IT infrastructure back on track towards the desired future state. This transition plan will attempt to close the gap previously identified.
          This is not necessarily a linear process, however, each phase of this process may trigger changes in previous phases. Also, the constant changes in the business environment will alter the content and priority of many of the IT projects . Equally important to keep in mind that this is a continuous process whereas these steps are repeated, or the architecture be at least reviewed on a regular basis. One obvious reason for this is that technology is changing rapidly and what might make sense one day might not make sense the next. Other reasons are more business focused, such as the changing strategic plan of the business, competition, laws, regulations, and economic pressures. During hard financial times, taking risks, especially in the IT area, may not make as much sense as it would during times of economic booms. All of these factors must be taken into consideration as the Enterprise Architecture and the resulting architecture plans are reviewed.
An Enterprise Architecture team is often made up of three areas:
•       Business Leaders
•       Business Unit or Specialty Architects
•       Enterprise Architects
          First, having a business leader heavily involved in enterprise architecture is necessary because only they understand the real information needs of the company and how they fit in with the business plans. This may be an executive, CIO, VP, or similar high-ranking individual. They may also act as a “sponsor” type of role in developing and presenting the plans to upper management. This is a very important role. Irrespective of the quality of the Enterprise Architecture, the success of the effort is primarily dependent on the support and enforcement of management .
The following picture demonstrates the connection between business drivers and IT infrastructure:                   
 

Executives and managers can bring the business drivers to the table while the IT experts identify the appropriate IT components.
          Next, there are the architects or planners of individual business units. This group may also be specialty groups for specific IT projects or technologies that have their own planning teams. These are the people who know their area the best and can provide the necessary insight. Often, these may be the same people who do some of the implementation. Finally, the enterprise level architects consolidate the business information and goals with the individual business units and specialty groups. Enterprise level architects may also deal with other high level architects in the areas of data management, application development, or infrastructure.
          Once data is accumulated from all areas of the business and technical areas, then the architect’s job is to define all of the major elements, interfaces, and partitions between the different areas. Even though much of the information will have to be found at the departmental level, the architect should take a enterprise view of the organization during the analysis. Priorities and responsibilities of individual departments may change over time, but the overall nature of the organization should be relatively stable (Miller). Depending on the organization, further responsibilities of the architects may included managing the lifecycle of major groups of technologies, procurement of infrastructure level technologies, methodologies for design and documentation, standards for lifecycle development and operational processes, training needs, data architecture (naming standards, storage, etc.). Creating standards between different areas of the company will ensure that applications can be effectively integrated with each other.

Zachman’ framework provides a basic structure for organizing a business’s architecture through dimensions such as data, function, network, people, time, and motivation. The last three dimensions were more recent additions to the framework. Each dimension is then described through the perspectives of different players in business’s IT organization such as the planner, owner, designer/architect, builder, subcontractor, and user. This very technical and rather theoretical framework is rarely used “as-is” rather it is the basis for other, more practical applications of Enterprise Architecture . The Zachman Framework should be something that any IT Architect should at least be familier with, and to understand some of the questions of who, what, when, why, and how – and from who’s perspective are the answers. Answering these questions will be beneficial in producing a complete Enterprise Architecture. Another advantage of the Zachman’s Framework is the idea of classification. Classification allows you to “eat the elephant one bite at a time” and identify different pieces of the IT infrastructure through different perspectives in logical pieces. By doing this, you have a much more manageable list of components to analyze.
            A final part of the architects job involves actually using the architecture that they have created. Communication is probably the biggest part – an architecture isn’t any good if the other managers and technical designers in the company are not aware of it. By educating these people, and showing them roadmaps for technology, they can make better decisions. The architects should be responsible for dealing with exceptions and helping to minimize their impact on the stability of the infrastructure.
       Despite much industry wide concern about outsourcing, these enterprise architect jobs are not likely to move outside of the organization. The type of business insight, longevity, and systems thinking are hard to find in a typical IT outsourcing arrangement. As important as Enterprise Architecture is to a company, having stability in this role is crucial.

Why Should An Organization Consider Enterprise Architecture?

Why Should An Organization Consider Enterprise Architecture?

The role of IT in organizations is changing. In the past, IT was a cost center – it didn’t add to the bottom line, nor did it help gain a competitive advantage. The best that IT could do was reduce costs. However, in the past 10 years, CEOs are realizing that that IT can indeed directly increase revenue. From 1992 to 2002, the percentage of IT investments that grow revenue within a corporation will rise from 30% to an estimated 80% . This is significant. IT is now more than just overhead for a corporation, it is a business asset that much be controlled, monitored, and managed like any other asset such as buildings, factories, or machinery . Enterprise Architecture also allows a company to treat all of its IT assets as a portfolio rather than individual items. Just as you manage a stock portfolio for certain attributes, such as risk, etc., IT infrastructure should be managed the same way.
          Enterprise architecture is the way to strategically manage a company’s investment in IT. In times of industry consolidation, mergers, acquisitions, spin-offs, drops in the stock market, and a rougher economy, IT enterprise architecture might be the first thing to take a back seat to more pressing business problems. However, this is the worst thing a company can do. At times like these, a company needs to be able to quickly realign their IT strategy with their changing business strategy. If a corporation doesn’t have a well documented IT strategy, as an enterprise architecture, then these changes are going to be very hard to make.
          Some of the other benefits in having a mature enterprise architecture lie in several areas. First, by having a well established idea of what infrastructure is going to be needed in a company, efforts can go into building it, and building it with growth in mind. Then, as specific business applications wish to utilize this infrastructure for their needs, it is already built and ready to go. Standards are another area that, while may seem as a hindrance to some, can be enforced by having a documented enterprise architecture. When a company supports standards, especially in the IT arena, support costs are drastically lowered, allowing the IT staff to do one thing, and do it well vs. having to support a wide-variety of systems, but doing none of them particularly well.
          Having an enterprise architecture can also help a company retain talented staff by being able to better focus training and other employee development funds, allowing the IT staff to focus on services for their internal “clients”, reduces the number of technologies the support staff has to support, and helps better focus the employees efforts, making their job descriptions much more clear.
          As was previously mentioned, creating and maintaining an Enterprise Architecture is an investment for a company to make, with the payoff occurring sometime in the future. The goal is to be able to deliver the right information to the right decision makers at the right time.
          70% of large companies are currently too busy fighting fires, solving short term tactical solutions and not developing long-term strategic plans. Just as planning your business strategy takes a different mindset, so does developing an Enterprise Architecture. Often a company’s culture and current employees are more focused on the project at hand rather than looking at their environment from a enterprise standpoint. Because of this, simply trying to “make” your IT department think strategically will most likely fail. When Enterprise Architecture is run as a program, with dedicated staff and an on-going review of the plans, a corporation is much more likely to have the efforts supported and accepted by the business and IT staff.
          Once the architecture is defined, then individual business units merely have to see where they “plug-in” to it to get their work done. For example, if the architecture plans says we are going towards a unified ERP solution, such as SAP, and a business unit wants a payroll system, maybe looking at SAP is a good start. Or if Unix systems are the “standard”, then that part of the design is already done. Finally, if the architecture defines that employee portals are important to the company to boost productivity, then a project to put a portal component together will be approved much faster than a standalone system would.
          Having an Enterprise IT Architecture is also a valuable tool in reaching the 2nd and 3rd level of the SEI’s Capability Maturity Model where the model calls for repeatable tasks and a defined organizational mission (Cecere). An Enterprise Architecture forces an organization to document their IT plans and align them with the business needs. Once the plans are in place, and standards are set, it is much easier to use the same methodologies, if not the same technologies to deliver business solutions. Business leadership is critical in making this move, and with enough committment, a well defined archiecture can easily push a business to the next level on the SEI model (level 2 or 3) .
          Architectures are not set in stone. However, if a business case is made for something that deviates from these standards, these plans are not show stoppers, merely a reason to stop and think about it. It is this “stopping and thinking” that shows where an Enterprise Architecture adds value. It gives the IT decision makers a baseline of the current and future environment so they can decide how (if at all) this new project fits into their architecture plans and how well it will work as the plans mature. It is up to management to decide whether or not to pursue this deviation from the standard. Or perhaps it is a signal that the standard needs to be revisited. Again, as was previously mentioned, the architecture plans need to be flexible enough to allow these kinds of changes as the technology and the business also changes.

What Is Enterprise Architecture?

What Is Enterprise Architecture?

 The first phase of the Systems Development Life Cycle (SDLC) is called Project Identification and Selection. It is in this initial phase that potential projects are identified and ranked. Then particular projects are chosen for further investigation, such as a more in-depth cost benefit analysis, or for implementation. So, what criteria is used to determine which IT projects are going to be pursued or discarded? If a project is to be pursued further, what technology will be used to implement and what base infrastructure is needed? These are the answers that an Enterprise Architecture can answer. Known by a variety of other names such as Information Architecture, Application Architecture, Business System Architecture, Enterprise Wide Technical Architecture, the basic process is the same – to develop a high level plan of how IT will meet future business problems. To briefly define each of the above mentioned “subsets” of IT Planning:
•  Information Architecture – very similar to Enterprise Architecture, but focuses more on the application and data aspects of an IT system. Often includes the Application Architecture (mentioned below) and the corporate data model.
•  Application Architecture – highlights the data flows between applications in a integrated information system.
•  Business System Architecture – a mix of the strategic plans for both IT and business resources. It is normally in pictorial form and used for high-level planning.
•  Enterprise Wide Technical Architecture – Another name for Enterprise Architecture, that better stresses that technical components as well as the infrastructure components of EA. 
  A common word in each of the individual components above is architecture. In this context, an architecture is merely “a set of shared definitions and constraints that are expected to effect a time, cost or risk reduction in future application development or operations” (Gartner – One IT Architecture…). The concept of an architecture is then applied to individual components of a company’s IT infrastructure, or taken all together, covering the entire enterprise. Each of the components mentioned above complement each other to form a common goal – effective and efficient IS planning.
A corporation of any size is going to spend a considerable amount of energy preparing a strategic plan for their business. Corporate strategic planning is where a corporation takes their current business environment and decides where they want to be in the future. They then construct a strategic plan on how to get from the current to the future state. A very analogous process can be applied to Information Technology – where the current infrastructure is examined, then the desired future architecture is laid out based on both the business plans as well as what is known about future technology. A set of projects is then constructed to achieve this goal. It is important that both business needs and technical needs are considered. Upgrades, replacements and improvements can’t be performed for technology’s sake unless there is a business need for it. Conversely, it wouldn’t make a lot of sense to built complex business processes on top of obsolete information technology infrastructure.
 

 Traditionally, problems are identified and a project is initiated to solve that particular problem. A planning-based approach looks further into the future and seeks to find a solution to the problem both as it exists today and into the future. This is particularly important for projects that span multiple departments or business units in an organization or many organizations. Also, as IT costs are becoming a larger and larger piece of the budget, the cost of an IT “mistake” is more closely scrutinized. Internet and E-commerce applications and their associated technology are rapidly growing. An organization may outgrow a specific solution but a strategy is more long term. Granted, there are times when a tactical, short-term solution is the best approach to address a very specific, immediate need. However, it must be pointed out to the business leaders that this is the approach being taken, and the short term gains may be offset by future support costs, conversion costs, or other implications of not working within a well-defined strategy. 
 Building an IT strategy based on a specific architecture can be considered a good investment – spend the time today for a payoff in the future. Or it could be considered a risky “bet.” Whether or not it is considered a “bet” or an “investment” relies on the level of predictability of the environment. A limitation of an architecture is that it relies on being able to predict the business needs into the future, and the basics of the technical needs. For example, it is probably a pretty safe bet that a company is going to want to share files and printers well into the future. They are also going to be able to want to communicate effectively with their suppliers and retailers. If the exact technical requirements (of these business requirements) were known, then all that is needed is a design, not an architecture. However, the architecture is going to describe these requirements at a higher level – such as the type of programming languages (e.g. object oriented) or Intel hardware (vs. Sun). However, the less certain about the future environment, the shorter the life span of the architecture and it will have a more narrow scope. In highly volatile environments, maybe the architecture is only good for a year or two, but constantly revised each year for the next two (Gartner – One IT Architecture…). 
  Using the term “strategy”, especially when discussing the development of an Enterprise  Architecture, can be confusing. A strategy and an architecture are relatively analogous terms. However, an architecture is often thought more of as a static picture that you draw on the wall. A strategy is more like putting the architecture into motion, defining not only what is to be accomplished, but how it is going to be accomplished.

  IT architecture is analogous to a homeowner discussing high level plans for a house with an architect. After the plans are made, the architect or the builder (designer) can make tactical changes later on to meet other requirements, but the overall framework will stay the same. The same thing applies to IT. An Enterprise Architecture is a high level planning guide for building the infrastructure out. It has to be flexible enough, however, to accept minor changes on down the road.

Competitive Advantage as a factor in selecting CMS vendor

Over the course of years, I have learnt to use competitive advantage as one of the factors in selecting any vendor. Below is the methodology I follow for selecting a CMS Vendor. Remember apart from Competitive advantage there are many factors one need to consider like TCO (Total cost of ownership), Customer support etc.What are two new features / tools / CMS advancements / acquisitions is your company cooking up that would keep you ahead of your competition for the next three years? What is the difference between your tool / solution and Free tools? Please share your top five features that are different from Alfresco (Open source) and why? How many new customers acquired the proposed system last year? In the year before that? What are your competencies in regards to integrating ECM 2.0 features (blogs, wikis, distributed, location unaware content etc). Can your solution work with Rich Media?  When was the software first developed and installed? When was the last major release or upgrade? When is the next major software upgrade planned for this system? Briefly, what will be new?  Are all software upgrade costs (e.g. custom programming, installation, training) included in support fees? If not, explain. Will your company guarantee in the contract that the software will comply with all current and future federal and state mandates? Vendor’s experience with projects that are in similar scope or nature as ours, longevity, financial viability, and stability in the industry along with qualifications of key personnel need to be considered.  Does the vendor generate enough cash flow from operations to support continued investment in development and support?  We need a vendor that will continually invest in product development, enhancements and customer support. Ask the vendor to see their product roadmap and R&D spending as a percentage of revenues/costs. Is the vendor really focused on web analytics? Some vendors have numerous products for multiple industries. In some cases, the vendor may “starve” the development of one product to “feed” another. An audited profit and loss statement and balance sheet for Vendor’s last 3 fiscal years.  If a company is privately owned, this information need to be asked otherwise such information is available in SEC filings. Also, of interest would be significant transactional events in the past 5 years, such as: bankruptcies, mergers, acquisitions, initial public offerings (IPOs).