Description
A Data View Web Part (DVWP) is configured to display data from a Microsoft SQL Server datasource. However, instead of data from the datasource, the Data View Web Part displays the following error message:
"Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Micrsofot SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator."
Solution *
1. Using SharePoint Designer, test the datasource for the DVWP. One possible cause for this error is that the credentials for the datasource are expired, as indicated in the SharePoint Designer dialog box.
2. Open SQL Server Management Studio, expand Security, expand Logins, right-click on the Login and click Properties. Uncheck the "Enforce Password Expiration" checkbox and click OK.
3. Test the Data View Web Part, datasource again in SharePoint Designer. If the issue is resolved, test the DVWP also in the Web browser.
* Disclaimer: This solution represents only one of many possible solutions and may or may not be applicable in your environment.
Concepts: Information Architecture, Knowledge Management, Portals, Enterprise Search, Collaboration, Extranets, Intranets, Business Intelligence, Business Process Automation, ECM, Records Management, CRM, ERP, Mobile, Web
Approach: Project Management, Business Analysis, Strategy, Design, Development, Implementation
Technologies: Microsoft SharePoint, Office 365, Azure, SQL Server, Windows, HTML5, CSS, JavaScript, ASP.NET
Thursday, October 27, 2011
Thursday, October 20, 2011
Lessons from an ERP Project Failure and Vendor Law Suit
A customer/vendor conflict:
In a recent Computerworld article, Chris Kanaracus explains how Epicor Sued Over Alleged ERP Project Failure. In the article, the customer attributes the project failure due to shortcomings in Epicor software. Customer states, "The project did not go well due to a variety of shortcomings in Epicor's software."
In my experience doing these sorts of procurements, when specific business requirements are defined well and included in the RFP, SOW, and contractual documents, then many project risks (both cost and schedule types) are shifted to the vendor. If the vendor agrees to meet a specific requirement and both customer and vendor sign the contract, then vendor is on the hook. However, if the requirement is not documented in the initial contract, then the vendor may later push back by describing the requirement as "out of scope" and will only do the work if they can bill the hours. Scope creep is not only common in ERP projects, it is actually a well-accepted fact.
As a casual reader of the article, I must state up front that I don't have all the facts in this story. I only know what I read in the article. So, based on the article and past experiences I can go out on a limb and suggest two things that might have happened:
This article reminds us of some key lessons that we can use when working with vendors.
References
Kanaracus, C. (August, 2011). Epicor sued over alleged ERP project failure. Retrieved October 20, 2011 from http://www.computerworld.com/s/article/9219127/Epicor_sued_over_alleged_ERP_project_failure?taxonomyId=144&pageNumber=1.
In a recent Computerworld article, Chris Kanaracus explains how Epicor Sued Over Alleged ERP Project Failure. In the article, the customer attributes the project failure due to shortcomings in Epicor software. Customer states, "The project did not go well due to a variety of shortcomings in Epicor's software."
Here is my analysis:
In my experience doing these sorts of procurements, when specific business requirements are defined well and included in the RFP, SOW, and contractual documents, then many project risks (both cost and schedule types) are shifted to the vendor. If the vendor agrees to meet a specific requirement and both customer and vendor sign the contract, then vendor is on the hook. However, if the requirement is not documented in the initial contract, then the vendor may later push back by describing the requirement as "out of scope" and will only do the work if they can bill the hours. Scope creep is not only common in ERP projects, it is actually a well-accepted fact.
As a casual reader of the article, I must state up front that I don't have all the facts in this story. I only know what I read in the article. So, based on the article and past experiences I can go out on a limb and suggest two things that might have happened:
- The customer failed to specify the steps of a key process and include those details in their contract with Epicor. Therefore, the process became ambigious and unclear.
- Epicor team attempted to remedy a technical shortcoming through additional pro services (billable time), and they failed to reach customer satisfaction before the bill got to be a million bucks.
This article reminds us of some key lessons that we can use when working with vendors.
- Invest as much time as necessary into defining processes well.
- Identify specifics even if they are obvious or assumed.
- Include specific business requirements, solution requirements, use cases, story board, and other illustrations in the vendor contractual document.
- Group related requirements into "categories" and seek fixed pricing estimate for each category (this forces vendor to do more careful estimates and makes the project easier to manage).
- Create a project completion checklist up front (should map closely to the categories) and include that the contracts.
- Realize even if you defined requirements really well, you still might miss important ones. Therefore, remember to buffer the project budget to cover requirements that may have been missed.
References
Kanaracus, C. (August, 2011). Epicor sued over alleged ERP project failure. Retrieved October 20, 2011 from http://www.computerworld.com/s/article/9219127/Epicor_sued_over_alleged_ERP_project_failure?taxonomyId=144&pageNumber=1.