CMS Fridays: Say No Is Hard To Do, But The Right Thing
This really qualifies as general project and product management, but SharePoint Shelter has a wonderful post about saying no to feature requests using SharePoint.
Some of the reasons that a project manager, in the context of SharePoint, should say no is:
- While this feature will extend our SharePoint environment, it is more of a nice-to-have, and not really a baseline requirement for this project
- The calculated effort requirement by either/both the development or operations staff doesn't really justify the production of the feature
- The subproject in the terms of the current contract constraints doesn't procure a practical baseline for reallocation (or allocation) of resources to make it a tangible production.
- While this feature from the development or operations end is awesome, it is something that client doesn't immediately realize the need for, or will never be noticed by the client
- Holy crap, this doesn't even qualify because it is so experimental, it isn't funny (kind of like when a client asked me to build neural networks for forecasting models off SharePoint lists. Probably should have nixed that one).