Part 2: Participating in the project
By Mark McGrath, March 2016.
Introduction
As the client and owner, you have ultimate responsibility for the outcomes of your web development project. Naturally, you want to get maximum value out of the money you are planning to spend on the project. Your participation in the project will be a significant determinant of the quality of the finished product. Therefore, it makes sense to learn how you can best carry out your responsibilities in this role.
This article aims to provide you with the necessary knowledge to successfully manage a website development project from the client-side. The article has been written to provide enough detail to be useful, without being exhaustive and too long. If you want more detail on any of the points made below, then please contact us or ask by posting a comment below.
Before the project
Fully understand the scope, budget and timeline
Before you start, it's important you fully understand the scope, budget and timeline of the project. Misunderstanding any of these aspects has the potential to cause significant disruption to the project later. Any issues regarding scope, budget or timeline are better dealt with before you commence rather than during the project. So make an effort to be crystal clear on what work is being delivered, for what cost and in what time. If you are in any doubt on any of these aspects, then consult your developer and ask for clarification in writing.
Decide what leeway you have with budget and timeline
It's quite likely that at some stage during your project you will be faced with at least one decision to extend the scope of the project (like adding a new feature to the website or further customising an existing service). This of course, will mean increasing your budget and timeline. This is normal so it makes sense to decide upfront, before you start the project, how much leeway you have in terms of budget and timeline. Doing this will make your decision-making on these issues easier and better informed.
Be aware of exclusions and variations
Whilst you need to understand what work is being delivered in your project, it's also important to clearly understand what work is not being delivered and how the work you are getting may change. These aspects of the project are commonly referred to as exclusions (what you are not getting) and variations (how work may change).
Exclusions
Make a point of fully understanding the exclusions. It's quite likely that your developer in the proposal has summarised the exclusions, so the onus is on you to ask for more detail to clarify what exactly is being excluded.
Some exclusions are distinct and obviously separate from the project scope. For example, e-Commerce functions when your new website will not run any e-Commerce services. In these cases, there is no need to seek clarification.
But where exclusions sit beside or are similar to a deliverable within the project scope, you should make the effort to clarify exactly where the boundary is that defines the limit of the project scope. For example, you may have content migration from your existing website to your new website included within your scope, but also have content migration listed as an exclusion. In that case, it would be important to establish the boundary between inclusion and exclusion. A typical outcome here would be limiting content migration to either a set number of pages or a set number of hours of effort by the developer.
Variations
It's almost inevitable that the scope of your project will change from what you signed-off on in accepting the developer's proposal. This is normal and to be expected as there are usually quite a few unknowns that need to be analysed, defined and decided upon during the scoping and specifications development phase of the project. So it's important to understand the protocols and procedures your developer will undertake when potential variations to project scope need to be decided upon.
When managing web development projects, I like to adopt the following approach to managing variations.
1. If any work requested may be outside of project scope then firstly stop work on the project and discuss the work in question with the client.
2. If the work requested is agreed to be outside of scope, then discuss options with the developer with the view to providing the following options:
- extra cost of work requested
- lower cost alternatives to the work requested (typically workarounds that involve some degree of compromise)
- no extra cost alternatives
3. Upon agreeing to a costed option, project work is re-commenced.
4. If the work requested (from 1.) is agreed to be within scope then project work is re-commenced.
Establish one point of authority on both sides of the project
No one likes dealing with a committee. It's inefficient and can compromise what you are trying to achieve.
Apart from a consultative phase, you should not expect your web developer to deal with a stakeholder group in managing the project. Similarly, you as the client should not have to deal with the developer's team. Instead, there should be one person on each side of the project (client and developer) who has the authority to make project decisions. It's the responsibility of both of these people to consult with their teams on any issues that may affect the outcomes of the project.
Each authority manages their own team
When a client puts a web development agency project manager in front of a stakeholder group to resolve issues, they are not doing their job and ceding their authority to people who may not be in the best position to make these decisions. If there are issues on the client-side that need to be resolved and you have a stakeholder group, then the client project manager should discuss this with the stakeholder group, with any necessary advice from the developer, come to a decision and then report this back to the developer.
Similarly, if you are asked by the developer's project manager to front their team to resolve some issues, then they are also not doing their job. It's the developer project manager's responsibility to resolve any issues the client may have by consulting their team and reporting back to the client. In these cases, I always try to come back to the client with options and pros and cons for each option.
Set and prioritise your website objectives
I've written on this before. Building websites is quite often about compromise. There is always going to be competing interests that cannot all be satisfied.
So decisions need to be made. Naturally you would want these decisions to be made in the best interests of the website and the organisation that owns it. But if you haven't got the right criteria for making these decisions then you are at risk of making bad ones. The right criteria here are objectives, in priority order.
Unless you are clear on the specific objectives you want to achieve with your website and their order of importance, then it will be difficult to decide on issues where different stakeholders or target audiences are competing for precious screen real estate.
If you don't make these decisions now, then the content issues you will be forced to resolve later will be a lot larger and harder to address. Once you get through this process though, resolving web content and design issues becomes much easier because these objectives act as a set of guiding principles.
These objectives should be specific, measurable and well defined in terms target audiences and website actions.
Taking the relatively small amount of time to define your site objectives in priority order is not that hard to do and will save you a lot of time and effort in the future.
Prepare content
Copying and pasting content from Word documents into your new website is a lazy, low-quality option. If you are sourcing your content that was used for printed material then it needs to be rewritten because people read web pages differently from printed material.
On the web, people don't read all of the content. Instead, they scan the page for what they might be interested in and then read that content before jumping to the next point of interest.
To make it easy for people to read your web pages in this way, you need to write for scannability. This means:
- Employing lists wherever possible.
- Inserting subheadings to act as summaries of the paragraphs they cover.
- Highlighting a small number of keywords in each paragraph (to provide another way for readers to quickly detect the meaning of your content).
- Explaining one idea per paragraph.
- Adopting a summary first, detail second approach (the inverted pyramid approach) at all levels of your article (paragraphs, sections, whole page).
- Reducing your text volume to 50% of the print version.
Doing this for all the content you intend to publish is not easy. But the cost of not doing it will be greater in terms of loss of:
- Online readership.
- Service delivery take-up.
- Reputation.
If you are going to spend valuable time and money on building a new website, then you should also invest the extra time in developing content that will be read by your users. Otherwise, you are wasting your time and money.
Assemble a publishing team
If you are a small organisation then you can probably get away with publishing and managing the web content all by yourself. But if your organisation is any larger than this then you will probably not have the capacity to write, edit, publish and maintain all web content on your own, so will need help.
The best way to organise this help is to assemble a publishing team. The key organising principle here is to have a tiered hierarchy of publishing responsibilities with one person who has overall responsibility for published content at the top and layers of more team members with more targeted or restricted content responsibility below.
Below is an example of a publishing team organised in this way.
| Role | Responsibility | Number of team members |
|---|---|---|
| Administrator |
| 1 |
| Editor |
| 2 |
| Publisher |
| 6 |
The breadth and depth of this team would need to change according to the size of your organisation and the volume of content you need to publish.
Adopting this publishing team approach means you will need two things to make this work efficiently:
- Workflow management system.
- Content publishing policy.
Workflow management system
This can be easily implemented by your developer as most CMS's nowadays can be configured "out of the box" to assign permissions to a role and trigger email notifications upon content being published. For example, content publishers only being allowed to publish a specific range of content in draft (not publicly accessible) mode and upon publishing content, an email to their content editor, notifying them about the submitted content being sent.
A content publishing policy is best developed during your project, so see below for an explanation on this.
During the project
Recognise that the project scope may change upon finalising the specifications
It's not financially viable for developers to fully scope and specify a web project before supplying a costed proposal. This is something that needs to be done as part of the project. Given that you will not know what the final scope and specifications are before the project commences, you should recognise that these may change upon finalising them. As a consequence, you should also be prepared for the budget and/or timeline to also possibly change.
Know the implications about each decision
Although your developer should inform you about the implications of each decision you make during the project, you should make it your business to know the full implications of each decision; before you make before you make the decision. Not knowing the implications of each decision can put at risk the quality of work delivered and project cost.
A common example of this is a client signing off on a set of wireframe diagrams and a sitemap for the project, then during the site build phase of the project, wishing to change the layout and functionality of landing pages for major content areas of the site, not realising that these changes are subject to extra costs as signing-off on these documents meant this was what was agreed to be built, for the accepted budget.
So each time your developer asks you to make a decision on the project, first confirm with them what are the implications of the decision you are about to make. The implications you should be looking for here are those around:
- Budget: will this mean any extra costs?
- Scope: will this change or compromise in any way the functionality or look of the website or will it limit my future options in some way?
- Timeline: will this impact on the timeline of the project.
Explore all options before making project decisions
A natural extension of knowing the implications of each decision, is to explore all options before making a decision.
Your developer should provide you with options for each major project decision, pros and cons for each option and a recommendation for which option to choose. But if they don't provide this, then make sure to ask them what are your options here with pros and cons for each option.
Building websites is often about compromise between the constraints of clients needs, audience needs and budget. So your developer should be well versed in the trade-offs for many of the issues that are common to web development projects.
A typical scenario is a client wanting a rich-featured, customised web service (like a multi-step product finder, coupled with an e-commerce service integrated into the client's CRM) but not being able to afford it. In these cases, there are often alternative options which provide almost as much functionality (like an e-commerce enabled, searchable, browsable product catalogue that isn't integrated into the client CRM) but at a more affordable price.
Treat the project as a learning opportunity
Even if you've managed web development projects before, you should treat the project as a learning opportunity. If you have a good web developer and are pro-active in the decision-making, you can learn a lot about best practice in designing, publishing and marketing websites.
The key here is to be an active participant in the project, asking the developer for the rationale on each of their recommendations. Issues such as homepage composition, sitewide navigation, information architecture (how you structure your content) and content authoring can all be informed by well established, best-practice conventions. So it's worth asking your developer about these.
Accept professional advice unless you've got sound reasons not to
As the owner of the project and the ultimate authority on project decisions, it's tempting for clients to indulge their personal preferences on web features and make project decisions that go against expert advice. Unless you are a web expert, and I'll be honest here, most clients aren't, then you should carefully consider the advice that's given to you during the project.
If your developer has demonstrable expertise and a well-argued case for a recommendation, that also addresses your particular issues, then I would accept their advice, unless there are compelling reasons that prohibit you from doing so.
Keep track of project progress
I believe in being flexible on the way you do this, as clients are all different and have varying preferences on the way they like to manage projects.
There are two broad approaches you can take here:
1. Request regular (eg weekly) project updates.
2. Request updates an incident basis (eg only when an issue arises, scope, budget or timeline may change, or when a milestone is reached).
Whichever approach you take though, you should have access to a project management system provided by the developer (such as Basecamp) that allows you to access project documents, view work in progress and discuss any of this.
Promptly respond to decision requests to avoid dragging the timeline
If you want to finish your project by the timeline's forecast completion date, then the best thing you can do as a client is to respond promptly to decision requests and hit the ball back over the net, when it's in your court, as soon as you can. When I'm timelining a project, about as much time is allocated to client review of work as it is for the actual work in designing and building the site. So if you can respond to requests quickly and clearly then potentially you can get ahead of the timeline.
You only need one issue on the critical path of the project where the client drags the chain on a review or sign-off decision to fall behind the timeline.
I'm not advocating rushing decisions though just for the sake of meeting or beating the timeline. You should take as much time as you need. But what you shouldn't do is sit on requests and respond to them later instead of sooner.
Avoid back-tracking on sign-off decisions
What can really kill the budget and timeline of a project is a client changing their mind on aspects of the scope after they have signed-off on documents that define this scope and worse still, after work, based on this scope has commenced.
Unfortunately, some clients are under the impression that because web work is virtual, it's easily changeable, so therefore changing the scope is no big deal. But changing the scope of the project can be a big deal as it can mean a significant amount of rework and new work to accommodate the changes.
In these scenarios, I like to use the (housing) construction industry as an analogy. If you were getting a house built you wouldn't expect to be able to move the bathroom to another location, after signing-off on the plans and commencing the build, without significant extra costs would you? The same applies to web development projects. Anything built or in the process of being built to plan that is then changed will mean extra technical work and therefore extra cost to cover the time of this effort.
So to avoid this I recommend that clients fully understand the project scope and how it relates to the budget and also carefully review all specification documents that they are asked to sign-off on. If you are not sure of anything, then ask your developer for clarification.
Develop a content publishing policy
This is probably best done in collaboration with your developer as they will be able to provide some expert input on the make-up of the policy. The CMS will also probably need to be configured to accommodate this policy. So this work should be undertaken during the project.
Good looking, professional content on a website is underpinned by uniformly applied, best-practice techniques in content publishing. The way to achieve this is to develop and implement a content publishing policy that governs the way text is structured and styled, images rendered and laid out. This is achieved in two ways:
- Configuring the CMS publishing templates and stylesheet (CSS) to automatically style content in the way your design concepts intended.
- Adopting publishing practices that will ensure consistent display of content such as:
- Always using the style options drawn from the stylesheet (such as heading levels or quotes) that are provided in the WYSIWYG toolbar of your content entry forms.
- Never "free-styling text" where you make up your own styles and ignore the stylesheet classes. I think it's even worthwhile switching these options off so they can never be used.
- Using dedicated image fields as much as possible (so that the image publishing policy can be maintained)
- Only using the WYSIWYG toolbar image publishing option when it's absolutely necessary.
If the style options within your content entry form toolbar don't meet all of your needs then talk to your developer about getting this changed. It's relatively easy to create new stylesheet classes and make them accessible via a toolbar.
After the project
Review the project
In the euphoria of launching and promoting a new website, it's easy to forget about how you got there.
Taking some time to review the web project with your developer, whilst it's still fresh in your mind, can allow you to learn some valuable lessons that can be put to good use the next time you embark on a web development project.
No web development project is perfect. Same goes for developers and clients. So if you both sit down and have an honest appraisal of what worked, what didn't and how things could be improved, then you'll be in a much better position to improve your project performance next time.
Address issues for next time
Out of the review you will probably identify some issues that could have been done better. If you address these issues now, whilst they're still fresh in your mind, rather than leave them for later, then you are more likely to avoid these issues recurring.
Plan for the next stage of development
Successful websites don't stand still. They're continually evaluated, redeveloped, tested and refined to improve their performance and meet the changing needs of their audiences. If you recognise this then the sensible approach is to plan for this work to be done, so it can be done properly with adequate time and resources.
A typical website development plan would contain a timeline of the following actions:
- Implementing measures that can collect website performance data for future evaluation, such as:
- Setting benchmarks (such as traffic growth or user satisfaction levels) that can be used to judge the success of the website.
- Google Analytics
- User website satisfaction survey (within your website)
- Evaluating website performance after a set period of time (say 12 months) against your benchmarks.
- Using the findings of the website performance evaluation to guide your next stage of development.
- Conducting usability testing on your new development with members of your target audience.
- Refining your new development, based on the findings of the usability testing.
- Timelining the next stage of evaluation, development and testing.
Conclusion
As the client and owner of the web development project, you have a responsibility to be an active participant throughout the lifecycle of the project, being across the detail and not relying on the developer to make key decisions for you.
If you put the work into:
- Preparing early for your web development project.
- Diligently carrying out your responsibilities to carefully review work and make informed decisions during the project .
- Addressing identified issues after the project .
- Planning for evaluating and further developing the website.
Then you will gain a better, finished product and be in a good position to improve your website with the next round of development.
But not doing these things puts at risk the quality of your new website and the valuable resources you've invested to achieve this.
Mark McGrath is a Web Consultant and Director of Social Change Media.
Add new comment