Project Management Software
Specialists in Project Infrastructure
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:
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.
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.
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.
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.
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
Concepts that serve as a foundation for these criteria have emerged out of experiences in public sector practices
The following are a list of differentiators that can prove useful when evaluating service offerings.
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.
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:
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.
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 .
For this group of differentiators a set of coverage metrics could be used, showing the following traceability:
In order to establish traceability, some teams use Excel type spreadsheets where, as an example:
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.
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:
Change request analysis could be also simplified through the use of these metrics.
Level of Details
The level of detail refers to
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:
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:
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:
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:
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.
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.
David Hanslip Using IBM Rational RequisitePro to support a project responding to a Request for Proposal (RFP)
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