In the previous post we explored how to define requirements for your website.
Once the ink on the contract dries, the parties often change their priorities. Your job is to make sure everybody stay enthusiastic about the project and target the same business objectives that were initially outlined in writing and agreed upon.
Even though detailed planning lays the foundation for success, there will be minor course corrections and scope adjustments. Are you ready to constantly manage change yet stay within timeframe and budget? This will definitely require day-to-day involvement with the development team.
Some subcontractors will tell you that you can take vacation while they are building your website. This approach almost guarantees that you will not get what you want the first time it is delivered.
Instead, pull out the specs, ask for specific plans against it for the few weeks to come, define deliverables together, and agree on transparent and continuous development process.
If you can’t verify the technical parts, such as database design, ask your CTO to join the conversation. You will be surprised with the differences in interpretation of the same specification document by various people.
Once you know that development is underway and can track its progress against the scope and timeline, ask your subcontractors for regular demos of the developed parts. They should be live and working, at least with a limited set of features.
At this point it is smart to show the results to actual users who will be frequent visitors to the website, both back- and front-end. Is administration interface intuitive or at least well documented? Can potential customers quickly grasp your value proposition and navigate to the needed content easily?
As you start diving into details of your design and functionality, it might turn out that they do not achieve the original goals as efficiently as you expected. It is vital to identify this early as every day will make it more difficult to correct.
It does not necessarily mean changes in the scope. For example, if you want to tweak homepage layout to enhance presentation, it might be possible to adjust straight from the admin area, without any additional coding.
Just check that technology and business go hand in hand at all times.
So how exactly do you stay in touch with your developers?
First of all, you want to have access to status at any moment. Ask for a web-based account in their task tracker with enough permissions to see the time spent on each task. Some custom view with the big picture of your project (total percent complete, outstanding issues) will also help. You might also want to use such system to clarify requirements, upload necessary materials, and even participate in planning.
Other traditional means of communication include email, Skype, mobile. Schedule at least weekly meeting online or in person to discuss what has been done, is in the pipeline for the next period, or could be an obstacle to smooth delivery.
In spite of real time access to the state of affairs, ask for official reports as well, they should be an integral part of the agreement. This will motivate developer house executives to supervise website delivery closely and focus on specific milestones.
Do you know that one third of all web projects fail, miss the launch date or exceed the budget? I’m sure no one told you this at the first meeting, so keep an eye on your team to avoid the frustration.
You own the software produced (did you include this point into the contract?), so get access to the code repository and make regular backups. Watch for daily export of the work done, this way developers cannot fake the progress. Ask your CTO to look at the code according to below guidelines.
Everything we spoke about above refers to functional requirements, or how your website will look and operate. However, it’s only the tip of the iceberg, while the rest lies under the trouble programming waters and is not visible to common non-IT mortals. So why should we care about it?
Non-functional quality requirements influence
- Reliability (stable and uninterrupted availability)
- Scalability (ability to handle large arrays of data)
- Performance (page load time, ability to handle high traffic)
- Robustness (ability to handle stress)
- Maintainability (effort and expense needed for technical support)
- Extensibility (ability to add new features)
- Security (protected data and access to the system)
of your system, and eventually its ROI. I hope I got your attention now.
Most of the quality issues will probably be covered by the underlying content management platform, as discussed in part 2 of this blog post series. But the actual templates and extensions produced to implement your website should also comply with strict QA rules. Ask developers to show their coding standards and make sure they follow them fanatically.
You should not just take the word of developers who say they have done everything “properly”. Every testing procedure has a clear measurable outcome that should be presented as a written report.
Functional testing comes first. Somebody needs to meticulously click through all the pages, buttons, and forms. Then, make sure graphical user interface replicates original design precisely, has optimized kilobyte size, viewed identically in all major OS/browser/version combinations, etc. Again, developers should know all the nuts and bolts about it.
Performance testing is twofold. One part is easy – server response time should be under 1 second, and page load time under several seconds depending on your interface style. The other is more complicated and involves speciality software to put the system under stress with simultaneous requests, high load, and unexpected user behavior.
This is especially important if your system is mission-critical.
You can now control the flow of your project and maybe even surprise your partners with deep knowledge of quality control techniques! But how do you accept and integrate your brand new system into your organization workflows and IT infrastructure? This will be the topic of our next post.
Part 1: Start a web project
Part 2: Select your CMS
Part 3: Select subcontractors
Part 4: Define requirements
Part 6: Deploy the system
Subscribe to our feed to get the rest of the series
This work is licensed under a Attribution-ShareAlike 3.0 Unported License