Project Management Central

Please login or join to subscribe to this thread

Topics: Change Management
Managing Change in high level of interruption from senior management
Network:60085



Today I received a question from Hammad Saeed, PMP on high level of interruption during the implementation of change management. His question follows:

Implementation of proper change management in projects is the biggest challenge I am facing in my organization. This is happening due to direct interference of top management in execution of projects. How can I overcome this issue?

This is a common as well as a unique situation. This is common where top level management is trying to micro-manage, and this is a symptom of lack of confidence in middle management. I am not defending that this interference is right by any standard, but before we can criticize it, we must first look into our own grip on the work at hand. If I as a change manager am unable to give any level of comfort to my senior management, they will like to keep tabs on every aspect of change I am trying to manage. This is unique because, change itself was originated from a business need and if the requirements are being consistently changed, we may raise questions on the validity of the business case itself. Business case may had the change manager or the project manager involved and may have been carried out by the business analyst or the senior management themselves. This raises a serious concern at how the change passed on to implementation by the senior management, if it was not viable.

Muneeb Minhas, responded to the said query by saying:

If that is the case, you will have to take a step by step approach, you will have to agree to the change request and along with it u will have to initiate the cost benefit analysis, impact analysis of the change. and let the stakeholders know of the possible outcomes. Repeat this process for a couple of projects and then make it a precedence to go for the proper process, don't be hard on them, be a bit flexible in the beginning, and then, once the organization is used to going through the process of change management, then make it mandatory. Change Management is more like Stakeholder management, and influential stakeholder management is similar to managing a 2-3 old kid who wakes up at night and starts crying that I want to go out and play with "moon".

I agree with the approach, but we must first explore the background as if we can apply this step-by-step approach. A Guide to Project Management Body of Knowledge, 5th Edition, does have the solution if the good practices provided are selected and used at the right time and in the right proportions. I am also confused about the question itself as if it is addressing only the change request process in project management or change management at organizational level. Both may have many similarities but will have to be treated differently. I will try to address both scenarios.

I will address following questions one by one, to answer the BIG question:

How can we be sure that the business case or the change request was viable?
How can we restore the stakeholder confidence and eliminate trust deficit?
What should be the process of change, when we are already dealing with the change?
How can we keep the whole process completely transparent?

How can we be sure that the business case or the change request was viable?

Let me take the first scenario first, where we are dealing with an organizational change. The business case justifying the change must not be taken on face value as it might have been considered or proven viable when the feasibility was carried out, but by the time the actual implementation of the change starts, the situation and the environment might have changed. It is exactly why, when a project is assigned to a project sponsor, it is her duty to take inputs from project statement of work, business case and the agreement, as if she can write the charter, an authorization for the project manager to mobilize resources for the said project. You see, even project sponsor, being an executive of the project, before she orders the implementation of the project, has to be sure if it is still viable. She uses the tools like cost-benefit analysis and SWOT analysis to review the business case and only when sure, drafts the charter, which will even then, have to be approved by the senior management. If all these steps had been taken, I see no reason, senior management will interfere in day to day working of the project, except at per-determined points of contact to monitor KPIs.

Even within the project, when a change is suggested by a stakeholder, project manager has absolutely no authority to say NO to that. She is supposed to analyze the change and if it is out of scope of the project, she has to convince the stakeholders about that in a friendly manner, which will be well-understood if stakeholder was already taken on board and engaged right from initiation of the project. In case, the stakeholder is not convinced, still project manager cannot say NO, the matter will be treated as an issue and will be escalated to the next higher level, which in this case will be the project sponsor and then the senior management. If the process is followed, there is no way that trust deficit will ever occur. The matter will be settled as some level of escalation and even if it was out of scope, but the management agreed to entertain the change, management will take the responsibility to increase the scope of the project to encompass that change and other allied arrangements and approvals will be granted. This way, there are no hard feelings, anywhere.

How can we restore the stakeholder confidence and eliminate trust deficit?

Remember, no matter if it is the senior management, customer or even your own team member, they all are the stakeholders of the project. It is not only the team members who have to be taking along, it is the whole list of stakeholders, without regard to their position and influence. All stakeholders will have to be taken on board and must be kept engaged throughout the life of the project. The moment, you disengage, be sure of the misgivings from the stakeholders.

During initiation, you must identify all stakeholders without fail, and develop your stakeholder management strategy.
During planning, you get engaged with you stakeholders and emphatically understand all their need and expectations. Converse and discuss with them, convince them on project objectives and deliverable requirements, be flexible and accommodate their view points if that is something the business case might have left out and must be included. Present such changes to be brought up in scope of the project and get them included. In case, the stakeholder is unable to agree with your logic, escalate the issue to next higher level and let them reach a decision.
During Execution, keep the stakeholder engaged by ensuring all necessary communications are happening and stakeholder at no point feels left alone. Engage by using your presentation skills and transparently communicating with your stakeholders.
During Monitoring and Controlling, manage this engagement by accommodating any changes to the stakeholder engagement or even to the project, and keep the stakeholders abreast with all the happenings of the project.
During Closing, you will record all lessons learned from stakeholder engagement as if to provide valuable guidance for future project.

I am positive, if this is the relationship you can manage with your stakeholders, there can be no possibility of lack of confidence and trust-deficit.

What should be the process of change, when we are already dealing with the change?

Project in itself, is an instrument through which we are trying to bring some desired change in the organization, thus is a part of organizational change. While we are involved in a project, we understand this is a kind of job we might not have dome earlier, or at least not in the manner this specific project is to be done, making it unique. This brings a lot of uncertainty, howsoever and in how much detail I plan, there will still be a possibility of some unknown unknown risk occurring and resulting in some change. So at all times, in the project life-cycle, no matte how well we planned it, we must be ready for change. I would be bold enough to take the agile line to project management, by saying you should always welcome change. Remember, project management has no authority whatsoever to say no to a change, as I described earlier. There is a process, which has to be followed, and there should not be any heart-burning about it. Everyone must be performing her duties, customer might be suggesting something new coming to her mind, you as a project manager analyzing the change and formally converting it into a change request, if you find it viable through your cost-benefit and other analysis. Senior management will have their responsibility to accept or reject, pend or delay a change request. This is not interference, this is procedure, and you must understand you have to follow it, without taking anything personal. You as project manager had a duty to provide justification for the change, if any. Senior Management has the authority to say NO. This is not interference.

How can we keep the whole process completely transparent?

There should not be hidden agendas or secrets in a project from its stakeholders. If that is the situation, you are facing, be sure of the conflicts rising among stakeholders and misgivings taking root. If otherwise it is not a matter of some national security or something, everything in a project should be completely transparent and there should not be any effort to hiding some information from a particular stakeholder. When you record the needs and expectations of the stakeholders, you very well know what is the requirement for interaction, engagement and communication with each of the stakeholder.

We must understand, we need not overload all stakeholders with all the data, as they may not be interested in irrelevant information and this will be a case of Information Overload. The information not required by a stakeholder, if provided anyways, may be detrimental to the health of the project. You must maintain a fine balance, and only provide the information required by each stakeholder. We cannot overload the stakeholders on the name of transparency. Similarly we cannot hold the data required to be transmitted to a stakeholder, which is called Data In Jail, in which you have imprisoned data which was otherwise supposed to be elsewhere with a demanding stakeholder. Both these extremities are to be avoided and project manager is the best judge how to keep her stakeholders engaged.

I hope I was able to respond to the BIG question.In case, something still needs to be clarified further, I will be pleased to elaborate further.

THANKS
Sort By:
Network:1057



Thank you for your inputs!
...
1 reply by Suhail Iqbal
May 18, 2017 12:25 PM
Suhail Iqbal
...
You are welcome
Network:60085



May 18, 2017 5:05 AM
Replying to Sonali Malu
...
Thank you for your inputs!
You are welcome
Network:598



I challenge the notion that project management has no authority to say no to a change. I recognize that there are organizations where this is true, but it is also possible to define a change management process where there are different levels of approval required, based on the impact of the change. If documented and approved by the project sponsor, this approach can help alleviate micro-managing.

Admittedly, when I use this approach, I make very few of the decisions outside of simple changes to scope or schedule. Changes that have the potential to increase budget get more scrutiny and require a higher level of approval.

This may not work in every organization or on every project; multiple variables affect the decision making process. But that is all it is - a decision making process. If you can make this approach work, your leadership will likely be grateful they don't have to be involved in every single decision.
...
1 reply by Suhail Iqbal
May 18, 2017 7:34 PM
Suhail Iqbal
...
We can agree to disagree but in this fast changing world of project management which is almost agile now, there will no more be any space left for anything but servant leadership.
Network:1208



Thank you, Suhail. Change happens ... it is seemingly inevitable. I find that earning the trust and respect of the Stakeholders, and providing open, consistent communication with transparency goes a long way in the ability to offer recommendations in response to potential change - impacts (cost, schedule, scope, quality), recommended solutions, provide insights, reasons, and guidance behind those recommendations.

Then just take it from there. In this month's theme, no need to create complexity for the sake of complexity.
...
1 reply by Suhail Iqbal
May 18, 2017 7:33 PM
Suhail Iqbal
...
Thanks Andrew for a wonderful but brief synopsis.
Network:591



Several years ago, i inherited a project in distress which had a customer, project sponsor, and a program manager, all from different organizations. As the project manager, I had not just to keep the project moving, but to satisfy several people, often with differing views of the project.

The program manager would attend meetings and demonstrate the various iterations of the software to his bosses, who would always have changes. he expected those changes to be made--without deleting anything from the project slate. That led to three different contractors eventually dealing with the project, which, by the way, had no real ending date. BTW,m this was not an agile project, at least not officially, but the Program Manager had a week or so of agile training and considered himself a scrum master plus.

The customer simply wanted a set of software that worke,d and since it was data-driven required quite a bit of ETL conversion and integration. The project sponsor was an IT- oriented organization that considered itself one of the industry's best, and routinely second-guessed every iteration to the point that the change list/defect list was larger than the product task list.

In all of this, the program manager wanted changes, refused to create formal change orders, and launched into a tirade that contractors were routinely cheating him with costs, and we could simply absorb the changed out of our extraordinary profit ( 8% on average)

This project was the only walk-away for me in my adult life--it was simply not possible to get the parties to agree. That project is still ongoing, has changed its scope myriad times, and, frankly, the reason for it has long-since passed, but they nevertheless continue.

That's the story of a horror waiting to happen to anyone who does not enforce reasonable change management.
...
1 reply by Suhail Iqbal
May 18, 2017 7:32 PM
Suhail Iqbal
...
Very good real-life story to make everyone aware of disadvantages of taking the change lightly. Change is not for light hearted.
Network:60085



May 18, 2017 1:28 PM
Replying to John Tieso
...
Several years ago, i inherited a project in distress which had a customer, project sponsor, and a program manager, all from different organizations. As the project manager, I had not just to keep the project moving, but to satisfy several people, often with differing views of the project.

The program manager would attend meetings and demonstrate the various iterations of the software to his bosses, who would always have changes. he expected those changes to be made--without deleting anything from the project slate. That led to three different contractors eventually dealing with the project, which, by the way, had no real ending date. BTW,m this was not an agile project, at least not officially, but the Program Manager had a week or so of agile training and considered himself a scrum master plus.

The customer simply wanted a set of software that worke,d and since it was data-driven required quite a bit of ETL conversion and integration. The project sponsor was an IT- oriented organization that considered itself one of the industry's best, and routinely second-guessed every iteration to the point that the change list/defect list was larger than the product task list.

In all of this, the program manager wanted changes, refused to create formal change orders, and launched into a tirade that contractors were routinely cheating him with costs, and we could simply absorb the changed out of our extraordinary profit ( 8% on average)

This project was the only walk-away for me in my adult life--it was simply not possible to get the parties to agree. That project is still ongoing, has changed its scope myriad times, and, frankly, the reason for it has long-since passed, but they nevertheless continue.

That's the story of a horror waiting to happen to anyone who does not enforce reasonable change management.
Very good real-life story to make everyone aware of disadvantages of taking the change lightly. Change is not for light hearted.
Network:60085



May 18, 2017 1:26 PM
Replying to Andrew Craig
...
Thank you, Suhail. Change happens ... it is seemingly inevitable. I find that earning the trust and respect of the Stakeholders, and providing open, consistent communication with transparency goes a long way in the ability to offer recommendations in response to potential change - impacts (cost, schedule, scope, quality), recommended solutions, provide insights, reasons, and guidance behind those recommendations.

Then just take it from there. In this month's theme, no need to create complexity for the sake of complexity.
Thanks Andrew for a wonderful but brief synopsis.
Network:60085



May 18, 2017 1:07 PM
Replying to Aaron Porter
...
I challenge the notion that project management has no authority to say no to a change. I recognize that there are organizations where this is true, but it is also possible to define a change management process where there are different levels of approval required, based on the impact of the change. If documented and approved by the project sponsor, this approach can help alleviate micro-managing.

Admittedly, when I use this approach, I make very few of the decisions outside of simple changes to scope or schedule. Changes that have the potential to increase budget get more scrutiny and require a higher level of approval.

This may not work in every organization or on every project; multiple variables affect the decision making process. But that is all it is - a decision making process. If you can make this approach work, your leadership will likely be grateful they don't have to be involved in every single decision.
We can agree to disagree but in this fast changing world of project management which is almost agile now, there will no more be any space left for anything but servant leadership.
...
1 reply by John Tieso
May 19, 2017 9:07 AM
John Tieso
...
Indeed, it can be very dangerous for a PM to be making changes which more appropriately belong to the Project Sponsor, or even the ultimate customer. A lot depends on the grant of authority to the Pm in the charter, and any other agreements which may be in place Some organizations have a culture which says to take the action if it is logical, reasonable, and has no significant added cost. Others say you have to have approval. There must be a median ground somewhere that makes sense.
Network:591



May 18, 2017 7:34 PM
Replying to Suhail Iqbal
...
We can agree to disagree but in this fast changing world of project management which is almost agile now, there will no more be any space left for anything but servant leadership.
Indeed, it can be very dangerous for a PM to be making changes which more appropriately belong to the Project Sponsor, or even the ultimate customer. A lot depends on the grant of authority to the Pm in the charter, and any other agreements which may be in place Some organizations have a culture which says to take the action if it is logical, reasonable, and has no significant added cost. Others say you have to have approval. There must be a median ground somewhere that makes sense.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Weaseling out of things is good. It's what separates us from the other animals....except weasels."

- Homer Simpson

ADVERTISEMENT

Sponsors