WEEK 2 1

Activity 2

Gautam Gurnani

Summer 2022 - Project Management Processes (BADM-623-M21) - Full Term

Dr. Watts

University of the Cumberlands

May 15th, 2022

WEEK 2 2

Summary

As stated in the textbook, “Scope creep is the term that has come to mean any change in

the project deliverables that was not in the original plan. Change is constant. To expect otherwise

is simply unrealistic. Changes occur for several reasons that have nothing to do with the ability

or foresight of the client, the project manager, or a project team member. Market conditions are

dynamic. The competition can introduce or announce an upcoming new version of its product.

Your management might decide that getting the product to market before the competition is

necessary. Scope may not be affected by the schedule change” (Wysocki, 2019, p. 31). Scope

creep is very common in the project management life cycle. In simple words it is the part of he

requirements that is missed during the gathering session. Again, it was a miss in terms of the

requirements that was not assessed or was not part of the initial requirement gathering as the

scope of the project was changed after its commitment. Scope creep is technical not a miss on

any team, ideally it is due to the fact that as scope of the committed project was altered as we

live in the dynamic world and the needs of the customer or the technical team has changed

through its time.

In most of the scenarios it is identified later and has to be dealt with to be part of the

project. Scope creep is not a reflection of the team’s performance or not to be considered as a

performance criterion in the team evaluation as this requires more than one team to work in

coordination to identify if the scope creep leads to technical debt or change of functionality.

From a project managers’ perspective, it is important o identify how to deal and accommodate

this change in the current planning or implementation of the project (Ajmal et al., 2020).

As a senior product manager for a health-tech company, we have come across these

scenarios where we identify a technical aspect that should have been part of the implementation
WEEK 2 3

or the scope was missed due to lack of awareness of the innovation we were working on. This

change that has been identified could be a API link that leads to better integration

communication between the system or something small that could have been missed by the team

when gathering the requirement or while working on the feature definition. Either of the

scenarios these has to be a small or extra small miss of the scope- which then becomes

permissible. If the scope identified as a miss is big and requires a complete turn around of the

team working on it, then it is big change and is definitely because the team did not asses the

situation better.

As a team, we then discuss the changes with architecture on what the impact to include it

if identified as a must have feature. Later on if this change/ scope is approved as a group as a

must have requirement, we then accommodate this to the release as a hot fix or the quick fix to

support the change.

WEEK 2 4

References

Ajmal, Khan, M., & Al-Yafei, H. (2020). Exploring factors behind project scope creep –

stakeholders’ perspective. International Journal of Managing Projects in Business, 13(3),

483–504. https://doi.org/10.1108/IJMPB-10-2018-0228

Wysocki, K. R. (2019). Effective Project Management: Traditional, Agile, Extreme, Hybrid (8th

ed.). Wiley.