The fear of scope creep, project slippage and 11th hour requirement changes has kept many a soul up at night. These announcements usually bring on an array of issues, chief among them monetary implications for both the project manager and the client. All resulting in a crazy frenzy for that last-minute, must-have feature. But what are we really fighting? Who are we blaming? Ourselves? The client? The angry one-eyed project monster?!?! It is far easier to point the finger at someone else, but like Granddad once said, 'When you point your finger at someone, there are 3 fingers pointing right back at you.' Advice well worth taking and advice that I aspire to always remember.

The real problem is most scope battles are fought in reaction mode rather than in anticipation mode. So let it be written, let it be done, that if a project is worth doing, it is going to have scope creep. Why not plan for it? Why should we view scope creep as a negative? Let's instead try and focus our efforts on what we can do about it., Is there a way to plan for scope creep rather than make ourselves crazy trying to avoid it? No there couldn't be…that would be …impossible? Call me crazy, but here are a few guidelines that can help manage the fragile edges of a scope. Not every project will allow for these guidelines to be implemented so utilize your 'thinker' and use these guidelines as a framework for potential ways to avoid the pitfalls.

  1. Don't avoid– anticipate! Address scope creep up front in the project budgeting and sales cycle. Something WILL come up that was left out of the initial requirements gathering process. Allowing space in the budget for this gives you and your client room for additional efforts that will inevitably come up.

  2. The Golden Schedule: Schedules vary, plans change, vacations arise and sickness can be unavoidable. Be sure to incorporate these things into the planning process for both your project team and the client. And always allow for plenty of time for feedback turn-around and the often under-appreciated QA (quality assurance) process.

  3. Know Thy Scope: The only way to manage scope creep is to keep track. It is critical to provide ongoing project documentation (business and technical requirements, wireframes, user-flows, designs, etc.) and the critical reference material that validates scope is being met and adhered to. Equally important is the expectations of your client and their understanding of the scope and subsequent approval. It is far easier to demonstrate to a client where scope is being crept when expectations are understood from the beginning.

  4. Educate, Share, and Empower: The customer is always right. But is there a path to lead them in the 'right' direction? It is important to ensure the client knows what to expect from the process and why the process exists. Managing expectations in the beginning is critical to managing overall scope. Clients can then feel empowered to share the same expectations and plans in the beginning and can assist in understanding overall change implications.

  5. Chase Down the Butterfly: When things do arise that fall outside of the agreed to requirements, meet with your entire team to understand the full ramifications. What seems to be small can sometimes have broad reaching implications, resulting in the butterfly effect. The risk of the butterfly effect increases as a project is further along so the later in the project the more critical this becomes. Managing this quickly is critical.

  6. Stamp of Approval: Once a new requirement is identified and understood by your client and internal team, document in a mutually agreed to manner. This can take the shape of a very formal change control process or be as simple as an email correspondence that contains the specifics agreed to. The key is to document so everyone understands the details and process for proceeding. Memory is fallible.

As I noted previously there is not one cut and dry solution to any scope creep. I often use an example/analogy in many different forms that basically sums up scope creep. How many times have you gone into McDonald's (and/or insert other fast food restaurant) here and asked for extra ketchup? Do they give it to you? Do they speak rudely to you and throw the ketchup at you? Or do they simply say, 'I'm sorry but if you look on your receipt you will notice your meal only came with two packets. If you would like to discuss additional ketchup options, I would be happy to arrange the conversation." Well they probably wouldn't say that and in most cases I hope they would just give you the ketchup w/o any of the above drama.

However, as is the case with most projects, we are not dealing w/ a simple packet of ketchup, however similar rules apply. The point is that in 99% of cases the client might just not understand the rules of the game. The bottom line is that project process is about anticipation, communication and conversation. If a PM ever finds themselves mad at a client, then in those 99.9% of the cases, they didn't do any of these6 steps up front.