Managing scope creep
Of course project delivery is about delivering fit-for-purpose outcomes which often requires going above and beyond the call of duty to achieve customer satisfaction. This flexibility is part of the domain we operate in, so it sounds completely logical to accommodate small or apparently zero impact changes as required. Point one is definitely true, but the second is a value based proposition.
In slotting in a minor change by working after standard hours as an act of goodwill, leaving your time and cost constraints untouched, have you done the right thing by the project? Unfortunately there is no such thing as a free lunch as somebody pays for additional work whether this be a financial impost or wear and tear on the team. Whilst for some it will be fine to do a few extra hours in the name of customer service, it may have quite a significant impact on other team members.
Consider those with childcare costs to pay (after hours pickups can exact extortionate costs) or other life priorities - such as a having a life. How many times can you ask the same volunteers, those who only seem to work and sleep, to rise to the challenge before they start to ask questions about unequal treatment. As for the PM, do you want to start drawing down your credit in the bank of goodwill for minor reasons. Before you know it, you have set a precedent with your customer and scope creep has now become a real threat.
Besides your actions, some customers are also extremely project process savvy, knowing multiple minor changes avoiding a formal change request can achieve the larger change that would not be accepted if assessed on merit. Creeping the scope may also be tried when management who are used to getting their way, get their first knock back.
More destructively, a pattern of variations may be hiding an omission or failure on the customers behalf so they attempt to bypass process and scrutiny by going straight and silently to the PM. Mistakes happen, and whilst it's part of having a good relationship with your customer and your stakeholder management skills to deal with the odd faux pas, beware what impact the precedent and allowing this type of issue to slide will have on your authority in their eyes. Sadly the idiom "No good deed goes unpunished" holds true.
So, is this problem unique to waterfall and does it highlight one of the more significant shortcomings of that approach? We are led to believe Agile overcomes such issues and turns these problems into positives by ensuring that change is embraced and acted upon to in response to value based judgements and discoveries. Shuffling the product backlog in an Agile project allows new and changing priorities to be readily acted upon and increases the likelihood of a fit-for-purpose outcome being delivered does it not. Well yes, and no.
Most application features do not exist in isolation and are not as plug and play as Agile practitioners may have you believe. Stories exist as part of an epic or theme, and as the backlog focuses on stories if the added story transcends an epic, then dependent supporting stories in that epic must also be delivered to constitute useable value. The minor two point story change may require one or two full sprints to deliver the supporting capability. Conversely, if the product owner drops a story or stories to accommodate last minute changes, work done on the epic to date that is still wanted may be unusable until subsequent releases and effort in the short term wasted. Waste that a bit of planning may have avoided.
Therefore I don't believe Agile solves the problem of scope creep by default, and I don't believe if managed correctly it is a problem for waterfall projects. At any time, a waterfall project can change tack and introduce new features. The same levers exist for PRINCE2 as they do Agile, though the procedures for doing so are different. Just like Agile, in more structured project management you can horse trade work at a minor change level as easily as follow the CR process for larger ones. The difference is you may be operating with greater definition and obligations around time and budget constraints.
The non-Agile limitations on rapid flexibility will actually serve to have the requester think harder about the value the creep in scope will deliver before going ahead. You can also give them the option of placing the feature into the road map for a subsequent release. Most waterfall application development projects have release road maps these days. In today's rapidly evolving technology and business environment, nobody realistically expects an initial solution to be valid in its entirety for long, and I believe Agile (or its forbears) can claim the kudos for this improvement in thinking and delivery.
Not establishing clear processes for managing change before execution is something that can have severe repercussions if customer roles change throughout the project. If you have creepy scopied, or left the door open a bit, to accommodate your initial stakeholders as a favour due to trust and familiarity then you may rue the omission. When changes in sponsors, product owners and in some cases end-users occur, you need to have formal ground rules to fall back on, mechanisms for management and power, should it come to a clash of priorities or force of personalities.
The lesson to be learned here, and hopefully not one on the job, is it will be too late to provide structure and controls around managing scope creep when it starts to occur, it must be done and agreed (by document and contract) up front. Just like everyone in an Agile project knows how they will be managing change by applying the methodology, if you are not doing iterative/Agile it will require knowing, communicating, agreeing and following the process irrespective of who the stakeholder is - and enabling you to be flexible if, when and where it is safe to do so.
