As a senior program/project manager I spend most of my professional career in international program/project management, focusing on distributed projects in multi-cultural environments. People I work with recognize me for my ability to assess a situation quickly and define adequate and pragmatic actions to bring projects back on track. My style of management can be characterized as can-do, a pragmatic approach focusing on delivery.
Managing the scope of a project is one of the main instruments to manage the project budget. Over the years I have a developed a more holistic view on scope management, discovering budget overruns are not always due to changes to the functionality but also due to changes in project approach. Another reason is the willingness of the project team to make the project a success and therefore spent time on support activities not foreseen at the start of the project.
As a result I describe scope in terms of FANGs:
Functionality
Activities
Non-functional requirements
Governance
This article explains the thinking behind the concept and provides examples and tips to manage each of the aspects.
Functionality
Functionality starts with having the business/functional requirements signed off. It's pretty straightforward as soon as the approval and the sign-off has been obtained. From that moment on, the functionality is under change control. The only potential budget consumer is impact analysis. All projects have a standard change-control procedure in place, which starts with approval for impact analysis. How many of you have a separate budget for impact analysis, irrespectively if the change will be approved?
Besides the additional work that might not be covered in the budget, there is