Key Stakeholder Change

It's very common for stakeholders to submit change requests for a project (e.g., a departmental manager asks for a change to the logon procedure for his staff or a vice president requests that a particular portion of the network be secured in a different manner than was specified). A director demands that some procedure be changed or an executive demands that particular security tasks be delayed until after a certain time or event. All of these kinds of changes have to be managed by the IT project team.

Your standard change management procedures should be employed consistently throughout the project lifecycle. These procedures should include evaluating the requested change, assigning it a level of criticality, and assessing what actions might be taken to address the change. Once it's decided that a change is desirable or acceptable, it must go through the risk evaluation process. By definition, change is a project risk because you're deviating from the project plan. Therefore, you should view all major change as a risk and evaluate it using the same methodologies you use to evaluate other kinds of risk. Be especially aware of unintended consequences of change.Think through these situations very carefully to determine if these changes will support, enhance, or erode security. If they will not support or enhance security, they should probably not be implemented. However, we all know that in the real world, things are rarely perfect and you may be forced by circumstances to implement a change that does not support or enhance security.You'll have to evaluate the pro's and con's before making a final decision.This might be a good time to check in with your security project plan sponsor if you have conflicting demands that cannot be easily resolved.

Also, use your functional and technical requirements documents to address major stakeholder change requests. Sometimes stakeholders simply fail to understand the implications of their change requests and once they are discussed in light of the original specifications and the risks of the requested change, they may rescind those requests. If not, your job is to negotiate a reasonable solution to the problem. Look over the original specifications and determine whether the stakeholder's change request:

1. Falls under the original specifications (i.e. you and your team may have missed something).

2. Falls outside of the original specifications, but is a desirable modification that will support or enhance security.

3. Falls outside of the original specifications, is a reasonable modification, but does not support or enhance security.

4. Falls outside the original specifications, is not a reasonable modification, and may or may not support security.

Clearly, having had key stakeholder input from the start of the project should reduce these kinds of change requests, but change always pops up in one form or another. As you evaluate these potential changes using these four criteria, you can take a logical approach toward incorporating the requested change or explaining the reasons for rejecting the requested change. Be sure to effectively communicate with key stakeholders and take time to explain the rationale for the decision. While the stakeholder might not be pleased with the final outcome, he or she should at least understand why the decision was made. If you can defend your position, be sure you're being reasonable. Sometimes in the midst of project work, we want to reject change just because it's inconvenient, not because it's undesirable. Make sure you don't fall into that trap.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment