In part one of this article we acknowledged that there are certain parts of a website development job that are always underestimated. Always. Even when the project plan and budget details have been written and analysed in the minutest detail.
We talked about running into the same problems when developing our own website that we see when we help clients build their websites. We discussed the creation of great content, the development of robust business processes, and staff availability as particularly relevant problems.
There are some others that we come across often in our projects...
Acceptance Testing
There are many kinds of testing, ranging from usability testing to functional testing and market testing. Most of the testing in a web project is performed or closely managed by the development agency. But the project owner's involvement in the acceptance testing phase of a website development project is usually given less attention than it needs. Sure, you should expect that the project has been fully tested by the development team before it's given to you to sign off. However that's never going to be enough to get it over the line.
User acceptance testing is often referred to as UAT. We love our TLA's in the tech industry!
The thing is, acceptance testing - the testing that should take place by or on behalf of the customer to make sure the project meets the necessary expectations to be accepted for launch - takes more time than most people expect (experienced agencies included). It's important to recognise that issues will arise out of running a proper test plan that need to be addressed by the development team, and that takes time too. The simplest of all web projects still needs a week or two between the time it's presented to the project owner for commercial acceptance, and the day it goes live.
- Follow a written test plan. Your web developer or agency project manager should be able to give you some guidelines or a starting point for this plan, but you should review and extend the plan yourself. It's important to try to understand the full scope of the project that is being delivered to you, and to verify that it works according to your expectations.
- Write down the results of every test case in your test plan. It's just as important to note a successful test as a failed one, or to write notes and questions down for later reference even when a test is successful.
- You will almost certainly need to test your project more than once before it can be launched. It's not uncommon for a web project to go through two or three rounds of testing and re-testing before launch day. It's typical for each round of testing to take between hours and days, and then to wait for days or more for the development team to properly address the issues raised.
- Be open minded about how to address the issues raised when testing. Prioritise the problems that are found, and be flexible about resolving them. It's likely that problems fall into four broad categories:
- Must be resolved before the project is launched
- High priority to be resolved shortly after the project is launched
- Should be resolved during your project warranty or support period
- Does not need to be resolved or can be resolved adequately with a workaround or adjustment in expectations or workflow process
I've seen the tiniest of technical problems (which ultimately wouldn't even have been noticed by customers of a website) hold up a project launch by weeks, and cause unhappiness among all the stakeholders in an otherwise highly successful project. This kind of thing usually happens when the job of testing is underestimated by the customer, and at the same time the agency or developer fails to take the lead in managing the client's expectations about how testing works.
Post-launch Testing
Another important thing to note is that a formal round of testing should be performed both by the development team and by the project owner after the project has launched. We call this a launch test at DDSN.
The launch test plan isn't usually as detailed as acceptance testing plans, since it's not necessary to test programming functions that couldn't possible have changed as part of launching the website. However the launch test plan does include some additional components that weren't relevant before the project launched - such as making sure the website analytics tracking code is working, the site is appearing in search engines as expected, the site performs as expected after being moved to the production server, and so on. It's also critical to reconfirm that all the transactional functions of the site (such as forms, emails, and database interactions) work as expected, even if they were verified prior to launch.
Project Management Overhead
Perhaps the most widely kept little secret of the web development industry is that agencies almost always spend more time managing a project than what they charge for. I don't mind admitting this, partly because I think it's not really a secret, it's common knowledge, but mostly because any agency worth hiring will deliver what was promised no matter how much they need to personally invest in the project. However risks come into focus if the level of management required is not properly communicated to or understood by the project owner (the client).
It's usual for the management effort from a client's side of the project to be equal to or in excess of the management effort of the development team. The development of a great website is in all cases the result of a close working partnership between developer/agency and client, so if the level of input by the project owner isn't well understood from the outset it can be tough to get the project done.
The only real way to address this problem is to allow for more project management time that you think is necessary. Regular meetings between client and agency project leaders will certainly help - e.g. every fortnight or even weekly in most projects, either face to face or via a telephone hook-up. Although the staff resources spent in these meetings might look excessive on paper, nobody likes coming to a meeting without progress to report. So things get done.
Once again, a good web designer or agency should be able to provide leadership and support in this area. We find that up to half our management time in any project is spent just in helping the client's project champion keep up with the things they need to do. It can be easy for a developer or agency to forget that things that are second nature to us because we do them every day simply aren't obvious to our clients.
We ran into a slightly different version of this problem when we re-designed our own website. In some respects, it was under-managed. We thought we could cut some project management corners because, well, we know how it all works! But no, we found out the hard way that the client had to put in just as much effort in our own project as in other cases.
Wait a Minute! What About Scope Creep?
Just about every article that's ever been written about the dangers of managing technology projects addresses the issue of "scope creep". That's a term we use in the development industry to describe the way requirements tend to expand incrementally as a project progresses and more is understood about it, and how this causes pain for both the development team and the project owner.
I'm the first to acknowledge that creeping scope is a real problem that requires dedicated attention. However, in my experience it's rarely one of the more underestimated problems in a project these days. Capable web designers and agencies are all fairly good at defining an accurate scope for a project, allowing leeway for change, and communicating with project stakeholders about scoping issues along the way. Clients are generally aware of the problem too, and happy to have their expectations managed closely.
Of course, your mileage may vary on this topic, and I'd be happy to hear your feedback if so.
Addressing the Pitfalls
There are a million ways to mess up a project as complex as developing a website. (Did you realise that the smallest of websites probably contains tens of millions of lines of code, and there could be errors on any one of those lines?) Talking about the most commonly underestimated components of a project as I have done here only scratches the surface.
There are some generally good practises that come to mind when thinking about the project pitfalls outlined in this article. By no means do the following comments offer a comprehensive view of how to manage a project - that's a whole science on its own - but they might help to address the specific issues I've outlined in this modest article.
- Allow plenty of slack time. If your project plan says you're going to launch on the first of the month, change it to say the tenth, tell your project stakeholders the twentieth, and let your customers know it'll be next month. I don't mean you should compromise your project plan to allow being late. I mean you should incorporate leeway into your project plan, and wherever possible under promise to your external stakeholders.
- Make sure there is a clearly identified and well understood set of procedures behind the operation of every function in your website. Try to identify these procedures early in your project.
- Develop a detailed prototype of your project. I know "prototype" is jargon that I haven't explained in this article, you can read more about prototypes in this article. In the meantime, keep in mind that among the many benefits of a good prototype, it allows you to start testing your project early in the process, even before graphic design has finished and code is written.
- Make sure you have the right experts available at the right points in the project. Understand that several people within your organisation will be required to assist in the development of the site.
- Take stock of the project often. Continually re-assess what's been done, what's to be done next, and what's left to be done after that. In doing this, you'll find that otherwise invisible issues that could cause major problems down the track are put on the agenda early, and often dealt with before they cause headaches.
So... That's 5 Ways to Underestimate a Project
In my experience, the problems discussed in this article are the most commonly underestimated elements of a website development project. They're certainly the ones we bumped into when re-designing the DDSN website.
- Writing and designing content
- The business and processes behind the website
- Staff availability
- Testing
- Project management overhead
But perhaps those are just the most common problems in our projects. What did I miss? Have you had a different experience? How do you think underestimation can be avoided?