Successful Website Design Projects Begin With Solid Project Scoping

Set Expectations Early by Clearly Defining the Website Design Project

We often receive requests for cost and timing proposals without having any requirements or expectations defined by the prospect. Real sample verbiage from inquiries include:

• “I need a new website and require a cost and timing estimate.”
• “Please look at my existing website and provide a proposal for update.”
• “Looking for a price to move our site into WordPress. Have a look at the site and let me know a rough price, then we can talk details.”

These brief descriptions of the website design projects – or really lack there of – are a recipe for disaster.
Custom WordPress websites can range from $3,000 – $500,000. Developers need to know specifics to grasp where your project resides on this large range of budgets. The larger and more complex the build, the higher price for execution.

The more information a prospect provides at the initial inquiry, the more precise I can be with my response. This not only helps me know if we are a potential fit, it allows the prospect to quickly qualify us in or out as a technology parter.

As your WordPress developer, I cannot execute the project to your satisfaction if I don’t have a solid understanding of your expectations. Honestly I cannot even begin to quote it at this point, because I don’t have a good sense of what equates to success for you and your website. I can make assumptions, but that opens us both up to a lot of risk and it exponentially increases the potential for failure.

Assumptions also increase project cost. When a project has a large number of unknowns, developers will add in a cushion to cover the margin of error. For the buyer, this could equate to $1,000 or $10,000 in costs that may or may not be needed.

Shocking right? Yes, but it is reality nonetheless.

Here is a real world example of why strong expectations management is so critical to website design projects:

I once had an technology association ask for “Salesforce integration” as part of their large, multiple page proposal. They could not initially define the nature or extend of the integration needed. I spent multiple days inquiring and giving them specific questions to ascertain the true nature of this requirement.

The WordPress.org plugin repository does have a few Salesforce plugins that are designed to handle basic lead to Salesforce integration, but this is basic integration. I could have assumed this and quoted a few hundred dollars to set up and test this functionality in their new website. My inner voice of sanity told me this is not what they needed and making this assumption would lead to significant issues later on. Due to this, I did not take this route in our RFP response.

What the association really wanted was a more advanced API integration that required data to be pushed back and forth between Salesforce and WordPress, while also reconciling data along the way. In more fancy terms, their true needs included a transactional plugin within WordPress that will both listen to SalesForce.com and talk to SalesForce.com to ensure that each of the proper transactions are received and sent as necessary. Transactions would be cached in order to achieve both optimal performance, as well as avoid hitting any API rate limitations. This Salesforce coding was estimated at approximately 50-60 development hours by a senior level coder. That equaled many thousands of dollars in coding and it increased our proposal cost by about 15%.

We scoped this part of the proposal to the more advanced integration. I know I am one of the few developers who did this, because of the prospect’s responses to my questions. I could tell other developers were not asking the same questions. This should have been a red flag for the association, but I could tell it wasn’t. They should have noticed the variance in developer inquiries and they should have noticed that the level of scoping was not the same from one developer to another.

The outcome for the association would be website proposals that were mismatched in planned functionality. This would give them a situation of comparing apples to oranges. You cannot adequately compare apples to oranges and obtain a successful analysis. This is a clear mismatch of expectations and it leads to a stressful and costly execution.

My Salesforce example has happened many times – for just Salesforce alone. After the above scenario I knew to quickly define the true nature of the integration. And if a prospect tells me to figure it after contracts are signed (I’ve really had that happen), I decline the opportunity and explain that the risk is simply to great for us move forward with the selection process.

I do this to protect our firm and to protect you my prospective client. I hope that my exit will raise a red flag for the selection team and they will reevaluate and refine their requirements to protect their project.

Provide Substantive Answers to Developer Questions

When someone asks us to participate in a selection process, we start asking a ton of questions. We do so because in most cases, the potential client hasn’t defined who they are or what type of project they’d like us to quote.

If I have a solid understanding for your company and your project, I can determine if we are a suitable fit. And more importantly, I can determine if my team can successfully execute your project.

Many times my endless questions surprise a prospect, because other developers are not inquiring in the same manner that we do. This is a problem and it should be a warning sign to you as the buyer.

If your potential developer doesn’t inquire about your business, product or service offering, and goals or objectives – they cannot properly quote or execute your project.

I ask a lot of questions, because it helps me formulate a solution for the project. The answers I receive allow me to build out the project in my head and this helps me prepare hypothetical solutions, determine if we are a fit, and evaluate if we can successfully implement the project.

The more questions I ask, the more prepared I am to offer a solution. As the buyer, you should want a solution and not just an estimate.

As my prospective client, you should answer my questions as completely as possible. It’s as simple as this – when I ask a question, give me a solid answer. That seems basic, but people are busy and they reply quickly to questions and many times these responses don’t provide actual answers. Responses like “I think so” or “maybe” are not answers at all. They are risk for me the developer and you the buyer.

One-word answers to an in-depth question will sound alarms for me because they are signs of risk and potential project failure. This type of dialogue can indicate future communication issues, so I will be wary of you and your project.

If you are considering a website redesign, take the time to properly establish expectations with your developer. The more you define and document now, the less you will argue about mid-project.

Identify and Articulate Your Requirements

For a developer, every web design client is unique. Our goal is to obtain a solid understanding of a client’s needs and adapt our standard development plan or process to meet those needs.

Many times we receive requests for proposals where the client has not yet thought about the website’s functional requirements or even what type of visual presentation they would like.

A lot of inquires will include the word “simple” and not be at all simple. As a developer I’m okay with complex as long as the project plan and budget supports it.

If you have a list of esthetic or functional needs in mind, document these and present them with your inquiry. This will provide a great starting point for discussion.

If you are really unsure about what you need, this is okay too. For more simple projects this can be determined within the sales and scoping process. For more complex projects, it would be best to have paid discovery phase where a trusted WordPress developer is paid to work through the definition and documentation of your needs.

Paid discovery isn’t for everyone, but when it is possible, it is a great alternative to assuming unnecessary risk.