Everything and the kitchen sink

In project management, scope creep (or kitchen sink syndrome) refers to changes, continuous or uncontrolled growth in a project's scope, at any point after the project starts. It typically occurs when the scope of a project is not properly defined, documented or controlled from initiation. However projects will only ever achieve their spending objectives and deliver the agreed outputs, capabilities, outcomes, benefits and/or value if they have been scoped robustly, planned realistically and cost justified from the outset and the associated business and service risks taken into account as part of informed investment decision making.

Setting out the boundary 

An important action for any project owner (the role ultimately accountable for the success of the project) is to effectively set out the boundaries or limitations of the project. In doing so, the project manager role should have a detailed understanding of what is and what is not in scope. The project scope, therefore, must be explicit in terms of geographic coverage, user base, functionality and service requirements. This to ensure that time is protected and that only viable, desirable and achievable options within the agreed scope are assessed, particularly as the project iteratively builds a compelling case for change for project funding. If scope remains vague and open to interpretation, then the resultant impact will no doubt be ‘scope creep’ and additional capital costs either at or after the procurement phase. In practice, it is beneficial to assess the potential scope and the associated service requirements in terms of a continuum of business and service needs, ranging from ‘core’ (minimum requirement) to ‘core plus desirable’ (intermediate requirement) to ‘core plus desirable plus optional’ (maximum requirement). 

Being in control

Given the project manager role is accountable for the day-to-day management of the project, they should take care not to deliver beyond the agreed project scope as this is a common cause of delays, overspends and uncontrolled change (‘scope creep’). No doubt every project is unique with its own environmental characteristics, size, complexities, importance, capability and risk. During the lifecycle of any project, potential risk threats may materialise into an issue. Depending on the nature of that issue, the project manager may be able to resolve any problems or concerns within the delegated authority. Alternatively, off specifications occurs when the solution or service fails to do something that it should have as agreed in a customer contract, requiring contract management liaison with the supplier. Lastly, requests for change refers to where a senior user or stakeholder requests for additional service coverage or functionality due to an increase in user base numbers or changing business requirements.

Exceptions to the rule

All issue types require expeditious decision making by the most appropriate authority. But every decision should be made within agreed boundaries or tolerances for the management stage or project. Requests for change will ultimately require decision and advice from the project board as to how the project should proceed next. Decisions outside of the management stage that impacts project tolerances for - time, cost, scope, quality (criteria), risks and benefits - will require escalation and advice from the program or main investment board (sponsor) to determine funding impacts to organisational budgets. Analysing a project in this way helps to provide a compelling case for spending as opposed to it simply being ‘a good thing to do’. As such organisations should not underestimate the importance of staying within approved budget and delivering early. After all, less than optimal value delivered early is always more attractive to a customer than seeking maximum value delivered later.

Forest for the trees

Project boards should only consider and approve requests for change that prove value for money or return on investment in terms of benefits realisation relative to overall spend. Adding additional geographic coverage, increasing the user base and/or business or service requirements may appear to be a good idea but this often leads to gold plating. Delivering a product and/service over and above minimum requirements. For this reason any additional funding requirements must always be analysed in terms of its accumulative impact on the organisational budget. The money saved can always be better spent on investing in prioritised pipeline ideas rather than continually changing the boundaries of existing projects.

In summary, successful projects are ones that operate with defined limits. Scope needs to be defined, agreed prior to project initiation and effectively managed. Otherwise uncontrolled change could eventuate where everything and the kitchen sink is included. Any project changes, therefore, to geographic coverage, user base, functionality and service requirements must always be assessed in terms of expected benefits relative to overall project spend as well as accumulative impact to organisational budgets. While it might be easy to make continual changes to scope; do not underestimate the importance of achieving deadlines and staying within budget when delivering value to customers.

References

• Office of Government Commerce (now AXELOS Global Best Practice),  Managing Successful Projects with PRINCE2, 2009
• HM Treasury, public sector business cases using the five case model  - green book supplementary guidance on delivering public value from spending proposals, 2013