Before we can dive into the reasons why web development projects fail, let’s start by defining what “project success” really means. 

What is Project Success? 

Most experts agree for a project to be considered successful it needs to:

• Be completed on time, and within budget 
• Result in an end product that fully meets the agreed-upon business requirements 
• Retain the developing party’s planned profit margin 

If any of these points are missed, the project should be considered less than 100% successful. When you can consistently achieve all of these metrics on ALL projects, you will very likely have a successful agency. 

Seems like an impossible dream? I assure you – it is not. The key is understanding the common challenges that stand in the way of that success and using proven project management techniques to overcome them.

Why Our Community Ignores This

The website development community in general, especially home-grown WordPress agencies, is typically focused on 3 things:

• Technology – What is the best (and coolest) tool for getting the job done?
• Associated Services – What other services, such as SEO, copywriting, sales funnels, and the like, should we be offering?
• Building/Scaling – How can we grow our business?

While these are important, most people don’t realize that successful project management is the mechanism that keeps your profit margin on target by keeping a close hold on the scope, cost, and timeline.

The 6 Primary Reasons Website Development Projects Fail

Reason #6 – Not Considering Project Risk 

A risk, with regard to project management, is defined as an occurrence you think might happen – and if it does, that occurrence will impede the project in some way. 

Most website providers try to pretend as if everything will go as planned all of the time. The truth is though –  it just never happens that way. What happens if your lead developer gets sick? What happens if you, a solopreneur, lose power for a week due to a storm? What happens if the client disappears mid-project?

The actual risks to project success will always vary from project to project, but there is at least one risk that exists on EVERY project: when the client or a 3rd party does not comply with the schedule (usually around content-related activities). If you don’t have a plan to mitigate (or address) this risk, your project will most likely fail.

Solution: Develop a Risk Mitigation Plan

Your proposal or contract should include a Project Risk section that lists the risks to the project, and how you will address them if they occur. For example, you might state that “team member illness” is a risk. Your mitigation plan may be that you have an equally talented person to fill in, should that happen, so there should be little to no impact on the project. When it comes to the content collection, you might state that “non-adherence to the agreed-upon schedule” is a risk and as mitigation, refer to your contract section regarding delayed and abandoned projects.

Assessing and planning for potential risk increases the likelihood of completing the project on schedule. Reviewing your project risk assessment with your potential client during the proposal phase also sets you apart as a true professional, and who already has a PLAN should things go awry.

Reason #5 – Performing Unpaid Work

There are two primary reasons website providers can end up carrying out unpaid work, thereby reducing their profit:

• Not implementing a paid Discovery session
• Not charging for changes as a “good faith” gesture 

Solution: Charge for Discovery and ALL Requirement Changes

The 2-Step Proposal Process we use, and also teach our students, is to operate under an initial contract that includes a range estimate to be fleshed out during Phase 1 – Deep Dive Discovery. After we’ve finished the deep dive, we provide a more precise estimate that includes any new requirements discovered along the way, and a “go/no go” decision is made.

• If the decision is GO – we continue on to Phase 2 under the newly contracted estimate.
• If the decision is NO GO – our client receives their website specification, and we get paid for all the work we performed to date. Everybody ultimately wins.

Many practitioners believe that throwing in a feature or two at no additional charge is “over-delivering” or a “good faith” gesture. Sometimes the team does this of their own volition because they “think” the client will like some cool feature (this is called gold plating) but most often it is due to the client asking for “one more, little thing”. 

The problem with this approach is that once you do any work for free, the client will continue to expect it. It can also mean that a lot of tiny “good faith” gestures add up to a LOT of free work given away – and of course, much loss of profit

It’s best to develop a solid change control process and educate your client about this very early on. The two most important rules regarding creating a good change control process are:

1. NO work is performed, or feature created, without written, client-approved requirements. That typically puts a stop to gold plating and the related loss of profit.
2. The change control process is invoked without exception because unmanaged scope creep is reason #3 that web development projects fail (see below).

Implementing these practices to avoid performing unpaid work not only helps keep your project within budget, but also helps to retain your planned profit.

Reason #4 – Poorly Defined Requirements 

Incomplete or incorrectly defined requirements are usually due to jumping into the design of the website way too early, instead of giving proper focus to the results that are to be achieved.

Many practitioners have a brief pre-proposal meeting, present the proposal, and then begin designing without a more in-depth discovery session. This happens for a number of reasons, but most often because either the development team is anxious to get to the “fun” part, or everyone is approaching the website as “art”, and not as the marketing tool that it is.

Sadly, once you broach the “look and feel” of the site with the client, most find it difficult to focus on anything else and, try as you might get back to the functional requirements, it is like pulling teeth and will slow progress.

In other cases, it’s a matter of lack of experience and knowing the right questions to ask.

Solution – Use a Checklist and Break Things Down

Inside the WP Project Manager’s Academy, we teach students to:

• use our exhaustive pre-proposal questionnaire as a launch pad for ensuring you ask the right questions to offer a proper estimate
• break down the deep dive discovery into multiple deliverables, each of which builds on the previously-approved deliverable
• position the deep dive discovery as Phase 1 to ensure you’ll get paid for the activity.

Conducting the in-depth Discovery in this way will ensure you delve deep enough to uncover all the requirements – and that you get paid for doing so.

Reason #3 – Unmanaged Scope Creep 

As previously mentioned, scope creep is most often due to the client asking for small changes over and over again, and the development team agreeing to implement them at no charge. Often, when all those small changes are added up, a significant loss of profit margin is the result.

Solution: Actively Manage Change

Believe it or not, you can completely eliminate scope creep from your list of project challenges by acknowledging with your client that project change is inevitable, and having a solid plan in place to manage change. You will also need to ensure that you invoke your change control process without exception.

To do this, you will need a change control process that, among other things:

• Includes a change budget
• Explicitly defines what constitutes a change
• Defines who can approve the change
• Specifies when change requests will be paid by the client

Managing change in this way ensures that the end product meets the agreed-upon requirements, you get paid for all you do, and the project is completed within budget.

Reason #2 – Inadequate Estimating 

The biggest mistake web agencies make in this area is providing too precise an estimate too early. Many will do this after only a brief discovery session with the client, and this almost always ends up with an estimate that does not reflect the actual scope of work. You need a deep dive discovery for which you get paid (see #4 above).

You’d be surprised how many practitioners use a “best guess” approach to estimating based on their belief of how long the entire job will take, multiplied by an hourly rate. This is the crystal ball approach to estimating, and almost always results in project failure.

Solution – Develop a Repeatable Estimating Process

The truth is, to get better at estimating, you need to practice. The more you do it, the better you will get at it, but only if you analyze each project to determine where you missed the mark. The best way to get started is to use a Work Breakdown Structure or Project Plan that lists all the Phases, Activities, and Tasks. When you do this, you’ll likely be surprised how many things you are actually doing for which you have not been charging the client.

Start at the task level, and estimate the time you believe each task will take, keeping the following best practices in mind: 

• Estimate the magnitude of content to be collected, created, and organized, and ensure your client can commit to the necessary tasks.
• Be sure to include all administrative tasks, such as preparing status reports and meetings with the client. 
• Consider who exactly will be completing each task and estimate accordingly (clients may take longer to write content than a copywriter).
• Roll up the Task estimates to the Activity and Phase levels to devise the overall project estimate.
• Explain to the client that any estimate is based on the requirements known at that time, and could change depending on whether the requirements change.

Reason #1 – Project Delays Caused by the Client

Most website providers who complain about clients not meeting the scheduled dates always mention content collection as the biggest bottleneck. This can result in delayed or abandoned projects if not managed properly. 

Solution – Educate, Incentivize, and Penalize

Most clients do not understand what is involved in a website development project – even though they may think they do. If that is the case, it is YOUR job to educate them. You can do this by:

• Including this type of delay in your Risk Mitigation Plan
• Reviewing a rough order of magnitude for the content – this can often convince the client to have someone else create and gather content
• Collaborating on the due dates for the tasks the client will complete
• Including in your proposal and other project documents:
  • Turnaround times for reviews and approvals
  • Incentives for meeting the agreed-upon dates
  • Penalties for missing the agreed-upon dates

By developing a process for a content collection that includes these best practices you significantly increase the likelihood of getting your projects completed on time.

Conclusion

Just as there are proven reasons projects fail, including completing the project over budget, delivering the solution late, producing an end-product that does not meet agreed-upon requirements, or ending up with a lower-than-expected profit figure, there are proven processes to circumvent those issues. These include:

• Ensuring projects are completed on time and within budget, by developing a Risk Mitigation Plan.
• Avoiding losing profit as a result of carrying out unpaid work, by developing a paid discovery process and having a solid change control procedure.
• Increasing the likelihood of a quality end-product, by using a checklist for questions and breaking the discovery into multiple, separately-approved deliverables.
• Minimizing loss of profit due to scope creep, by actively managing change.
• Consistently completing projects within budget, by developing a repeatable estimating process that uses a mathematical formula.
• Reducing delays caused by the client, by making sure you educate them on the importance of meeting the agreed-upon dates and offering incentives for doing so.

If you’re interested in learning how to consistently deliver successful projects using these proven processes, I invite you to consider joining the FREE WP Project Manager’s Academy and earn your WP Project Manager’s certification to set yourself apart from the competition.

Simply put, the logical boundaries of your project are your project’s scope and the best analogy for understanding it is to consider it a fence or corral. All the activities and tasks inside the fence will be carried out during the project and everything outside the fence will not.

Suppose something outside the fence should be moved inside later. In that case, it requires a very specific and well-executed set of instructions for opening the gate – namely, your Change Control process or procedure.

Very early in the project, the scope should be defined and documented. That’s the easy part. During the project, the challenge is controlling it.

The Importance of Defining Project Scope

The purpose of defining scope is to clearly describe and gain agreement on the project’s boundaries before the project starts. It seems simple enough. But, sadly, it is human nature to make assumptions. 

First, your clients will assume that certain things will be included or excluded from your website development project. This is not their fault. They likely use the internet every day and may presume that all websites include a particular feature that they see very often, so they never think to mention it. On the other hand, they have a business to run and have likely spent very little time learning and understanding the true nature of web development. And don’t even get me started on the ads that claim you can build a website in an hour. Your clients are being misled by such things. But again, this is not their fault.

Your clients need you to educate them about what is included in a website project (specifically YOUR project) and the project scope statement or document is the foundational piece of client education.

At the same time, you or your team members will likely make certain assumptions about what your client understands and expects. 

Your agreed-upon scope statement clearly defines what is inside the fence, and what is not, so there are fewer misunderstandings and rework requirements later on. It is only possible to successfully manage project scope IF you’ve done a good job of defining the scope upfront.

Understanding The Risk Of Scope Creep

Scope creep is a dreaded and insidious thing that can happen with any project if measures are not established to prevent it. Scope creep occurs in several ways: 

1. The client asks for that one tiny (or big) thing, and you agree to do it even though it was not in the agreed-upon scope or estimate.
2. You add a feature or element because you “know” the client will like it or because it’s “cool”. While the intent is admirable, this is called gold-plating and is pure, unadulterated scope creep for no reason.
3. Your estimate and scope included a particular solution that turned out not to be viable, so you use an alternative solution without updating either.

But you’re not alone. Almost ALL projects suffer from some form of scope creep, and both project teams and clients are consistently frustrated by it.

When Should You Define The Project Scope?

Your project scope begins to reveal itself even in the initial pre-proposal meeting. As you uncover BUSINESS requirements for the website, some things will immediately be considered included – or excluded.

For example, if your retail brick-and-mortar client doesn’t want to sell their products online, but wants customers to be able to view them, then a catalog solution is in scope – while eCommerce is clearly out of scope.

The initial project scope is typically agreed upon via the Project Proposal or Contract either in a single scope section or in several sections covering the necessary information. This section should be as detailed as possible and clearly highlight the activities that are in scope for both your team AND the client. It is essential to let the client know that the scope statement agreed upon in this step is based on what you know at that time, and could change during the project using your Change Control Process.

The Difference Between A Project Scope Statement and Project Discovery

The Project Scope statement is typically included in the Proposal. It includes a high-level list of the major activities that will be carried out during the project. It should also include those activities that are specifically excluded, or out of scope. In other words, it defines WHAT will be done.

Project Discovery, on the other hand, is the first activity to be carried out once the proposal is approved. It takes much longer to perform and document and results in a Statement of Work (or website specification) that includes the nitty gritty detail of HOW the activities in the Scope Statement will be carried out.

Who Should Be Involved In Creating the Project Scope Statement?

The first draft of your Scope Statement is included in the proposal. It should be reviewed with the client during the proposal or contract walkthrough. It is not uncommon for the initial Scope statement to be updated with agreed-upon changes before the final proposal is submitted for approval.

What Should Be Included In A Project Scope Statement?

The following should be included in every scope statement. Some additional items may be needed for some specific project types.

• Timeline – a list of project phases with a high-level description of what is accomplished in each phase.
• Team – a list of individuals to be involved in the project with roles and responsibilities
• Project Activities – A list of major activities with an indication of who will be carrying them out
• Out of Scope – A list of activities that will NOT be carried out as part of this project
• Change Control – your process for controlling scope creep

I once reviewed a student’s proposal where he had done an excellent job defining what was In Scope for the project but had nothing listed as Out of Scope. Instead, he had only this statement: “Anything not mentioned or listed in this proposal will be considered out of scope.”

While I respect the intent, it is much safer to go ahead and clearly define the out-of-scope elements in detail. Remember those assumptions? That’s what the out-of-scope section is about. Make sure there are no incorrect assumptions by listing the activities that will not be carried out as part of the project.

The 6 Steps to Defining Project Scope

Step 1 – Identify Boundaries

First and foremost, boundaries must be established regarding when changes will be allowed to the scope, and how that will take place. This is typically done by including your established Change Control process or procedure. 

It’s also important to note that requests for changes to scope should ONLY be considered an opportunity and NOT an aggravation or annoyance. Change is going to happen. You’ll be more successful if you embrace it and invoke your change control process without exception.

Step 2 – Identify Responsibilities

Clients often think that once the proposal is approved, they can disappear for a few weeks, after which you will deliver a website. Most don’t realize that their day-to-day involvement is necessary and that some activities are solely their responsibility. We do this in two ways:

• Project Roles and Responsibilities – we include this in every proposal to drive home how much is involved in a website project, as well as clearly spelling out the client’s responsibilities.
• A Scope Chart – Lists the Activities with an indication of In Scope (for me), In Scope (for the client), and Out of Scope (see step 6).

Step 3 – Include All Items That Are in Scope

Gather the activities from your Project Plan and include them in your Scope Chart. It’s essential to be specific here. It’s no good just saying that your agency will build the client a website.

• How many pages?
• What will be on those pages?
• What functions are needed?
• What devices should the website be optimized for (desktop, tablet, mobile)?

Remember that clients will often tend to assume many things, and won’t always appreciate that, for example, responsive designs don’t just happen, or that contact forms or other interactive content isn’t necessarily a stock part of every website.

If your agency will be building a wireframe, include in your scope the ways in which this design will be approved, and by whom (make sure it’s a named individual). Remember, the client’s responsibilities and roles need to be a defined part of the scope every bit as much as your own.

Step 4 – List All Items That Are Out of Scope

This takes a little more practice, but if you’ve got a standard list of project activities, you can re-use this and designate in the Scope Chart which of those are not included for this specific project.

It helps if you already have a list of elements that could potentially be included in the design and development of a website, and then specify those which will not be included. This may in some instances prompt the client to reconsider the project scope, perhaps not realizing that certain elements would not be included. It is far better to have that discussion at this stage of the project than several weeks down the line when a huge amount of work has been achieved and you believe the project is nearing completion.

Again, just as with the previous step, make sure you are specific about those elements or tasks that will not be included in the project. This can include, for example, the design, redesign, or optimization of their logo (often overlooked), the sourcing of stock images, or the taking of new custom images.

Step 5 – Separate the In-Scope Items to Theirs or Yours

We do this using three columns in the Scope Chart, as shown in Step 6. It’s critical to appreciate when designing a project scope document that it covers both your tasks and obligations as well as the client’s.

Failure to include the client fully in the project scope can give them enough wiggle room to cause all sorts of problems. For example, it will be their responsibility to approve designs promptly. If they don’t, then the project can drag on, taking far longer than planned, potentially costing more, and then overlapping with other projects.

Then of course what you don’t want is for the client to suddenly show up and wonder what all the delay is for. Since there might be no mention of their responsibilities and roles in the project scope, that could make for a very challenging conversation.

Including their roles and tasks very specifically also gives you the opportunity to include statements identifying what actions would be taken in such a situation, such as including a percentage rate for a project kill fee.

Step 6 – Use Charts for Clarity and Brevity

Here is a partial example of the Scope Chart we use and teach the students in The WP Project Manager’s Academy to use. A chart like this allows the client to see where each item falls quickly and easily.

In this table you can see we have four columns, the tasks or elements of the project, which of these will be both in scope and your responsibility, which of these will be both in scope and the client’s responsibility, and which of these are entirely out of scope.

Having a stock table like this produced ahead of time makes it much easier to then work through for each client what will be included and what won’t. If you don’t have something like this now, then building a list of tasks for each project and compiling this into an archived table, to which you add any other tasks other projects may require, will give you a useful resource for the future.

Don’t Forget the Care Plan Scope

If you offer maintenance or care plans to your clients (we require it), it is imperative to spell out what IS and is NOT included in each plan and STICK TO IT.

This includes timeframes, contact methods, and precisely what tasks, elements or features will be supported, and to what extent. Again, make sure that you are as specific about what won’t be included in this care plan as you are about what will be. Doing otherwise can become a costly and time-consuming mistake.

Final Thoughts

Aside from your estimate, your scope statement is the most crucial element in your proposal because it sets the project boundaries and the expectations of all those involved. At a minimum, a well-defined scope statement includes:

• A description of the timeline
• Team roles and responsibilities
• Project Activities 
• Activities that are Out of Scope 
• A description of your Change Control process

Controlling scope creep is a primary function of managing any project, but you cannot manage it successfully if it isn’t well defined at the project outset. Once approved, any changes to the scope should only be made via an agreed-upon change control process that is invoked without exception. Our proposal template and example inside the Premium membership to The WP Project Manager’s Academy gives a thorough relevant example of how your scope can be defined for ease of client understanding.