Avoiding Project Scoping Failures

September 22, 2017


An expensive pitfall when retaining tech consultants is kicking off a project without understanding its details. From a delivery standpoint, projects are most often counted as failures for either going over budget (time or dollar) or not delivering what the client expected. While extremely common, the risk of missing the target on budget and deliverables can be eliminated before the project starts.

The devil is in the details, but it takes time and effort to flesh them out. “Take your time” is the antithesis to “always be closing”, but having an airtight game plan in place from the start will save everybody involved a world of pain. While consulting firms can help sidestep the pitfalls of rushing into projects, clients can be guilty of glossing over details and communicating their grand vision instead of the hard deliverables they need produced.

Here are some steps you should take to ensure your projects go smoothly:

Take time to explore the project’s facets. Talk through and document things like workflows, corner cases and user experience. To avoid scope creep, possibly the biggest risk to modest-sized projects, there should include a lot of “what if?” and “what about?” questions. This will define scope, help stakeholders learn to identify sub-requirements and acclimate them to thinking in terms of deliverables. As an example, consider a requirement to include a web based monitoring tool. We drill into details by asking sequences of questions such as: Is there a login? Can users reset their passwords? Is there a user management requirement? Is a single sign-on platform like Facebook going to be used?

It quickly becomes clear that something as simple as “it needs a web page”, generates many questions that should be answered up front. Turning nebulous statements into concrete requirements will generate huge returns on invested time.

Create in-scope / out-of-scope documents. Use what is learned in the above to create an “In-Scope” section to your SOW. These items should correspond to line items in a project tracker shared between the client and consultant. If you do a good job planning, you’ll know the project is completed when each item is marked “Done”. It’s also good to also have an “Out-Of-Scope” section in your SOW. This is where the fuzzy line between in-scope and out-of-scope is made clear. This should identify the project’s boundaries preventing feature creep, a common cause of budget overruns.

Budget for contingencies. Assumptions may be incorrect. A client’s promised internal resource may become unavailable, management may demand that a previously out-of-scope item be moved in-scope, or some deliverable may prove to be much more difficult than estimated. Budgeting wiggle room will give some flexibility to move out-of-scope when the project’s overall success depends on it. Alternatively, agree ahead of time how expansion of scope midstream will be invoiced. This will prevent potentially contentious negotiations later. As a rule of thumb, if you feel confident that you have done a good job scoping, price out the project based on the time for each deliverable plus 20% to account for anticipated deviations from the original plan.

Identify and document project risks. There may be aspects to the development that are known to require some post-kickoff discovery. This can create create variability. Similarly, there may be known externalities with the potential to hinder the project’s progress. Try to bullet out the most likely. If these risks end up impacting the project’s course, the stakeholders will not feel blindsided.

Start with a leader / assessment project first (optional). A very tangible reason why pre-commencement scoping doesn’t happen is because it is expensive. Getting into the nitty gritty of features, workflows, risk assessments and corner-cases can be a serious undertaking. These pre-closing costs are usually baked into the final contract award, but it creates a disincentive to make the due investment in project scoping because the consultants will be out of pocket if the deal doesn’t close. Pre-sales expenses are a cost of doing business, but when requirements gathering is a project unto itself, consider executing a separate SOW prior to diving headfirst into the more ambitious project. To make a good case business case for what seems like paying to get a quote, attach deliverables such as a risk assessment, proof of concept or system architecture designs for the large project under consideration. This effectively front-loads the project’s work while allowing the consultant’s to give the clients due attention in the discovery process. Optimally, the leader project will be structured to deliver value irrespective of how or when the larger project is implemented.

Clients and consultants will inevitably identify requirements, scope and scale. If you do it before diving in headfirst, you’ll be working with a known quantity that can be tracked against. Otherwise, you’re risking budget overruns, a sour business relationship and a black eye for everybody involved. By working carefully to understand what’s really needed, clients and consultants can dramatically improve their chances of success.