Many companies have web applications that require ongoing tweaking and maintenance. A common solution is to hire a third-party supplier to provide this level of software maintenance and support.
It’s important to evaluate the quality of the relationship you are likely to have with these suppliers. Unexpected downtimes or issues with your web app mean serious costs for your business. You want the confidence that comes from covering all the bases to get the best service possible from your supplier.
The evaluation process, however, can be difficult. It’s a challenge to wade through all of the factors that comprise the totality of a supplier’s value. A few characteristics that need to be evaluated:
- Quality of contracts or service-level agreements (SLAs)
- Experience level
- Project management style
This guide (one of a series) will walk you through some ways to get clear about the quality of service you are receiving from your web development company. (Some of these evaluation methods will also be relevant if you are using an in-house team.) Treat this article like a checklist so you can evaluate the various characteristics of your supplier with clarity and precision. We’ll also highlight some issues you’ll want to pay particular heed to.
Contracts and SLAs
You absolutely need a contract with your developer.
Even if you’re completely happy with your current supplier’s service, it still makes sense to review your current working arrangements and get things on the level legally.
Here are some important General Factors to consider when evaluating contracts and service-level agreements (SLAs):
Scope of work: SLAs should clearly lay out what you can expect in terms of the type of work they will do and the amount of work. Is the scope clear? Are your expectations being met?
Responsiveness: Does the SLA clearly spell how many hours you will get when the app has a pressing problem? Does it clearly spell out how quickly you will start receiving service? Does it clearly spell out how much you will “jump the queue” to start receiving immediate attention? Are there any limits or extra charges?
Transparency of operations: Does the SLA provide you with some transparency into how they structure projects and schedule deliverables? Ideally, you want an SLA to show that clear communication is part of their process.
IP issues: If your app has proprietary coding and it’s important to protect that intellectual property (IP), you want to make sure a contract addresses that concern. Also, if a supplier is supplying you with code, you want to make sure that the code’s IP is entirely held by the supplier, and that there won’t be third-party complications with you using it.
Other legal concerns: Some contracts have a general stipulation that a supplier is adhering to all relevant regional laws (for example, IR35 legislation in the UK). Ideally, you want to ensure that you are protected from potential legal issues that could result from a supplier’s business or employment practices.
Things to Double-Check
Below we’ll give you a few areas where you want to pay particular attention. If these are not already in place, then you’ll want to make sure that you address them.
- You have no contract with your current supplier. Sometimes informal agreements are not enough, and it is best to be cautious. At minimum, you should get a basic contract that covers the general scenarios and get it checked by a lawyer. Then you can draw up specific schedules or scopes for each particular deliverable ensuring both parties are covered.
- The General Factors (above) are not present in your contract. Check any contracts and SLAs to ensure most of the above criteria are addressed. A glaring gap in an agreement could lead to trouble down the line.
- Promised service isn’t adequate. Usually, there are two essential questions: How many hours of work does my SLA entitle us to? How quickly will that work be done?
To be proactive, you should go through an SLA and ask yourself these questions: if the worst-case scenario happened–a major problem with the app–would the speed and amount of service be adequate? What would be the consequences if the app were down for x amount of time?
If there is a significant downside to your app being down and you’re not sure if your supplier will provide you with what you need, that could be a problem.
History and Experience
Understanding a company’s history and experience is key for evaluating their quality and expected future service and deliveries. Some important factors are:
Historical presence: How long has the company been around? How long have the company’s principals been around? Their longevity in the industry tells you a lot about their level experience and knowledge. Most importantly, it also tells you a lot about their financial security and the likelihood of their availability for the long term.
Team experience: How respected are the company’s team members? Are they respected in the PHP community? Do they contribute to open-source projects? Do they speak at industry conferences or meetups? Knowing that a company is widely respected can help set your mind at ease.
Testimonials: Does the company have a good number of testimonials or case studies? This is a good indicator of reliability. You also want to see if the testimonials relate directly to the work you need. Sometimes a company has great testimonials for their dev work but no testimonials for their ongoing support/service. Look closely.
Project specialisation: What kinds of projects does your supplier focus on? Are those projects similar to the needs of your project? Do they typically work on open-source projects and not proprietary code? Full-stack web apps or back end code only? The more a supplier’s focus aligns with yours, the better.
Technical competence: In the same way, you want to know if there are certain technologies that a company uses and certain technologies they don’t use. For example, maybe they’re focused on using a specific content management system (CMS), like Drupal or WordPress, and that’s not the appropriate tool for the job you’re presenting.
If you’re looking to have a more complex web application created, then maybe question which PHP framework they’ll be using. What version? Is it the latest? Do they have experience maintaining other sites using it? If it’s their own framework, then how many installs are there? Do they maintain older versions?
Location: In our digital day and age, location isn’t always a factor, but it can be. There might be a big difference between the time of day your company works and when the support company works. Check the time zone; it may mean significant lags in response time when something goes wrong. Some countries have different weekdays that constitute their work week, and this can be a cause for lags as well.
Things to Double-Check
Again, there are a few areas where you want to pay particular attention.
- Evidence of experience. There are several ways a company can prove its competence and experience to you (e.g., a history of work, testimonials, past service to you). If your PHP app is integral to your business, you want to feel confident that things continue to be handled correctly.
- Technology or project congruency. Ideally, you want a company that regularly handles the kind of project and the kind of technology you work with. A supplier could be the most technically skilled on the planet, but if they aren’t focused on the kinds of problems you face, this mismatch could result in problems like lack of focus on your projects, lack of interest in the size/profitability of your project, and lag times if they don’t understand the needs of your project.
- Availability. Gaps in response could be due to location and time zone issues, or could be due to project management problems (to be discussed below). You want to get clear on what potential factors could lead to current or future response-time issues.
How a supplier structures their projects and how they approach their work is very important. A company’s project management style easily makes the difference between mediocre and excellent service.
A few of the most important factors:
Communication and transparency: Of all project management factors, this is the most important. Without transparency and clear communication, you don’t have an understanding of how your project is being handled, which makes it hard to evaluate anything else. Clear communication means telling you upfront about how the work is done, knowing how the communicate milestones are set and communicated to you, and keeping you abreast of issues and progress.
Timeline management: Part of clear communication is having an organized way of setting timelines. Some companies use Gantt charts, some use their own original spreadsheets, some use dedicated project scheduling software. No matter how timelines are set up, you should be clear on how your supplier is planning out your project and how they plan on completing it. (This applies not just to large dev projects but also to quick, emergency fixes.)
Prioritization and philosophy: How are the supplier’s projects and tasks prioritized? What system or philosophy do they use? Is it an Agile approach? Or a Waterfall approach? You want to get a sense of there being a methodology behind how they decide which clients and projects are most important. Their approach could impact how your project is treated and impact their response times.
Things to Double-Check
You need a healthy working relationship with your developer. They may be excellent coders but not so good at communicating. If there isn’t a clear project management process in place, then you need to work together to cover the areas listed below, at a minimum.
- Unexpected charges are not acceptable. Put systems in place so that you cannot be invoiced for work done unless there’s a work order or simple scope of work clearly communicated and approved by you beforehand. Provide them with a purchase order to give them the confidence that you’ll pay. It’s a win-win.
- You require timelines. Goals and milestones need to be communicated regularly. For even small projects, a fortnightly Skype or Google Hangout meetings will be a great high-bandwidth way to keep abreast of what’s going on and whether things will ship on time.
- It’s not always urgent. You want everything now, naturally. But try not to run the job at a constant sprint. Pace things out; allow for slack and holidays. Is that “immediately before Christmas” deadline really appropriate? You want it delivered in a timely fashion, but be willing to accept a sensible and well-paced timeline as long as you’re only being billed for the time being spent on the project.
- Constant deliverables. You want to be clear about how your developer structures their timelines and how they work on your project. Even if it’s a sizeable development project, you should expect to see something to look at or test on a relatively frequent basis.
So far, we’ve talked about some high-level ways to maintain a healthy relationship with your developer and benchmark their quality of service. In the next article in this series, we’ll continue to give tips for getting more in-depth information about your supplier.
In future articles, we’ll look at strategies for improving your PHP app, including implementing user feedback and tracking app usage.
And if You Need Help…
If you ever need any help or advice regarding your web development, PHP upgrades or ongoing support, please feel free to reach out and ask us for an opinion.
Who’s “us”? We’re Siftware, a firm run by me, Darren Beale. I’m a long-time PHP consultant turned manager and my team includes other respected PHP developers. Over the years, we’ve worked with a diverse client list, overseeing their PHP development and providing ongoing support.
Our service offering is laser focused and we only work with owners or managers of existing PHP applications. If you would like to find out how we can help you please don’t hesitate to book a free consultation.