The Importance of Program Scope Definition
The scope of a program is essential to thoroughly understand for any project or program. All assumptions should be captured in a document that is intended to define the program scope, like a statement of work (SOW). The project scope provides a definition of the objective of the cross functional team. Having the results match the program scope is how the program team knows their work is complete.
If it’s that important and everybody knows the definition of it, you think it would be an easy thing to define and manage. However, most projects involve some sort of concurrent engineering. So, the definition of what is required to satisfy the ultimate customer almost always changes at a component level so that the sum of the parts meets customer expectations. These changes in scope are not usually a problem if all parties involved properly use a program change management system to track changes and the impact they will have on the progress of the program. The impact can be felt in the cost, timing or quality to deliver the program.
For both the customer and the supplier, there can be some benefit to vague program definition. Customers will argue that some content or feature was implied and should be included in the program with no impact to cost, timing or quality. Suppliers will argue that if that content had been included it would’ve been in the SOW and would’ve been itemized in the quotation. Either way, the point is they argue. So, the less vague the program scope definition, the fewer arguments there should be over expectations.
Scope Creep
Scope creep is a change to the original scope that is not paid for and alters the expectations that the customer has on the supplier. The change could be either a more detailed definition that increases the complexity or simply a change to the expected output of the program. The change to expectations is usually an increase in the demands on the supplier. It is essential to understand that changing the scope of the program might be essential to satisfy the customer. So, it’s not the change, itself, that is a problem. How publicly it is discussed, how well it is documented and how completely the impact of the change is bought into by customers, stakeholders and the cross functional team will determine whether it is a well managed change or scope creep that decreases the likelihood of program success.
As already discussed, as a program is executed and concurrent engineering progresses, the requirement for changes will be identified. If these changes are not added to the SOW or managed through a change control system then they are an increase in expectations. They are often verbal or only documented in email and there is no opportunity to quote the impact to cost, timing or quality. It is essential for Program Managers to recognize scope creep and to vigilantly protect against it. Scope creep increases the demands on the program team, which makes it more challenging to achieve a successful outcome.
If scope creep is allowed to happen and it leads to the customers “crept expectations” to not be met, the program team will be forced to explain how they fell short when they might’ve actually met the original program scope expectations. The Program Managers leadership team will wonder why the customer is unhappy and they won’t know the details of how their expectations have changed. All they will know is it will look like the team failed.
A Program Manager’s job is to close the gaps in perception on the progression of a program. The gap between the customer’s expected outcome for the program and the actual outcome is directly related to scope creep. The gap between internal stakeholder’s perception of program outcome and what was expected is a combination of their distance from the details of the program and scope creep. So, it is the Program Manager’s obligation to ensure that stakeholder and customer expectations are constantly managed and project scope is constantly referred to as the finish line. Furthermore, it is their obligation to ensure that any attempts to alter the expected outcome of the program are taken from the ethereal output of conversations and the electrons of emails and added to the statement of work with stakeholder and customer buy-in for the impact to the program.
Elegance Creep
When the program requirements are met but either the customer, or someone like an engineer on the cross functional team, continues to incrementally change the product in the apparent search for perfection, this can be referred to as elegance creep. These efforts are made with the best of intentions.
“If I only spend one more day or one more week on this feature, it will be better” is the thought that provides the compulsion for elegance creep. They might be right. The product might be better. However, “better” wasn’t a part of the program scope when it violates program timing. Taking that day or week for elegance creep that was above and beyond the expectation of the SOW is a luxury you don’t have when all downstream functions (Purchasing, tooling, suppliers, testing, Manufacturing, etc.) will be forced to absorb your selfish consumption of program timing just to get their jobs done in the minimally acceptable way. It is essential for Program Managers to protect these downstream functions and hold the early activity on the program to rigid timing expectations. In a four-person relay race, the last runner can’t sprint and make up for the first running walking or jogging their portion of the race. Everybody has to deliver on time.
Conclusion
Defining the scope of the program and getting the buy-in of stakeholders, customers and the cross functional team is a non-negotiable requirement for every program manager. Equally as important is defending the approved scope against all scope and elegance creep unless the impact of the changes has been used to temper the expectations of everybody involved.
The scope of a program is essential to thoroughly understand for any project or program. All assumptions should be captured in a document that is intended to define the program scope, like a statement of work (SOW). The project scope provides a definition of the objective of the cross functional team. Having the results match the program scope is how the program team knows their work is complete.
If it’s that important and everybody knows the definition of it, you think it would be an easy thing to define and manage. However, most projects involve some sort of concurrent engineering. So, the definition of what is required to satisfy the ultimate customer almost always changes at a component level so that the sum of the parts meets customer expectations. These changes in scope are not usually a problem if all parties involved properly use a program change management system to track changes and the impact they will have on the progress of the program. The impact can be felt in the cost, timing or quality to deliver the program.
For both the customer and the supplier, there can be some benefit to vague program definition. Customers will argue that some content or feature was implied and should be included in the program with no impact to cost, timing or quality. Suppliers will argue that if that content had been included it would’ve been in the SOW and would’ve been itemized in the quotation. Either way, the point is they argue. So, the less vague the program scope definition, the fewer arguments there should be over expectations.
Scope Creep
Scope creep is a change to the original scope that is not paid for and alters the expectations that the customer has on the supplier. The change could be either a more detailed definition that increases the complexity or simply a change to the expected output of the program. The change to expectations is usually an increase in the demands on the supplier. It is essential to understand that changing the scope of the program might be essential to satisfy the customer. So, it’s not the change, itself, that is a problem. How publicly it is discussed, how well it is documented and how completely the impact of the change is bought into by customers, stakeholders and the cross functional team will determine whether it is a well managed change or scope creep that decreases the likelihood of program success.
As already discussed, as a program is executed and concurrent engineering progresses, the requirement for changes will be identified. If these changes are not added to the SOW or managed through a change control system then they are an increase in expectations. They are often verbal or only documented in email and there is no opportunity to quote the impact to cost, timing or quality. It is essential for Program Managers to recognize scope creep and to vigilantly protect against it. Scope creep increases the demands on the program team, which makes it more challenging to achieve a successful outcome.
If scope creep is allowed to happen and it leads to the customers “crept expectations” to not be met, the program team will be forced to explain how they fell short when they might’ve actually met the original program scope expectations. The Program Managers leadership team will wonder why the customer is unhappy and they won’t know the details of how their expectations have changed. All they will know is it will look like the team failed.
A Program Manager’s job is to close the gaps in perception on the progression of a program. The gap between the customer’s expected outcome for the program and the actual outcome is directly related to scope creep. The gap between internal stakeholder’s perception of program outcome and what was expected is a combination of their distance from the details of the program and scope creep. So, it is the Program Manager’s obligation to ensure that stakeholder and customer expectations are constantly managed and project scope is constantly referred to as the finish line. Furthermore, it is their obligation to ensure that any attempts to alter the expected outcome of the program are taken from the ethereal output of conversations and the electrons of emails and added to the statement of work with stakeholder and customer buy-in for the impact to the program.
Elegance Creep
When the program requirements are met but either the customer, or someone like an engineer on the cross functional team, continues to incrementally change the product in the apparent search for perfection, this can be referred to as elegance creep. These efforts are made with the best of intentions.
“If I only spend one more day or one more week on this feature, it will be better” is the thought that provides the compulsion for elegance creep. They might be right. The product might be better. However, “better” wasn’t a part of the program scope when it violates program timing. Taking that day or week for elegance creep that was above and beyond the expectation of the SOW is a luxury you don’t have when all downstream functions (Purchasing, tooling, suppliers, testing, Manufacturing, etc.) will be forced to absorb your selfish consumption of program timing just to get their jobs done in the minimally acceptable way. It is essential for Program Managers to protect these downstream functions and hold the early activity on the program to rigid timing expectations. In a four-person relay race, the last runner can’t sprint and make up for the first running walking or jogging their portion of the race. Everybody has to deliver on time.
Conclusion
Defining the scope of the program and getting the buy-in of stakeholders, customers and the cross functional team is a non-negotiable requirement for every program manager. Equally as important is defending the approved scope against all scope and elegance creep unless the impact of the changes has been used to temper the expectations of everybody involved.
RSS Feed
