The project manager’s job is to buffer the project team from the vagaries of change, but that said, it is essential to recognize that change is constant. It is the rare project that runs from start to completion without change. Thus, the successful project will be executed by a team, and led by a project manager capable of adapting to change.
Change can come from any quarter. Most frequently project changes stem from new or modified requirements. With some process appropriate to the size of the project and the culture of the shop, requirements changes can be managed. But change is sneaky. It may well come from an unanticipated direction. A very limited list of possible sources of change includes: staffing change (resignation, promotion, reassignment, illness, etc.), budget change (sadly, usually downwards), corporate reorganization (mergers and acquisitions included here), competitive situations, sales (see the blog entry on chasing the next sale), loss of the key customer for this project, partner relationship changes, vendor changes, changing deadlines, and pure corporate politics.
How does a project manager deal with change? When does the project manager inform the team and when should such information be withheld? When does the project manager inform upper management of project changes as opposed to managing against them? There is no definitive answer to these questions. On highly complex projects with rigorous, published tracking metrics, change often needs to be addressed head on and openly, early. On smaller, more contained projects it may make sense to buffer a manageable change. Corporate culture and management style also play a pivotal role in how change should be handled, as do the extent and immediacy of impact of the change.
Project managers who work for me get significant latitude. My management style gives the project manager a clear objective, an understanding of the strategy the project fits within, and the charter to manage to success as she or he sees fit. I expect to be informed of problems that cannot be solved within the project and that require my support. I expect to learn about significant changes of schedule. I encourage project managers to work through problems that are addressable and to seek support where they are not. I tell both project managers and development teams who work for me that, above all, I don’t like surprises that come up too late to be addressed. Experience as a project manager, and the experience the project manager has with the current team play a large role in when a project manager needs to raise a flag.
From the other direction, I may learn of a change of priorities that impacts one or more project teams. My job, managing a team of project managers, is to ensure timely communications where appropriate. For example, a major new customer has signed an agreement. The schedule to bring that customer online requires resources currently committed to other projects. Working with other senior managers, priorities and schedules must be evaluated in order to free the appropriate resources. In some cases, resources may be needed from multiple teams … it’s rare that one lower priority project is staffed by a team appropriate to the new customer project. Senior management’s role is to support the decision process for adjusting priorities and schedules. The project / program management team must implement the changes dictated by reallocating resources, adjusting schedules, and ensuring that work in progress that is to be deferred gets properly parked. For example, code is documented and saved to a recoverable configuration, development and test systems are properly backed up before being reallocated, design and code artifacts are saved with sufficient documentation detail to recover when the project is resumed, and test plans are similarly preserved.
Of course, this kind of change leads to the inefficiencies of context switching (see the note, “Flail Leads to Fail”) and can be dispiriting for the team members affected. It is in such situations that the project / program manager must ensure the affected team(s) have sufficient information regarding the reasons for the change to understand. At such times, I remind team members of my mantra: the only constant is change.