In our organization, sales people and administrators ask developers for support whenever they experience a problem. How should support time be structured/provided for existing software without constantly interrupting developers with direct requests to fix things?
-
I refactored the question quite heavily for clarity. Please feel free to edit your question further if you have additional information, or if my edits misrepresent your issue.– Todd A. Jacobs ♦Commented Jan 24, 2013 at 18:45
-
Please expand these 'existing softwares'. Are they softwares built in-house or third-part softwares?– Tiago CardosoCommented Jan 25, 2013 at 13:25
1 Answer
Responsibility for Change Control
Whether the request is for new features, bug-fixes, or support for developed software, what you're really talking about is change control. Change control is the process your organization uses (or fails to use) to manage scope and resource constraints on a project.
Regardless of the framework, here's how responsibility for change control should be handled at the conceptual level:
- Projects should define a hand-off to a support team/organization for completed projects.
- Projects should define a support process for projects-in-progress to prevent diverting project resources in unanticipated ways.
Change control requests should be triaged and prioritized by someone who can make business decisions about whether resources should be diverted from feature development to support for any given issue.
Note: In Scrum, this person should be the Product Owner. Other frameworks may task a steering committee, project sponsor, or other executive with this authority, which may then be further delegated to someone else (e.g. the project manager) if desired.
Note that all responsibility ultimately rests with senior management. While the project manager is responsible for recommending controls such as a formal change management process to senior management, the management team remains responsible for funding the process and keeping it aligned with business interests.
Support Outside of a Project
If support requests are an ongoing business process rather than a byproduct of a specific project, then an organization needs to build a process around that need. While some process frameworks such as Kanban or Lean can be leveraged for repeating or ongoing processes, technical support itself is not typically considered a project, and is not usually managed by a project manager.
Because technical support is a business process rather than a defined project, applying project management methodologies (as opposed to process control methodologies) is usually not appropriate. However, one can't over-generalize here, so your mileage may vary.