2

I am trying to institute a technical request protocol throughout my very large and diverse company. The problem is, this protocol has existed for years, yet it has never been implemented effectively, as many of the requestors make informal, personal requests to the developers and/or request through email/phone call/in person without filling out the form. This leads to miscommunication and lack of clarity. What are some effective strategies for implementing this protocol?

Improve this question

3 Answers 3

Reset to default
4

"Never introduce a managerial change without first introducing the managerial change." Mark Horstman, http://www.manager-tools.com

Since the protocol has never been implemented effectively, start over. You effectively don't have a protocol in place now, so begin implementation anew.

Start by revisiting why you need such a protocol, the benefits for the organization and for the individuals in the organization. (Other responders have some pointers along those lines.) Consider redesigning the protocol - if you consult with stakeholders on both ends of the request, you may discover other approaches to solving the same problems.

Then introduce the protocol as a change. Ignore the fact that it should have been used all along. Follow organizational change management best practices - review the change individually with at least a representative subset of those affected, announce it to the organization, present the change to organizational units that will be affected, provide materials well ahead of the change implementation date, and so on. Searching the web for "change management" will turn up a lot of resources, if this isn't in your skill set already.

Once the change has been implemented, following the protocol is now a management exercise. And how that's done is a different question, well outside the scope of personal productivity.

Improve this answer
1

The question you need to ask is why these individuals are not using the form. Is it much easier to just contact the individual directly? If that is the case then there is no reason for them to change. They will see your plan as annoying and inefficient.

If there is no direct benefit to them you might need to look in the opposite direction - official word from the top that says if they don't follow the procedure then their project does not go ahead, their change is not approved or they are disciplined in some way (lower score at annual review etc)

Sounds harsh but if the process doesn't benefit them it won't happen.

Improve this answer
0

Developers should never be disturbed by various people with feature requests. Instead it is the duty of the product owner to act as a gatekeeper, taking note of all requests and prioritizing the backlog items. If you don't have these roles in your organization, you should introduce them before dealing with your form problem.

Improve this answer
1
  • Hello Gruber. On Workplace, we strive for answers that explain why and how. To improve this post, my suggestion is to elaborate on how the asker might get started introducing those roles into the organization. Additionally, you could include a link for reference, if it adds value. Please see the back it up rule for more details, as well as Good Subjective, Bad Subjective. Hope this helps!
    – jmort253
    Commented Dec 5, 2013 at 6:17

You must log in to answer this question.