Welcome to the second of twelve articles where we talk about the do’s (and some of the don’ts) of Agile Project Management. During this series we will work our way through the 12 principles of the Agile Manifesto and talk about how it relates to you, a project manager and your project.

This week’s principle is Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (Beck, 2001)

Change is hard.  Change, for Project Managers, is often challenging. Why? Because Project Managers (PM) have often been trained to set a schedule, set a budget, set a timeline, create deliverables, a Gantt Chart, a Statements of Works or maybe a Project Scope.  All these items are to be documented and take hours, days, weeks and sometimes months to put together. The PM documents what needs to happen for a project to successfully get off the start line, run 100 metres and cross the finish line! There are boxes to tick that ensures that everything will run smoothly and in the end, management will see how successful the job was because the Project Manager can produce a magnificent comprehensive closure report!

In reality, projects rarely work this way! In a recent project I was managing, the scoped processes sometimes had changed the very next day after the process was scoped. The developers and customers had a fantastic relationship and the project was forging ahead a lot faster than what I had prepared for.  It was my job to change the plans to accommodate this. The customer wanted to bring forward some of the benefits that were in phase two. The only problem that I had was that my manager, the owner of the company, wanted everything to be documented. He wanted the before and afters. I had to explain to him multiple times that although it was possible it was not practical nor logical.

Goal posts change in all projects. Harness the change, even if it is not always in a direction that you, as a Project Manager, would like, trust that the people who are suggesting the changes are doing it for the right reasons but also try and manage it. Try using some of these techniques:

• Communicate the change as soon as you can
• Explain, explain and explain until there is an understanding of the change.
• Be patient. Remember change is hard.
• Try and involve affected people. Be inclusive!
• Try to incorporate the change in a structured way; and
• Make sure the organisation changes along with you.

Be sure to bring your team along for the ride. Most teams welcome changing requirements, even late in development, if it is part of the culture.  Humans are experts at adapting to change and in software development this is especially true.

References

Baldauf, K. (2020, February 24). Change Management – Why Project Managers will also have to be change managers. Retrieved from The Project Group: https://www.theprojectgroup.com/blog/en/change-management-in-projects/

Beck, K. B. (2001). Agile Manifesto. Retrieved from Agile Manifesto: http://agilemanifesto.org

Harris, E. (2018, Augus 12). 7 Causes of Project Change. Retrieved from Strategy Execution: https://www.strategyex.co.uk/blog/pmoperspectives/7-causes-project-change/

Hughes, K. (2019, 07 31). The Agile Manifesto, Explained. Retrieved from Project Manager: projectmanager.com/blog/agile-manifesto-explained