Advice to Banks and Credit Unions for Establishing Website Development Budgets
If you're in charge of determining a budget for website development & ongoing management for a bank or credit union, the most critical success factor is ensuring you follow a reliable formula. One such formual is:
Reasonable Expectations + Reasonable Budget = Likely Success
“How much should this project cost?”
That’s an important question and it's critical that you involve the people most capable of answering that question accurately early in the process. In nearly all cases, you'll need key technical, creative, and management people with expertise in the technical processes, as well as the strategic & tactical goals of the organization to arrive at a reliable answer.
Should I Be Secretive About My Budget?
No, not usually. Developing custom websites is similar to building a custom house in many respects. In the same way it is important to tell your house architect whether you have $100,000 or $1,000,000 before any design work starts, in the same way it is helpful for your web team to know their budget constraints when proposing solutions to achieve your goals.
You will get the most value from talented website development experts by sharing as much information up front as possible. In addition to budget, there are other key questions that help guide good budgeting:
- If the project is successful, how much total value will the bank or credit union realize?
- What is the value of each key goal, if successful? If financial or other resources are constrained, which opportunities present the highest value and least risk?
- What are the opportunity costs associated with either acting or not acting?
- What key dates or deadlines are critical to realize full benefit of the opportunities?
- What resources are available and to what extent will the team be able to use them?
An experienced team can often accurately predict which types of functionality are reasonable for a project based on the available budget. For example, if you only have a budget of $5,000 for your entire project, then a good team will recommend only options that are reasonable for that budget and will best maximize your return on that investment.
By sharing your budget limitations early and openly, you will save yourself time in the long run by allowing your team to present realistic solutions that fit within your budget.
Why do estimates vary from one team to another?
In my career, I have worked on projects that had budgets ranging from $5,000 to millions of dollars. While a $5,000 website and a one million dollar website are both websites, the effort to produce them and the functionality each delivers is vastly different. When a team does not have accurate, detailed information, it is forced to make assumptions about goals, resources, value, and constraints. Assumptions vary widely from one person to another and one team to another, which usually results in drastically different cost estimates between teams. This makes it very challenging for you, the client, to compare choices.
Real World Example of Drastic Cost Estimate Variance
When you ask a team of developers how much it is going to cost to develop your website or mobile app, the estimate is going to largely depend on three factors:
Specific functionality of the website or software
Types of skills necessary to build the functionality
Billing rate for each of the people involved
The functionality differences, or worse, assumptions of functionality differences, are often the cause of large cost estimate variances between equally capable teams. Your idea of a generic term such as “Branch Locator” or “ Secure Login” may be radically different from the person sitting next to you or the programmer who is reading your request for proposal. Whenever possible, avoid ambiguity. The best way to avoid ambiguity is to have in-depth conversations during the earliest planning phases with the team you plan to work with on the project. Experienced teams will ask critical questions that help to ferret out details to determine realistic, accurate budgets.
Let’s look at a common example that will illustrate how two different development teams can estimate one set of functionality very differently.
Let’s suppose that you want to hire a development team to build an online customer portal. On your requirements list, you include the following feature:
“Requirement #1: A user should be able to login to the customer portal”
You contact two different development teams for an estimate. The estimates you receive back are:
- Team A - $300 (2 hours)
- Team B - $4,500 (30 hours)
WHOA, that’s a big difference! What makes Team B’s login feature so much more costly than Team A’s?
How Assumptions Drive Estimates
Let’s assume for the sake of this example that both teams are equally competent and both work at the same pace and roughly the same hourly rate. If both teams work equally fast and have comparable skills & hourly rates, why are the estimates so different?
To understand the difference, we need to examine the assumptions each team made about your very concise login requirement.
Team A’s Estimate
- You will ask the user for only for a username and a password
- Username and password values will be stored in plain text in the code
- There are no rules about the length, complexity, or expiration of a username or password
- A user can attempt to logon as many times as he wishes without ever locking out the account
- No audit log will be kept of failed or successful login attempts
- No feedback will be returned to the user if he enters an incorrect username or password, rather the login form will just reload with blank inputs if the login credentials are incorrect
Team B’s Estimate
This team approached your requirements with an assumption that you wanted a high level of security, user-friendliness, and a lower long-term support and maintenance costs. Their assumptions:
- Users will logon with a username and password
- Multi-factor authentication will also be available for each user account
- Username will be stored in a secure SQL database
- Passwords will be hashed and only the hashed value will be stored (as opposed to the real password), which is impossible to decrypt and very nearly impossible to crack.
- The app will prompt users with a challenge question when logging in from a computer that the user has not previously logged in from.
- The system to automatically lock an account after a certain number of invalid attempts
- To aid users who have lost their passwords, Team B’s estimate includes an automated password reset procedure.
- Team B also assumes that you’ll want a way to manage your users without having to edit the programming code, so they’re planning to build a secure administration portal for the application.
- Team B knows that keeping a good audit trail of system access is important to security conscious companies, so their estimate also includes writing code to record a log of all activities performed on the website, including failed login attempts, password changes, password resets, and many other common security related activities.
- Team B also assumes that you want to lower the risk of introducing bugs into your website as you add new features, so they’ve planned to build automated tests into their code that will execute every time your website is deployed. This will help to prevent new code from breaking existing functionality.
Same Name, Very Different Results
The example above is one that we encounter often in our practice and illustrates clearly why you can receive widely varying estimates to develop something as common as a “user login.” Both feature sets described above meet the criteria for allowing a user to login; however, Team B’s approach will clearly require more time and cost, but you may see more value in one approach versus the other.
Candid Budget Sharing Can Give You More than Reasonable Software Estimates
Most development teams I have worked with want to maximize the value of the software they create. With a trustworthy, capable team, there is very little risk of a team delivering less value than you’ve paid for. The opposite is usually true, especially if the team you’ve hired knows that you’ve been honest, you’re easy to work with, and they believe you respect them.
I can speak for the team here at Inet, and others I’ve worked with, when I say that we all genuinely love to help people succeed. Building custom software is a profession based on serving others. We build technology that millions of people use every day to make their jobs and personal lives easier to manage, more secure, and less aggravating. I also see the hundreds of hours that Inet team members put into projects for our clients that never show up on an invoice, simply because the men and women here enjoy helping those clients, even if that means doing work that the client cannot pay for. The team members here simply do it out of a love for the work and helping others. The people who are most likely to receive these benefits are, not surprisingly, those who have built relationships based on openness, trust, and mutual respect. I cannot speak for all people, but here at Inet you’ll definitely earn a return on your investment in openness.
Find this useful?
Want to receive our monthly tip to make your website easier to use and safer? No spam, just good advice. Signup!