Author: Dmitri Ilkaev – Dan Meenan

Abstract

This paper describes how progress in the IT marketplace has changed the nature of the offerings provided by software development and consulting firms, and resulted in the need to define new or updated differentiators for their services. The paper presents some of the differentiators, mostly in the form of extendable metrics, and provides descriptions and rationale for use.

By differentiators here we don’t mean something totally unique that is offered by this particular company and cannot be duplicated by its competitors. It’s more about leveraging existing capabilities to create added value for potential or existing clients so that they can better position their organization in the marketplace.

Change in Market Place Differentiators

Analysing 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.

Programming Skills

For example, previously such skills as Enterprise Java, Portals, XML, and Web Services were once quite unique and difficult to find. 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 are easier to recruit on an “as-needed” basis.

Domain Knowledge

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

Additionally, with the increasing interaction between programmer’s and their clients, there has been an increase in programmer’s experience within specific business domains. This has resulted in a reduction in the need for a full-time domain expert. The role becomes more of a “nice to have” addition in order to provide improved validation of the deliverables and communication with the client. It is especially true on large, complex projects

Technical Architecture

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. An applications built on this architecture will be modular with a high degree of component reuse, and follow best practices in security, shared services and configurability. If they cannot provide these services they will simply not be considered as the viable candidate among other offerings in the market.

Industry Standards

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 there is an increasing use of industry standards in software development. Approaches like Rational Unified Process (RUP), and others such as XP, RAD, MDA, etc. are commonly used.

PMI, CMMI, Scrum, Six Sigma, etc., provide organizations with 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.

Personal Skills

Characteristics like excellent communication skills, commitment to success, attitude, and intellect are valuable components of effective client relations. They 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.

“Must Have” Differentiators

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

What are the Project Differentiators?

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

This paper discusses a new set of metrics based differentiators which can be used in the Business Development, Sales and 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
• Overall trends in IT marketplace.

The following are a list of differentiators that can prove useful when evaluating service offerings.

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 at describing the individuals on the team. They are described 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 a client’s comfort level with the project team. It illustrates that people they will be dealing with, are experienced, and that they are 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 and experiences for the proposed individuals on the project team.

Creating Metrics

In order to improve this approach, 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
• 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 is it just a collection of individuals who may have never worked together before?

The use of this approach to skills and project history based metrics will not only address this question. It can be extended to account for multiple roles and areas of the project where individuals will undertake work whilst 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. It can establish a kind of project team data mart. It can provide 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.

Relocation of the Project Team

In consulting, a commitment to move (or relocate) an entire project team to the client site could be another differentiator. It would however depend on the value the specific client places on having the entire team located locally. 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 Traceability

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 has already became a bible for the majority of project’s software development life cycles. This approach is much less popular when focused on business development and presale activities. Rational recommends 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 you would indicate functional requirements from an RFP
• In another column would be the features of the product or technology being offered.

While this approach allows for the requirements mapping, it works effectively for the static data, where no interdependences between different categories of requirements exist, and the data does not change.

Requirements Tools

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. They provide potential oral presentation material and a solid foundation for 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
• 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 and controlled
• The functionality of the solution
• The technology
• 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. Nor does it 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.

How the Estimate was Created

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 “X” number of resources and would take “Y” 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 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.

Project Estimating Tools

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 also freeware products as well Construx Estimate (limited license) and COCOMO software from USC. For a good listing you can go to http://www.laatuk.com/tools/effort_estimation_tools.html

Some of the estimation tools are bundled as part of other packages. Estimation capabilities are 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, Telecom, etc., and make adjustments based on the technology and programming language (or their combination) which are used in the project. They can take into account code reuse and implementation of the pre-packaged modules.

Integrating Estimation with Scheduling

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 and techniques in place to support effective project estimation, the real challenge is to provide accurate inputs so that you can generate 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
• Perform “if-then” analysis
• Assess 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 tools. 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 to the client 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, and 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

David Hanslip Using IBM Rational RequisitePro to support a project responding to a Request for Proposal (RFP)
http://www-128.ibm.com/developerworks/rational/library/5347.html

About the Author

Dmitri Ilkaev has almost twenty years of experience in software and technology development. He holds Ph.D. in Computer Sciences from Moscow Institute of Physics and Technology. Dmitri is the Chief Technologist at Tier Technologies (http://www.tier.com) in Scottsdale, AZ. He can be reached at DILkaev@tier.com

Copyright Project Perfect