Introduction
When going assessing new business opportunities, Information Technology (IT) companies try to present compelling differentiators to distinguish their offerings from their competitors, and establish the rationale why they would be the logical choice for any potential client to select them. By differentiators here we understand not something totally unique that offered by this particular company and can not be duplicated by its competitors, it's more of leveraging existing capabilities to create added value to potential or existing client to better position the organization in the marketplace. Analyzing current offerings in the software development and consulting markets, we could not help but notice that a lot of differentiators which previously made sense, no longer are valid or can sometimes even mislead a potential client.

For example, previously such skills as Enterprise Java, Portals, XML, and Web Services were quite unique and were difficult to find. However, these days most organizations that have been in the business of delivering IT solutions for more than 3 years would have a number of resources with these skills, as well as, a portfolio of successfully completed projects. Additional resources with the needed project specific skills would be easier to recruit on as-needed bases.

Another differentiator that is easily addressed is individuals with specific domain knowledge specific to the market segment. Theses Subject Matter Experts (SME’s) provide an important component, however it can be easily purchased by hiring extra resources with the specific business and functional experience. This is especially true in the past few years given increased layoffs and with those having reached early retirement marks seeking a "second" career.

Additionally, with the increasing interaction between programmer's and the clients, there has been an increase programmer’s experience within specific business domain, reducing the need for a full-time domain expert on the time, making the role more of a "nice to have" addition to provide improved validation of the deliverables and communication with the client, especially on large, complex projects.

Similar situation exists with technical architecture. In order to be competitive, all players in the market will propose an open, scalable, n-tier architecture based on the industry common standards and protocols. The applications built on this architecture will be modular with high degree of component reuse, follow best practices in security, shared services and configurability. If not, they will be simply not considered as the viable candidate among other offerings in the market.

Even within the areas of software development life cycle and project management methodologies, there are not clear differentiators beyond the experience the firm has with industry standards. These days with the increasing use of industry standard in software development approaches like Rational Unified Process (RUP), and other approaches such as XP, RAD, MDA, etc. are commonly used.

PMI, CMMI, Scrum, Six Sigma, etc., provide organizations and approaches that promote rigorous and consistent practices in project management, quality, and software development. As such, it is not a difficult for to team to demonstrate their command of sound software development, project management and quality approach to potential clients.

Characteristics like excellent communication skills, commitment to success, attitude, and intellect are valuable components of effective client relations, and reflect the underlying culture of an organization and the values of their staff. However, these attributes may not be easily assessed during initial meetings with a perspective client, and as such are not really sound differentiators. They only provide a differentiation as reflected in the soundness of the references from clients through the success they achieve and their focus on the client's goals and objectives.

It is really the "must to have" group of components which could be considered as enhancement to the base qualifications the form true differentiators. This group needs to be redefined to reflect the current state of technology, project management, overall industry expertise and trends of IT market.

IT market maturity has resulted in the invalidation of the previously compelling company's or project's differentiators, and created a strong need in having new or updated forces for organizations to redefine their place on the modern market and clearly position their offerings.

This paper discusses a set of new set of metrics based differentiators which can be used in the business development, sales, Request for Proposal (RFP)/Proposal related activities. These differentiators and associated metrics can be used by both the firms seeking new engagement and organizations assessing offerings from competing companies. Concepts that serve as a foundation for these criteria have emerged out of experiences in public sector practices within Tier Technologies, analysis of the close competitors, and overall trends in IT marketplace.

Differentiators

Project Team
In a number of situations, especially those dealing with a proposal, the project team is initially represented as a collection of resumes and overall statements aimed to describing the individuals on the team by years experience in the selected areas, a list of past successful projects relevant to the current one, references, etc. This is an important set of unstructured information which normally increases client's comfort level with the project team. It illustrates that people they will be dealing with are experienced, and that they knowledgeable in their defined subject area. In a number of instances attempts have been made by the potential client to take the "unstructured" information from the resumes other related information and "structure" it into spreadsheet type format. This permits effective summarization and comparison of the most important skills, experiences for the proposed individuals on the project team.

In order to improve this approach, and make it reusable and more efficient for the client an N-dimensional metrics can be used showing, (per person), the most critical business and/or technical skills related to the specific project, the duration on similar projects where these skills have been used, and how recent these projects were. One criterion which is often overlooked is the information about the team as a whole. How much experience does the team have working together, or it's just a collection of individuals from where they may have never worked together before.

The use of this approach to skills and project history based metrics will not only address this question but it can be extended to account for multiple roles and areas of the project where individuals have work, stressing the flexibility of the staffing model. To add more dimensions it can take into account additional specifics of the past projects (for example, off shore development, multiple geographically dispersed teams, project success or failure, current state of the developed system, etc.).

Such N-dimensional spreadsheet, being prepared and populated by a consulting organization, can be used by a perspective client; establishing a kind of project team data mart, providing not only quantitative confirmation about proposed related skills and experience of the proposed project resources, but allowing a client to work with the data and make their own assessments.

In consulting, a commitment to move (or relocate) an entire project team to the client site could be another differentiator. It would depend on the value the specific client places on having the entire team local. Additional, the real benefits to be gained would need to be mapped against the potential costs (relocation, potential loss of key personnel). To account for this option, additional criteria would need to be added to our N-dimensional metrics which will indicate team members staying locally, and those traveling, along with their projected availability for the client.

Requirements Coverage
The activity of requirements traceability is becoming a staple in effective management of projects. Mapping requirements to the use cases and extending functional requirements and software specifications to the technical design artifacts, and even linking them to the test cases had already became a bible of the majority of project's software development life cycles. However, this approach is much less popular on when focused on business development and presale activities; even though Rational does recommend the use of requirements traceability as a component of responding to Requests for Proposals (RFP), see [1].

For this group of differentiators a set of coverage metrics could be used, showing the following traceability:

• Functional requirements and use cases
• Requirements (not necessarily only functional) and technical design
• Functional requirements and features/functions of the available technology or product

In order to establish traceability, some teams use Excel type spreadsheets where, as an example, in one column would indicate functional requirements from an RFP, and in another column would be the features of the product or technology being offered. While this approach allows for the required mapping, it works effectively for the static data, where no interdependences between different categories of requirements exist, and the data does not change.

In situations where requirements can change, and such changes can easily affect other requirements, a robust requirements management tool like Requisite Pro, DOORS, Caliber, Reconcile, etc. should be considered. These tools not only help generate a recommended coverage metrics with the necessary quantitative measures, but the artifacts collected with the help of these tools will provide a significant value add to the proposal, potential oral presentation, and provide a solid foundation on-going requirements traceability once the project is imitated.

Additionally, these metrics can provide benefits to both the client and consulting organization in reviewing the requirements, determine their relationships, the criticality and influence on other requirements, and the technical design. Change request analysis could be also simplified through the use of these metrics.

Level of Details
The level of detail refers to the granularity of information presented about the manner in which a project will be managed, controlled, the functionality of the solution, the technology, and how they relate to enabling the business objectives and enterprise architecture of the organization. This, however is the least measurable criteria, and in general, it would be best bundled with other differentiators discussed in the next section. That being said, the importance of these criteria can result in several potential benefits:

• Improves client’s comfort level
• Demonstrates knowledge and expertise of the company and the project team
• Provides base data to be used in the project estimates

Without sufficient granularity in the information, it will be difficult to construct a plan that will provide the specific task detail necessary to support effective planning, let alone enable the next group of differentiators.

Since one of the objectives of this paper is to provide guidance for the future projects and business development activities, specific approaches for defining ways of handling tasks should be used. For example, if there is an available API, technology, or other service which you propose to use–then say so. The result will provide a solid foundation for planning and for accurate effort estimates. Another example would be detailed UML and ER diagrams, benchmarking results, scaling rules, etc.

Details, Quality and Validation of Estimates
This is the most challenging and controversial part of the sales effort. It is aimed at addressing the most critical questions: How much will it cost? How long will it take to build the new system or solution? Based on the analysis of several proposals and the client feedback on those proposals, a simple project schedule with a high level work breakdown structure is not sufficient to provide a convincing projection on task effort estimates, or provide a sound basis of estimate.

More and more during presales activities consulting firms are asked to validate their estimates, and provide a greater level of detail on how these estimates are derived. In other words it is not sufficient to provide the set of tasks with the "x" number of work hours efforts associated with each of the documented tasks.

In order to stay competitive, it is important to show the base assumptions, model, and calculations used in constructing the estimate. For example, in the past it may have been sufficient to state that task related to the integration of a new system into an existing infrastructure would require that "x" number of resources and would take "x" amount of time to perform.

In today's market it is essential to provide effort estimates, broken down per interface, and support those estimates with calculation using functional or Internet points, use cases and actors, number of lines of code or other quantitative parameters being used by the estimate model. This supports the documentation of assumptions on which the estimates are based.

Obviously, such estimates can only be possible when all functional and technical details are well clearly defined. That is why it is valuable to provide both a significant level of details, as well as, the basis of estimates together in a process the presents a realistic picture of the project life cycle, required resources, and estimated timeframes.

With that being said, it is easy to understand why a number of specialized estimate tools are playing a more important role in the current project environment. There are a number of tools commercially available, such as SLIM, CostXpert, Duvessa, ScopeIT, there are freeware products as well Construx Estimate (limited license), COCOMO software from USC.

Some of the estimation tools are bundled as the part of other packages, with estimation capabilities built into the Enterprise Architect from Sparx Systems, or a similar tool recently added to Borland’s Caliber RM.

These tools provide flexibility in analysis by providing different estimation models (use cases, functional, feature or Internet points, number of lines of code, object metrics, etc.); and address multiple software development methodologies, (RUP, RAD, waterfall, etc.). They also can address different industries, such as financial services, and telecom, etc.), and make adjustments based on the technology and programming language (or their combination) which are used in the project; along with the code reuse and implementation of the prepackaged modules.

Frequently estimation tools can be used with project scheduling tools to provide a holistic and uniform vision of the project life cycle. With the tools techniques in place to support effective project estimation, the real challenge is to provide the accurate inputs to obtain realistic project estimates. The underlying assumptions and details related to the estimates can be used by both the client and consulting organization to conduct reality checks, perform extra validation on assumptions, performing "if-then" analysis, and assessing the criticality of certain tasks and their sequence on the overall scope of the project.

Conclusion
The maturity of IT marketplace requires changes in the differentiators used by software development and consulting companies to seek a competitive advantage. This paper outlined new or enhanced metric-based differentiators, describing the following categories:

• Project Team: extendable N-dimensional metrics showing staff skills, experience, past projects and a relevant history of working together as a team. For a consulting engagement taking place at a client site, an additional parameter can be added to the metrics showing members of the team residing locally, or traveling–with projected availability to support client needs and critical project activities.
• Requirement Coverage: set of metrics obtained through one of the standard requirements management tool. These metrics provide traceability between requirements and use cases, project requirements/specifications and technical design and mapping of the project requirements against features of the product or technology if proposed for the current project. The proactive use of this in responding to a client’s RFP provides not only assurance that all of the stated requirements have been addressed, but demonstrates the client the knowledge of the tools and the importance of the activity. It also provides a sound foundation for effective requirements traceability from the inception of the project, improving scope management and reducing project risk.
• Level of proposal details: provide the foundation for accurate project estimations, and when coupled with the use one of a robust estimation tool, provides both confidence in the projections, but also facilitates effective planning, tracking and oversight, and risk management. This may be the most critical differentiator.

Differentiators can be efficiently used by the software development and consulting companies to position their projects and project teams in the market place, and by clients to properly assess and compare the solutions and services offered.

References
1. David Hanslip Using IBM Rational RequisitePro to support a project responding to a Request for Proposal (RFP)