A Comparative Analysis of SQL Server Reporting Services and Crystal Reports

Posted by Sambeet Patra under .NET Software Development, Software Architecture, Software Development Platforms, e-Business Software Solutions

The objective of this post is to present differences between SQL Server Reporting Services (known as SSRS) and the Crystal Reports suite. Since it is impractical to identify the “better product” without the context of a specific deployment scenario, I will focus on laying out the high level differences and let the readers draw their own conclusions.

(A) Product Maturity

Crystal Reports has 11 major releases and it is currently at the XI version. Since the early conception, the product has been focused on end to end reporting needs and has matured comprehensively over the last few years. There is a general misconception about the common issues with Crystal Reports especially in the .Net community. Many people do not realize that the embedded crystal reporting features in Visual Studio .Net 2003 was a limited edition of Crystal Reports 9 which has been out of date for a number of years now. The newer versions have matured significantly and provide features to seamlessly integrate with .Net applications.

SSRS, on the other hand is only 2 versions old. The first version was released in 2004 as an Add-On to SQL Server 2000. However, there are significant feature expansions in the next release [SSRS 2005]. While this product is relatively new, Microsoft had the advantage of analyzing the existing reporting solutions in the market and implementing the most sought after features in SSRS.

(B) The Product Suite

Crystal Reports suite has 3 main components. The designer interface allows users to design report layout. The server is the hosting environment for the reports and it helps manage / schedule reports. The suite provides extensive library to integrate with the various development platform.

SSRS, in contrast, is a .Net based reporting system. If you do not want to work on .Net platform, SSRS is not the right solution for you. SSRS has a design interface integrated into Visual Studio .Net. The Report Server hosts reports and the report manager is used to manage / schedule reports and the related data sources.

(C) Licensing

Crystal Reports provides various editions for designing reports. There is embedded edition available with Visual Studio .Net at no extra cost. This edition helps developers design reports in the Visual Studio .Net environment. There are stand alone design suites available to design reports without the need of Visual Studio .net environment. This package is sold as a per user license. The crystal server license is sold separately.

SSRS is slightly confusing in terms of licensing costs involved. It is available for free when you buy SQL server license. However in large enterprises you would like to separate out the reporting infrastructure. The reason being, SSRS is extremely resource intensive and tends to take up a lot of RAM / CPU, thereby reducing the bandwidth available to the SQL server itself. This forces organizations to buy additional licenses of SQL Server just so that they can install SSRS in an isolated environment.

(D) Report File Format

Crystal Reports are stored in binary format. The crystal reports object model can be used to programmatically access and manipulate the report components.

The reports created using SSRS are stored as plain XML text. This can be opened in a text editor and changes can be made without opening the Visual Studio .Net report designer. You may tend to assume that this is a convenient option to make changes to the report; But keep in mind that the report XML can get extremely complex and it takes a lot of effort to accurately understand and parse the XML. You are much better off using the Visual Studio .Net designer interface. The XML based format allows vendors to conveniently write third party tools for SSRS. Also, Visual Studio .Net 2005 has an inbuilt feature to design client reports that do not require an SSRS back end to be hosted. This report format is derived from the existing xml format.

(E) Data Binding

Data binding is the process of obtaining data from an underlying source and attach it to an interface. This is an important aspect in report development [in fact, display of data is what reports are all about!!]. Crystal Report allows a single data source per report. If data is to be obtained from multiple database tables, then you have to join the tables to get a single resultset. To display multiple content sets in the reports coming from multiple data sources you will have to design and include multiple sub reports in the main report.

SSRS is flexible in this regard as it allows any number of datasources per report. It is easy to design reports with unrelated sections displaying data from different data sources.

(F) Report Design Features

There are endless debates on differences in the design capabilities between Crystal Reports and SSRS. While it is impossible to provide a complete and detailed list, I will compare some of the common features:

WYSIWYG Capability: Since Crystal Reports has matured over a number of major releases, the designer interface helps articulate the exact look and feel for the intended report. SSRS however has minor issues which will probably be resolved in forthcoming versions.

Report Structure: Crystal Reports takes a Section based approach. There are predefined sections in a specific order [i.e. page header / page footer / group header / footer / body etc] and the designers customize each section to achieve the desired look and feel. SSRS takes a different approach. it is possible to drag / drop and customize report elements onto the report deign interface. This provides better flexibility in defining the structure of the report.

Formula / Calculations: Crystal Reports provides a wide range of predefined formulas that can be readily used in the reports. SSRS provides all the basic functions, but it does not match up to Crystal Reports in terms of the extent of predefined functions provided.

Extensibility: SSRS provides options to write custom code or make calls to external .net assemblies from the report.

Managing Data Flow / Sections: Crystal Report provides better features to manage page breaks / section breaks / spacing paragraphs etc. SSRS does not do an equally impressive job. These features are highly desirable in generating reports for finance / insurance / banking.

Summary

Both tools provide extensive features to build reports in your application. While Crystal Reports takes credit for being in the field for so many years, SSRS provides exciting features in the .Net platform. Before deciding on the product that is right for you, make sure you identify your primary report requirements and then evaluate the products to decide on the most appropriate one.

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

Operational Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The Operations perspective

Some companies inherit a globally distributed development initiative or organization. This may be for instance through M&A activity. Many companies on the other hand are compelled by business conditions to use geographically distributed teams. For these companies, a key question that arises is whether to invest in a captive facility or partner with a vendor for services.

While making this decision, you should consider the following factors, since they could have long-term business implications:

• Location or country and its legal business framework
• Upfront investment in a captive set-up versus working capital for vendor relationships
• Extent of direct control required, which is typically higher in an self-owned facility
• Management bandwidth available to manage the remote location
• Exit strategy and costs in case of a captive facility

Our experience shows us that on average the minimum team size in a remote geographic location should be 50 people for a captive center to have a shot at being successful.

Regardless of whether one goes the captive route or the outsourced route, the distance and time that separate members of a distributed team tend to magnify the effects of everyday challenges to successful projects.

One of the key challenges is what work to hand off and how to hand off that work to the remote location. We’ve learnt that it is important to partition the work so that at least some level of local collaboration and face-to-face can occur, e.g. individual modules being developed by dispersed teams. That said it is important to communicate frequently and regularly. The frequency and intensity of communication across locations can be increased by using a mix of formal and informal communication channels; e.g. using interactive mediums such as IM to create a feeling of connectedness between individuals. Not only does this break down barriers, and foster a one-team feeling, it also leads to a better grasp of the “larger picture” across dispersed teams.

Another very effective tool for motivating individuals and fostering a collaborative spirit across teams is to reward and more crucially recognize achievement. When the context of the distributed development initiative is understood across locations, recognizing achievement and excellence builds awareness and credibility across teams. This in turn leads teams to trust that other team-members are working toward a shared goal and carrying their weight.

Within this collaborative environment, it is also vital to have standard process to perform common tasks, so work across teams can be coordinated effectively. For instance, developing and sharing standard processes for tasks such as application builds, unit testing, release management, software deployment etc. across teams. Here collaborative infrastructure assets would play a critical role, e.g. a wiki or a project portal, to which this information could be published.

A major benefit of adopting and following standardized processes and methodologies is that all team members understand the plan, their role in the plan, and how they affect others in the plan. Many collaborative tools provide some workflow framework, helping teams structure tasks and understand where they are in the development process. Key here is to have rapid feedback cycles to minimize costs. Agile practices and rapid release cycles increase this feedback, and also tend to overcome the command and control-mindset that seem to pervade certain distributed efforts.

A word of caution here. If you are planning to adopt a methodology, internalize it well within the local organization before extending it globally. For instance, if you intend to use global agile, you need to be first agile in your co-located team. You will need to build your expertise and find the sweet spots in your own process before extending it externally. Then you can test the waters in distributed development by identifying pilot projects that would give the most bang for the buck and thereby impress senior management. That’s where the virtuous cycle starts, success feeds on success and you get buy in from senior management and business heads for engagements with greater scope and duration.

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.

 

Infrastructure Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The Infrastructure perspective

Many organizations have a tendency of just picking up a project and jumping into distributed development, without adequately considering the fundamental framework, building blocks, and logistics, and more importantly the change in mindset needed for this shift in development process. All these need careful planning and organizing. Without enabling technologies for communication or collaboration, frameworks for project tracking, visibility, or transitions, and an appropriate engineering infrastructure, the very objective of having seamless cross-location operations will be defeated.

The greatest challenge of distributed development is ensuring that high-quality, flexible code is delivered promptly and predictably—regardless of obstacles such as communication barriers, different development environments, and distributed team structure potentially in different time zones. These challenges can be made easier by enabling the three critical components of infrastructure required for successful distributed development or the 3 C’s:

• Communication
• Computing
• Collaboration

These components need to be built out to ensure that distributed teams can work as one team throughout the lifecycle of a project, regardless of their location. Also, putting these in place is a job in itself, and should be built into the initial planning stage of any dispersed project.

The first is Communication: While electronic communication is a poor substitute for face-to-face meetings, a good communication infrastructure ensures continuous, unlimited, and bidirectional communication. Telephone, video, email and chat tools contribute to a mix of formal/informal communication channels. For instance, at Silicus we use a mix of communication channels, including Voice-over IP, videoconferencing and virtual meetings or net meetings. Also, we’ve found that using tools such as Skype, with photographs of individual team-members on their profile can reinforce the one-team concept by reducing the anonymity and sense of distance that plagues geographically dispersed teams. While it doesn’t replace the “Hey Joe” environment of a centrally located team, it goes a long way in fostering an informal channel of communication between developers across geographies. Also, it functions as an important supplement to the formal Manager to Manger communication between locations, and prevents disconnects between the teams at various levels because it facilitates transfer of information.

The second factor that can make or break a distributed engineering initiative is uniformity in computing infrastructure. Multiplicity in terms of operating environments, tools, and a fragmented network can lead to compatibility issues, difficulties in managing code bases, and can lead to transitioning problems. Managing infrastructure itself can become a focal activity in such cases, overshadowing the main motive of distributed development. To ensure that work across the geographies is aligned, it is important to also align the tools and computing environment that are used to produce this work. For instance, good practice is to ensure that every location is using the same set of tools and versions. VMware infrastructure can play an important role in compressing software development cycles. It allows the creation of a centralized pool of IT assets (e.g. virtualized servers, storage and networking equipment) and, using LabManager, enables teams to rapidly setup and tear down complex, multi-machine configurations for use in testing and development. Also, configurations can be moved seamlessly to and from remote location.  This results in lowers communications costs, and enhances the efficiency and productivity of distributed teams by allowing defects to be detected early and fixed early in the development lifecycle.

The third critical component is collaboration infrastructure. In highly distributed development teams, the ability to collaborate with people across space and time is very compelling. For example at Silicus, we establish point to point VPNs as the foundation for collaboration across locations. It’s important to keep in mind that distributed development requires a variety of additional activities as compared to single-site projects: these relate to the division of tasks, sharing of artifacts, coordination of handoffs, and integration of components. So, you have to invest in creating collaborative capabilities, and developing a technology platform to improve the coordination of work. You can use proprietary tools to develop this platform, or use FOSS - Free and Open Source Software. Some FOSS tools we have found to be very useful are FocalPoint for release and iteration planning; CVS/Subversion for Source Code Control, Eclipse as an Integrated Development Environment, Ant/Cruise Control for Build automation; Bugzilla for defect and enhancement request tracking; Testopia for Test plan Management; Emma for code coverage analysis; TestNG as a unit testing framework and for UI Test automation; JMeter for load testing; and Twiki, KnowledgeTree for knowledge and document management.

The goal is to promote a long-term view of the development assets needed for effective collaboration, and to leverage this collaboration infrastructure across multiple projects over time. It is recognition of the fact that the same forces that have fostered the use of distributed teams are also yielding new ways to keep team members in touch and involved with team activities, and also allow them to maintain a sense of importance and ownership in the work being performed. By utilizing available tools and keeping alive the spirit of teamwork, distributed development teams can be as successful as the centrally located teams of the past.

About the Author

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.

 

People Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The people perspective

Being an outsourced software development services company, we serve our clients globally from our development center in Pune, India. In our partnerships with leading software companies over the last 8 years, we’ve assimilated experiences of building distributed development teams.

From our experience, the issues managers face while adopting a distributed product engineering strategy span three broad areas:

• People
• Infrastructure
• Operations: both startup and ongoing

 I’ll dig deeper into each of these in subsequent posts, and start here with people:

People are the bedrock of an execution plan. In a rapidly changing environment, the importance of people or “knowledge workers” has come sharply into focus. While labor arbitrage was a primary driver for distributing development across several low-cost locations, there is increasing realization that lower costs are only one piece of the puzzle. Talent is global, and smart firms are reorganizing themselves to tap into this global pool.

The essential challenge of distributed development is to transfer complex knowledge about products or processes, held in the heads of a group of people in one location, into the heads of a group of people at another location. We’ve seen that a higher intensity of interactions between individuals is more critical than comprehensive documentation or elaborate processes and time-consuming tools, especially if requirements are rapidly evolving

So, the people perspective for distributed development is about practices that enable and ensure communication and interactions across locations. By selecting the right people and instilling a culture that facilitates communication we can not only achieve superior productivity but also ensure that we retain these teams on a sustainable basis. So, how does one achieve that?

For starters, by priming the existing team for an imminent cultural shift. If your organization currently does not leverage agile practices, then it would be important to instill these practices as also build processes and infrastructure that can be extended to a distributed team in the future.

What is important is to envision an effective team structure and a communication plan, within which specific roles in distributed locations are incented to encourage communication. Some roles, more than others, play a critical role in not only facilitating the transition to the new paradigm but also supporting it on an on-going basis. The project manager is a key promoter of the one-team concept. Business analysts who serve as proxy customers can ensure functionality is understood clearly and well in time. Onsite liaisons from the distant location also serve as key contributors to a successful transition. Depending on the team-size, the onsite liaison should be capable of serving as the project manager, business analyst, and proxy customer all rolled into one. Once this team structure is envisioned, it is important to communicate the anticipated change in roles, emphasizing the interaction mechanisms with the distant team.

Hiring team members at a distant location typically involves working with a vendor organization or your own captive operation. Either way, multiple organizations are involved, bringing with them potential cultural, language and time zone issues. Participation in the hiring process can ensure the right team members come on board. For example at Silicus we work with our customers to put their team together in what we call a Hired-to-Order exercise. On its own, our HR department is fully capable of staffing the engagement with the best and brightest, but we involve our customers in selecting team members based on specific requirements like skills, domain knowledge, experience, etc. The selection process is essentially a joint exercise between the project manager and the offsite HR person. During this process, the Project Manager can either be present physically at the distant location or be available via video conferencing for the interview sessions.

While pre-selecting candidates, we place as much importance on soft skills as their technical ability. People with experience living in or working with other cultures, or who have traveled outside their home country are more open to forming relationships across cultural boundaries. Hence we’ve found them to be more effective in communication. Additionally, people with familiarity with our customer’s software vertical or domain are able to jumpstart the learning curve and act as mentors to other team members. If you are setting up a remote location as part of an outsourcing relationship with a vendor, ensure that the vendor is well versed with agile practices and the team members you are hiring also have past experience in agile development.

Ok – so now we have distributed teams that are ready to engage as a single team, even if they are in different locations. But is this sufficient to achieve success? To further nurture the one-team culture, we exercise best practices that continue to cement relationships – both people-to-people as well as people to organization.

Many organizations have grown from small close-knit teams. Such organizations do not have the mindset of having staff members travelling or working off-site. Often these organizations could also be sensitive about sending critical data or source code off-site. Providing access to team members who are offsite entails putting security measures in place. We will discuss this aspect in a subsequent webinar on infrastructure best practices. Also, even after putting security measures in place, management and senior team members are distrustful. And then, some employees may perceive a team at a distant location as a threat to their positions – especially if the distant location is a low-cost development center.

These issues can be addressed by building practices that emphasize a one-team concept. Having a “seeding” visit before diving into the distributed development initiative is a good way to start.  A seeding visit occurs the first time people from the off-site team visit the local site or vice versa. The first seeding visit should usually occur when team members from either location meet face-to-face to help articulate the general vision for the combined teams in terms of roles, responsibilities, communication practices as well as day-to-day operational practices. Collaborating in this fashion leads to a shared vision between the distributed teams. Subsequently, regular maintenance visits or visits by team (goodwill) ambassadors who dedicate time at the offsite location for a period of time can build and sustain the one-team structure.

Encouraging the teams to participate more in product strategy and roadmap discussions ensures that your off-site team is dedicated to customer commitments and has a common understanding of your vision and approach for execution. Most often, remote teams are not viewed as a strategic part of your organization’s assets, giving them no incentive to remain passionate about developing your product. This stems mainly from the mindset that the remote team is part of the offshore (or a vendor’s) organization, whose job is only to carry out instructions and tasks – a command and control mindset. To get a remote team to deliver, especially for time-sensitive deliverables, team members get involved early in the process and are considered integral to the successful delivery of the code – not just as workhorses for cranking out a section of the code.

Finally, there are cultural exchange programs that can greatly impact the success or failure of distributed development. Occasional cultural programs, which aim to get the teams better acquainted with the other’s culture and way of life, go a long way in ensuring cross team integration. The HR manager could take the lead in drawing up a calendar of such events, especially if they include non-work activities that also introduce aspects of the other culture. A short game of baseball or cricket during maintenance visits is not only fun; it also presents the opportunity to glean insights into another’s culture.

So, if you haven’t already done so to build the next generation of your product engineering team, we believe it is time to start scouring the globe for talent! Remember that the benefits are no longer limited to large organizations alone.

About the Author

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.

 

Considerations and Best Practices for CRM Implementation

Posted by Sambeet Patra under Customer Relationship Management (CRM), e-Business Software Solutions

Customer Relationship Management is commonly touted as an electronic business solution that brings people, process and technology together to provide seamless customer-related functions. Since CRM has been a proven strategy, companies, over the past few years have made substantial investments in deploying CRM solutions.

However it has been observed that more than half of these CRM implementations fail as the stakeholders of the deployment report negative ROIs. In this article, we provide best practices from our experience in planning  and deployment of CRM systems.

(A) Identify the Nature of Application

One of the primary but often ignored considerations for planning a CRM deployment is identifying the business scope. A CRM system can be looked at as an effective contact management tool, a platform for business process integration, a collaboration management solution providing easy to use features for communication and data handling. While it is nice to have a system that does all this, it is much more practical and economical to correctly categorize the proposed system. Although organizations have disparate requirements, a typical CRM deployment may be categorized as the followings:

CRM as a Contact Management Tool: The system is primarily conceived to maintain client and prospect information. This is typically used by Sales force to maintain list of contacts and the history of communication. The system may not provide complex business processes. However, the users want rich / easy to use interfaces and are likely to maintain huge amount of data. The system is expected to be used for bulk messaging / campaign activities.

CRM as a Collaboration Management System: In this scenario the CRM system is seen as a tool for internal / external communication. It is used as a one stop solution to track and manage customer communications and intra-organization activities involving customers. Users expect features like e-mail integration / information sharing / notification etc.

CRM as a Business Process Integration Platform: The system is expected to automate in house business processes for sales / service / order fulfillment / customer management etc. This is a solution that helps execute process flows across disparate groups in the organization. Such systems are seen as the backbone of the organization that uses it.

It is imperative that we identify the nature of the system before making decisions on the deployment.

• This impacts all the key decisions for planning, design and implementation of the CRM system.
• It helps identify the correct product in the market [if products are being evaluated]
• Provides guidance to the deployment team about management expectations.

(B) Product or Project?

Once the vision is identified, people tend to evaluate the options available in the market. There are CRM products available for all business sizes. These products may be distinguished in regards to hosting and may be grouped in two categories.

• Hosted solutions: Web / Web Service based solutions usually with a rich client layer. The data is hosted by 3rd party.
• Desktop / LAN based applications: Data / Software hosted by the organization itself.

In a happy-day scenario, we would probably find a product that meets the primary vision of the conceived CRM system. Unfortunately this will not be the case in most of the implementations. We need to consider the driving factors and their impacts on each option.

Cost considerations: The option of purchasing and deploying products has a predictable cost associated with it. The product prices are standardized and during the discovery phase it is usually easy to identify the deployment cost. For a custom development project, the management may not have good visibility for the cost involved. Developing custom applications require a detailed plan in place and the right group of resources needs to be identified to execute the project.  There are greater risks involved in regards to completing the project within schedule and within budgeted cost.

In the other hand, most of the leading CRM products available in market are highly extensible and provide framework for deployments to customize the functionality. While such capabilities are highly desirable, one needs to consider the overhead of the deployment cost associated. Decision makers are often misguided looking at the base cost of the products and they do not consider the cost associated with customization and support.

In summary, while products are generally preferred from a cost predictability standpoint, it is critical that we try to identify the customization, deployment and support cost.

Managing Change: A well planned implementation should be flexible enough to accommodate changes. A change may be related to a new business process,  change in the type of users intended for the application, change in functional requirement or a change in organization policies on software deployment. Most of these changes require the existing application to be modified.

Flexibility in accommodating changes plays a major role when deciding between product and custom development for the CRM deployment. Keep in mind that while it is almost impossible to predict the extent of changes, asking some of these questions to the involved business teams helps the deployment team gain valuable information

• How big and diverse is the user base?
• Has the sales process changed over the years?
• What kind of service / product do we provide to the customers? Which of these are tracked in CRM? Is there a well documented history behind these products / service offerings?
• What is the growth strategy for the company?

While products, by definition may seem to have an obvious disadvantage in accommodating changes, a closer look at the extensibility features provides a better understanding of the strengths of the product in consideration.

Integration Requirements: As discussed in the previous section, the CRM system may be conceived as a bridge between disparate business functions. In such situations, the ability for the solution to integrate seamlessly with other systems may be more critical than the ability to provide CRM specific features. Choosing a CRM product [especially a product that is designed as a standalone CRM application] may have limitations on integration capabilities.

(C) Focus on Business Process first…

Often, a CRM system is seen as an intelligent technology that defines and automates the Customer Relationship functions. During the initial discovery phase, people consider it as a one stop solution that can replace various stand alone legacy systems used by different groups in an organization. While there is no argument with the expectation, it is a better practice to consider the proposed CRM application as a system that merely “facilitates” the business processes. Once this expectation is set, the deployment team should focus on identifying “What exactly are the processes” in stead of jumping to “How we can implement the process”. To drive this argument further, let us consider the typical approach to understand and stabilize the business process

• Identify the subject matter experts who can explain the intended business process.
• Analyze and suggest changes to the process without considering the CRM system.
• Once the stake holders approve the suggestions, implement the process across groups without thinking about the CRM application yet. This way we ensure that all the business rules, roles, responsibilities have been adequately defined. This will greatly reduce the unknown issues and possible rework when actually implementing the solution.

(D) Manual Policies Vs System Rules

It is ideal to implement a CRM system that will completely automate the business process. There are issues achieving complete automation because

• Rules can change over time
• Management can change and new policies may be put in place. This affects the already implemented system.

So how do we design a system that can survive such changes? A simple approach is, “Not all rules need to be implemented in the system”. Keep in mind that CRM should “facilitate” processes and integration. The implementation team needs to identify the areas and policies that are likely to change over time and should make an attempt to implement these policies as working instructions for the users. The following example will clarify this:

The sales team often uses CRM to create and manage product offerings and customer quotes. Usually there are rules on pricing / discounting options for the product offerings. It is a common practice in the Sales department to change the rules around discount / pricing.

A short sighted implementation will translate all these rules in to the system implemented. This will then force the deployment team to make changes every time the sales department comes up with new policies.

A better approach is to explore the possibility to allow the sales team to adhere to these rules through proper working instructions. Further, to ensure the conformance to the rules, the team managers may be appointed to review the quotes before it goes out to customers. This way, the system is merely used to track and manage the work done whereas some of the dynamic rules can still be performed manually by the users.

(E) The Driving Committee

If you have managed a deployment project at the client’s location, you would have interacted with the management that gave you directions, discussed status and approved the work done for the project.

CRM projects are usually stakeholder-driven. It is their vision and interests that determine the course of the projects. But who are the stakeholders? People often interact with the senior management to understand the requirements. The senior management may have better visibility on high level goals such as revenue, but there are some obvious shortcomings if you deal only with senior management.

• Detailed requirements are not easily captured. The senior management may not be able to provide correct and accurate input when it comes to finer details.
• At the end of the project, when you are ready to formally obtain user acceptance, it is difficult to get Senior Management to accurately provide feedback.
• Project plan is likely to suffer as sometimes the deployment team needs timely advice and guidance from the Management.

You need some representation from end users. It is a much better practice to form a “driving committee” that comprises of various types of users. In a typical organization structure, you would look for the following people in the team that identify requirements, approve project plan, approve changes, etc:

• Representation from Senior Management
• Supervisors that manage team of users in support / implementation and other user groups using CRM. They create a bridge between management and end users and are the best people to provide detailed inputs / review work done.
• System Administrators as they will play a vital role in providing inputs on corporate strategy for software deployment / security / infrastructure.

(F) First Thing’s First

Often, CRM projects are driven with a top down approach. Management wants visibility through sales reports, revenue projection and sales forecast. They want to achieve this through the system being deployed. What they do not realize is that such analysis is done only if complete and qualified data is entered and maintained in the system. This approach then requires the low end users to put additional effort in entering all the data required. This results in lack of interest on the user’s part to adopt the new system. Also, users tend to get away with entering minimum possible data to get their job done.

An alternative approach is to understand the requirements of the management and at the same time pay attention to the low end users. During the initial phases, focus on building a system that is acceptable to the low end users. Once they adopt the system and realize the potential, you should make gradual attempts to build in additional features requested by the Management.

The success of a CRM system usually depends on the end users who access the system frequently. It is imperative that you gain their support and acceptance for a successful deployment.

(G) Iterative Approach

If you are planning to achieve all functionalities in a single iteration of the deployment, you are brewing recipe for disaster.

CRM deployment is a learning experience for all people involved. While the management may think that they have all the requirements in sight, they start discovering rules and patterns as things progress. As the representative of the deployment team, you need to help the business “learn and apply the learning”. Plan the deployment in small phases and make it a point to achieve few critical goals through every iteration. Obtain timely user feedbacks and do not be afraid of rework. Keep in mind that the business is used to identify the right approach only when they see something tangible. Instead of creating and reviewing huge requirements document, it is relatively simpler to keep adding functionalities gradually and make changes per user feedback.

Summary

There has been an increased focus on maximizing customer satisfaction. CRM is projected as the answer to issues concerning customer satisfaction. But improper implementation just adds to the already existing worries the organization has to deal with.

Detailed planning, setting long term visions and effective participation of end users will help ensure a successful deployment thereby achieving greater degree of customer satisfaction.

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

How to customize an existing process template in TFS?

Posted by S Singh under Software Development Practices

In my last post “Process Implementation and TFS(Team Foundation Server)- Part1” I spoke about editing the process template using TFS process template manager. The limitation with this approach is that it commits the changes at the template level which can only be seen in the new project. So, in other words the existing projects using that template would not see the changes.

 This leaves us with the question – how do we customize our process templates to see the changes in the existing projects. Here is a step by step guide to do this:

 Problem:

 Scenario: Suppose I have a team project named “test” which is using TFS-CMMI process improvement template. Due to my current project needs I need to modify the work item Type-“issue” to support an additional state “Awaiting business feedback”-this is to clearly identify all the items that are waiting for customer’s feedback before closure.

The flow would be something like this:

Existing flow:

Propose->Active->Resolved-> closed 

New Flow:

Propose->Active->Resolved-> Awaiting Business feedback->closed 

Solution:

This can be achieved in two ways: 

• Command line Route: Microsoft has provided some command line tools to help with this process. Using witexport you can export a single work item definition file for a specific team project, modify it, and then use witimport to import the modified work item definition into the process template.         

            Step 1:

Make sure the path for the above two command line utilities is in your system environment variable. Otherwise you will have to traverse to the following location to execute these commands: <drive >\Program Files\Visual Studio8\Common7\IDE

Step 2:

Open command line screen and execute the following command: 

witexport [/f Workitem export path/Name] /t [TFS Server] /p [teamproject] /n [workitem name] 

In my case it will be: witexport /f c:\\ ProcessTemplates\issue.xml /t silpunappdev6 /p test /n Issue

Step 3: 

Open Issue.xml in Visual Studio 2008/2005 with TFS process template editor. It will automatically create an issue.wit in “c:\processTemplates”. WIT extension stands for work item type. This is how the file will look like once opened in Visual studio 2008.

Step 4:

To achieve the required customization. I will have to add a new State-“Awaiting customer Feedback” and three new transitions: a) Resolved to Awaiting customer feedback b) Awaiting customer feedback to Closed c) Awaiting customer feedback to Active (In case of rework) Please refer to my earlier post “Process Implementation and TFS(Team Foundation Server)- Part1” for more details about “State and Transitions”.

• Add a new State-“Awaiting Customer feedback” by dragging and dropping the state object from left tool bar on the Workflow tab of issue.wit
• Rename the state to “Awaiting Customer feedback” by double clicking on state object. Please refer to the following figure: 

Add Transitions:

• • Select Transition link on the left tool bar and create a link between resolved and awaiting customer feedback state objects by clicking on them. 

Transition Details: 

1. Resolved ->Awaiting Customer feedback. Please refer to the following figures:
   • Double click on transition object and add a reason for this transition as “Customer Approval Required”. Refer to the following figure(s):

Create the remaining transitions and save the changes. The final workflow screen will look like this:

 

 

 

The author is a seasoned project manager at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

 

Step 5:

After making all the changes to the work item type. Import the issue.xml using the following command line utility. 

Witimport /f [filename] /t [tfs Server] /p [teamproject]  

In my case: Witimport /f c:\\ProcessTemplates\\issue.xml /t silpunappdev6 /p test 

This was the last step required to implement the customization. No you should be able to create an issue with “Awaiting customer feedback” state in your existing ‘test’ project.

In the beginning I mentioned that there are two ways to do this. Actually if we look at it the real difference between the two approaches is in the way we export and import the workitem type xml file. One is using the Command line utility (witexport and witimport) the other approach is through visual studio IDE. Please refer to the snapshot below. The WIT editing part is the same in both the cases. 

 

  About the Author

The author is a seasoned project manager at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.