InfoStrat has created a calculator to help customers explore costs for licensing, hosting, and professional services relating to Dynamics CRM projects. This calculator is based on many assumptions (list price for software, nominal blended rates for services) and is missing some cost items (data migration, hardware, and integration) but is a starting point for understanding the total cost of initial implementation and total cost of ownership.
The tool will be refined based on user feedback. It is no substitute for talking to an experienced implementation team and getting the actual prices based on your Microsoft volume licensing agreement and professional services provide.
We hope you enjoy.
Wednesday, May 15, 2013
Wednesday, May 8, 2013
Usage Scenarios for Microsoft Grants Manager
Government agencies have diverse requirements when it comes to automating grants management. I have been helping customers evaluate Microsoft Grants Manager and it turns out that each agency has a unique approach which requires some customization in order to optimally match their business rules. One size definitely does not fit all when it comes to grants.
Federal agencies are the largest grantors, and rarely receive grants except perhaps from other federal agencies. These agencies are bound by guidelines established by the Office of Management and Budget and are striving for more consistent approaches to grants such as accepting applications via the grants.gov portal. Many of their grants are formula grants rather than competitive grants, and the formulas themselves may be quite complicated. Typically the grant managers are scattered among offices within an agency rather than centralized, although some are consolidating. The volume of applications and dollar value of federal grants ranges widely, but is often quite high. Most federal grantors have automated their processes but are relying on custom built solutions that may be based on outdated technology which is difficult to update as business rules change.
Local governments, on the other hand, are primarily grant recipients rather than grantors. They are focused on applying for grants and managing the grant activities, including reporting to state or federal grantor agencies. The most common scenario is to use Excel spreadsheets and email to manage grant information, along with the agency's accounting software. The scattered nature of data means it is difficult to do reporting and combine data from multiple departments or agencies.
State governments fall between the extremes of federal and local government in terms of grants. They are both grantees and grantors. Most states have automated their grants processes, at least in larger agencies.
Microsoft Grants Manager allows each customer to tailor the solution to their requirements. For instance, many agencies have a simple proposal review process and don't need the full sophistication of the review wizard and review group functionality in Grants Manager. They can replace that function with a workflow that matches their process. Specialized groups can use only a portion of the solution as needed and hide extraneous forms and reports from their menus. Many of the customizations can be performed without programming by system administrators.
Federal agencies are the largest grantors, and rarely receive grants except perhaps from other federal agencies. These agencies are bound by guidelines established by the Office of Management and Budget and are striving for more consistent approaches to grants such as accepting applications via the grants.gov portal. Many of their grants are formula grants rather than competitive grants, and the formulas themselves may be quite complicated. Typically the grant managers are scattered among offices within an agency rather than centralized, although some are consolidating. The volume of applications and dollar value of federal grants ranges widely, but is often quite high. Most federal grantors have automated their processes but are relying on custom built solutions that may be based on outdated technology which is difficult to update as business rules change.
Local governments, on the other hand, are primarily grant recipients rather than grantors. They are focused on applying for grants and managing the grant activities, including reporting to state or federal grantor agencies. The most common scenario is to use Excel spreadsheets and email to manage grant information, along with the agency's accounting software. The scattered nature of data means it is difficult to do reporting and combine data from multiple departments or agencies.
State governments fall between the extremes of federal and local government in terms of grants. They are both grantees and grantors. Most states have automated their grants processes, at least in larger agencies.
Microsoft Grants Manager allows each customer to tailor the solution to their requirements. For instance, many agencies have a simple proposal review process and don't need the full sophistication of the review wizard and review group functionality in Grants Manager. They can replace that function with a workflow that matches their process. Specialized groups can use only a portion of the solution as needed and hide extraneous forms and reports from their menus. Many of the customizations can be performed without programming by system administrators.
Thursday, May 2, 2013
Microsoft Dynamics CRM and Geographic Information Systems (GIS)
Maps are a great complement to CRM systems, and can help you visualize data in exciting new ways. Over the years, InfoStrat has integrated Microsoft Dynamics CRM with GIS including ArcGIS (ESRI) and Bing Maps (Microsoft).
One of our first GIS integrations was to show cases from constituent management on a map using "pushpins." This solution allows users to see a map of open cases and filter by search criteria.
Field inspection is a great scenario for mapping. Inspections use maps to navigate to inspection sites, and can present inspection results in maps.
Mashups of data from multiple sources, including CRM, can be useful. This visualizations can include business graphs integrated with maps.
Interactive video conferencing often uses maps to communicate critical information. The virtual meeting experience can be enhanced with Microsoft Kinect as a 3D controller.
Modern GIS data and images may be used for scientific and historical research.
The extensibility of Dynamics CRM makes it possible for developers to include maps in the Dynamics CRM user interface and also to make CRM data available as a web service for consumption by GIS. By default, Dynamics CRM includes Bing Maps integration, but administrators can disable the Bing Maps or replace them with ESRI ArcGIS, Google Maps or others.
One of our first GIS integrations was to show cases from constituent management on a map using "pushpins." This solution allows users to see a map of open cases and filter by search criteria.
Field inspection is a great scenario for mapping. Inspections use maps to navigate to inspection sites, and can present inspection results in maps.
Mashups of data from multiple sources, including CRM, can be useful. This visualizations can include business graphs integrated with maps.
Interactive video conferencing often uses maps to communicate critical information. The virtual meeting experience can be enhanced with Microsoft Kinect as a 3D controller.
Modern GIS data and images may be used for scientific and historical research.
The extensibility of Dynamics CRM makes it possible for developers to include maps in the Dynamics CRM user interface and also to make CRM data available as a web service for consumption by GIS. By default, Dynamics CRM includes Bing Maps integration, but administrators can disable the Bing Maps or replace them with ESRI ArcGIS, Google Maps or others.
Monday, April 29, 2013
The Secrets of IT Project Success -- Willpower
Stories of failed information technology (IT) projects are legion, and the poor success rates have been documented in many studies. To some extent, the larger the project and the more time and money spent, the more elusive the success.
I have been mulling over the reasons for project success based on my experience participating in projects and reading about the industry. Of course there are many reasons for success and failure, but I think the most important one is the willpower of the stakeholders and key project participants.
Nearly all IT projects are challenging, and could easily be considered failures or the project team doesn't adapt to changes in requirements, technology, and other factors.
The assumption that requirements are finite and stable is unrealistic. Rigid requirements can lead to project failure, or a product that technically meets the requirements but doesn't actually work. It's easy to point blame to all the participants in the project, from flawed management vision to weak requirements to sloppy coding and testing.
What stands out to me in successful projects is the sheer willpower along with optimism to ship a working solution, and the willingness to face up to all the problems that are encountered along the way. This courage is not common, and some projects and organizations prevent individuals from taking personal stakes in the outcome and putting their willpower to work.
I have been mulling over the reasons for project success based on my experience participating in projects and reading about the industry. Of course there are many reasons for success and failure, but I think the most important one is the willpower of the stakeholders and key project participants.
Nearly all IT projects are challenging, and could easily be considered failures or the project team doesn't adapt to changes in requirements, technology, and other factors.
The assumption that requirements are finite and stable is unrealistic. Rigid requirements can lead to project failure, or a product that technically meets the requirements but doesn't actually work. It's easy to point blame to all the participants in the project, from flawed management vision to weak requirements to sloppy coding and testing.
What stands out to me in successful projects is the sheer willpower along with optimism to ship a working solution, and the willingness to face up to all the problems that are encountered along the way. This courage is not common, and some projects and organizations prevent individuals from taking personal stakes in the outcome and putting their willpower to work.
Wednesday, April 17, 2013
Don't Call People Resources
I know that in project management, people are considered resources in the same way that raw materials are considered resources, but for software development projects I have found it counterproductive to treat people like so many interchangeable parts.
The success of a software project hinges on the interactions among many people, including the client, subject matter experts, project managers, testers, trainers and developers. In addition to their experience and expertise, these people bring with them their personalities and communications styles.
Because software development is more a team exercise, like filming a movie, than an individual exercise, like writing a book, the overall team dynamic is just as important as individual qualifications. It is quite possible to put together a team of people with excellent resumes who will be quite ineffective when forced to work with one another.
I have run into clients who focus excessively on comparing resumes as if they provide an indication of future success. Some of the best resumes I have seen belong to work avoiders who spend more time finding others to blame than accepting responsibility and getting things done. Job hoppers have more interesting resumes than steady performers that stay with companies and projects for the long haul.
So many project methodologies are now used that you need to ensure everyone is on the same page. Approaches and activities that work in one methodology are disastrous for others. Excessive love of methodology and documentation over working software is ever more pernicious.
Experience of people who have worked as a team is a great asset for a software project. Knowing the strengths and weaknesses of team members helps project managers and technical leads assign tasks to the right people, and to know how those people should be managed. Some need close attention with frequent interaction, and others need time alone to do their work. Some people will thrive in the intense pressure of a war room environment, while others will crumble.
So even if you call them resources on your project plan, don't treat people like resources if you want your project to succeed.
The success of a software project hinges on the interactions among many people, including the client, subject matter experts, project managers, testers, trainers and developers. In addition to their experience and expertise, these people bring with them their personalities and communications styles.
Because software development is more a team exercise, like filming a movie, than an individual exercise, like writing a book, the overall team dynamic is just as important as individual qualifications. It is quite possible to put together a team of people with excellent resumes who will be quite ineffective when forced to work with one another.
I have run into clients who focus excessively on comparing resumes as if they provide an indication of future success. Some of the best resumes I have seen belong to work avoiders who spend more time finding others to blame than accepting responsibility and getting things done. Job hoppers have more interesting resumes than steady performers that stay with companies and projects for the long haul.
So many project methodologies are now used that you need to ensure everyone is on the same page. Approaches and activities that work in one methodology are disastrous for others. Excessive love of methodology and documentation over working software is ever more pernicious.
Experience of people who have worked as a team is a great asset for a software project. Knowing the strengths and weaknesses of team members helps project managers and technical leads assign tasks to the right people, and to know how those people should be managed. Some need close attention with frequent interaction, and others need time alone to do their work. Some people will thrive in the intense pressure of a war room environment, while others will crumble.
So even if you call them resources on your project plan, don't treat people like resources if you want your project to succeed.
Thursday, March 7, 2013
Estimating the Cost of Dynamics CRM Implementations: Part 8 -- Future Enhancements
This is the latest installment of ruminations on cost estimating for Dynamics CRM projects. Now that your xRM solution is in place and you have determined what kind of support you need to keep it alive, is that all there is?
For some customers, maintenance is the last item that requires professional services. But building a software solution isn't usually like building a stone obelisk and placing it in the middle of your piazza. For most people, it's more like planting a garden, and will require not only tending but will evolve over time based on which plants thrive.
The future may bring changes that require modifications to the solution. Government agencies must ensure that their policies and procedures are consistent with laws and regulations which are constantly changing. This regulatory compliance is not optional.
What if you come up with an improved business process and want to reflect it in your CRM solution? Such changes could affect the data model, automated workflows and reports.
In order to control the cost and disruptions of change, you may want to set up a release schedule to set expectations of users who request enhancements. Over the course of an implementation you may move to less frequent releases.
Don't forget that changes require notifications to users and sometimes refresher training. A mechanism to solicit user feedback can identify ways to improve and boost user satisfaction at the same time.
See our Dynamics CRM implementation cost calculator
For some customers, maintenance is the last item that requires professional services. But building a software solution isn't usually like building a stone obelisk and placing it in the middle of your piazza. For most people, it's more like planting a garden, and will require not only tending but will evolve over time based on which plants thrive.
The future may bring changes that require modifications to the solution. Government agencies must ensure that their policies and procedures are consistent with laws and regulations which are constantly changing. This regulatory compliance is not optional.
What if you come up with an improved business process and want to reflect it in your CRM solution? Such changes could affect the data model, automated workflows and reports.
In order to control the cost and disruptions of change, you may want to set up a release schedule to set expectations of users who request enhancements. Over the course of an implementation you may move to less frequent releases.
Don't forget that changes require notifications to users and sometimes refresher training. A mechanism to solicit user feedback can identify ways to improve and boost user satisfaction at the same time.
See our Dynamics CRM implementation cost calculator
Tuesday, February 26, 2013
Estimating the Cost of Dynamics CRM Implementations: Part 7 -- Support
This week we examine alternatives and costs for supporting your Dynamics CRM (xRM) implementation. In the long run, it is not unusual for the support to end up costing more than the implementation itself, but cutting corners on support can put user satisfaction and adoption at risk.
The first step is to determine what support arrangement you have with Microsoft? Who is authorized to create Microsoft support incidents? Does your organization have assigned Microsoft technical support managers? Microsoft can help with product questions and issues that arise from software updates. In most cases, they will not be familiar with your specific implementation.
Next, do you have a help desk or do you need to hire an outside company to provide help desk services? Do you need coverage during business hours or 24 hours x 7 days a week? Will your users call your help desk to report their initial issue?
How will you handle enhancements to your solution? Do you intend to publish new versions on a periodic basis? At what interval (weekly, monthly, quarterly or other)? If so, how large a team is required for these iterations? Will the team that did your implementation be available?
For how long a period do you want to budget? You can expect the level of enhancements to drop after the first year unless new business requirements are introduced.
See our Dynamics CRM implementation cost calculator
The first step is to determine what support arrangement you have with Microsoft? Who is authorized to create Microsoft support incidents? Does your organization have assigned Microsoft technical support managers? Microsoft can help with product questions and issues that arise from software updates. In most cases, they will not be familiar with your specific implementation.
Next, do you have a help desk or do you need to hire an outside company to provide help desk services? Do you need coverage during business hours or 24 hours x 7 days a week? Will your users call your help desk to report their initial issue?
How will you handle enhancements to your solution? Do you intend to publish new versions on a periodic basis? At what interval (weekly, monthly, quarterly or other)? If so, how large a team is required for these iterations? Will the team that did your implementation be available?
For how long a period do you want to budget? You can expect the level of enhancements to drop after the first year unless new business requirements are introduced.
See our Dynamics CRM implementation cost calculator
Subscribe to:
Posts (Atom)
Posts
