10 Tips for Keeping Momentum on Web Projects

Tricks for avoiding stagnation and block points on a web project.

There are many hidden perils lurking in the midst of a web project. So many little devils which conspire against you delivering on time. The nature of a project is that it is a unique undertaking, so unless you can see into the future, chances are there will be hiccups along the way.

If we know there is trouble on the horizon, then we can be prepared. The idea isn't just to have a plan ready for dealing with what maladies may befall your project, but also to use strategies to nip things in the bud before they become a problem.

To that end, I present 10 techniques I use to keep things moving along smoothly on a project. Some of these may seem counter-intuitive at first, so you will have to use your best judgment about what approaches you feel comfortable using.

Before I get into the meat of the article, I should say I'm not covering obvious things like 'use a project schedule' and 'write a spec' - if you aren't already doing that, then no amount of clever tricks will save you.

1. Get the ball rolling early on things involving third parties - a good example is live hosting, you can get seriously bogged down if you leave this until just prior to launch. If you don't have full control over the server it makes you heavily reliant on tech support to do things for you. Another example is e-commerce gateway integration. Do you really want to wait until the last minute to find out if your code is talking to the gateway provider's server properly?

2. Have settings accessible via the CMS - I've found it's preferable to have settings adjustable via the CMS rather than have them in code or in a string table. Options like Google Analytics script code could be placed inside a System Settings or Website Configuration page. Doing this lets non-technical people deal with last minute changes.

3. When there's two ways to code a simple feature, code them both rather than wait for approval - if the features each take only 15 minutes to implement, just code them both and enable one. You have a 50/50 chance of getting it right. If the client decides they'd rather have it the other way around, you switch on the alternate option (preferably via a setting in the CMS). The amount of effort you would expend going back and forth to get a concrete decision from the client is probably going to exceed the 15 minutes it would take to just code the alternate feature.

4. Put in the wrong content - this may sound counter-intuitive and you'd expect it to lead to an unhappy customer every time (but it doesn't, most of the time). This is only for preview/staging versions of the client's project, not their live site. If the client hasn't made content available to you, then use the closest match. Something off their old website perhaps, or workable place-holder text. This does one of two things; the client may say "hey, that's the wrong text", to which you reply "OK, can you give me the correct text please?", or it gets them started by providing a basis to work from (as opposed to starting from scratch).

5. Have a change request budget - this concept is straight out of PRINCE2 methodology. It basically says when you make a fee proposal/tender, include a chunk of budget for unexpected features. So for an eighty hour project, I would have between 5-10 hours of change request budget. The good thing about this is when the client asks for something off-spec, you don't have to wait for approval or try and convince them to pay for it (they already have). It can also help cut down on admin tasks since you don't have to track the item for inclusion in a future invoice.

6. Get clients thinking about what they hadn't thought about, early - a good example of this would be a social media strategy utilising Facebook (assuming it's appropriate for the business). A client may not have thought about Facebook, bringing it up early may have them saying "hey, I hadn't thought of that". That gives you time to provide them with some advice or reading material. Leaving it to the last minute may throw them off, they may even decide to delay launch to consider social media options.

7. Don't just offer options, offer a recommendation - if you talk to a client about a feature where there's two or more paths to choose from, first describe the available options, then the pros and cons for each, and finally make a recommendation on what's most suitable and why. This helps clients who are cautious of making a decision because they don't understand the technology at play. An example would be if a client asked whether its better to integrate a blog into their website or use a well-established one like Blogger.

8. Use a bug tracking system - scope creep can seriously side-track a project, potentially delaying the original launch date considerably. An issue management system lets you deal with off-spec features in a controlled way. If a client asks for a feature and you say no, that's just bad customer service. If you say yes to everything, you'll be coding forever. Instead, if you say "yes, but its been flagged for post launch implementation", you should be able to segment off features for future coding. Unfortunately this doesn't always work, sometimes clients are adamant that a feature needs to be included immediately.

9. Start early on tasks which require client approval - an example of this would be a storyboard for a Flash animation. The client may need a few days to review the document. Connected to this tip is starting early on things which only the client can do. A good example would be applying for an Internet merchant account. The bank will most likely only deal directly with the client due to security considerations.

10. Begin some work before the project deposit arrives - if you're fairly certain the project is going to proceed, do a couple of hours work even before the deposit has arrived. This would be stuff like preparing the project folder, checking that the domain delegation details the client has provided actually work, minor things (but no coding). This gives you a head-start on the project, its creating momentum from the get-go.



Keeping momentum on a project isn't just about following documented procedures. The role of creativity and a willingness to take risks shouldn't be underestimated. Novel solutions which produce results are either praised or go unnoticed, whilst failures may attract negative feedback. The trick is for your successes to significantly outweigh your failures.

Subscribe to RSS Feed.

Understanding Google Analytics Reports

A primer on interpreting the statistics inside analytics PDF reports.

This article will help you figure out what the statistics inside a Google Analytics report mean. This is not to be confused with the full service provided when logged into the Google Analytics website. From within the Analytics website, you can set it to automatically email you a periodic summary report (e.g. once a week). The report itself arrives in your inbox as a PDF attachment.

One last note before we move onto the interesting stuff; this article has been written to help non-technical people (e.g. an accountant who's just got their hands on their first website). So, if you are a computer science major, you may read parts of this article and think to yourself "that's not entirely true". And you would be correct, but I have intentionally made a few generalizations for the sake of brevity.

If we are going to talk about Analytics stats, we need to first ask ourselves "what's the point of all this data?" Sure, the figures can demonstrate that a ROI has been achieved (e.g. "was my money well spent, or should I have just gone down to the casino instead?"). But information without application is largely useless. The statistics should guide and shape the decisions you make in future (we'll cover some examples in a moment).

Absolute Unique Visitors
Arguably the most important figure is contained on page 2 of the report; Absolute Unique Visitors.

This stat is largely self explanatory; it's the number of people coming to your website. For most people it's the number which says whether their website is being successful or not. When a website first launches this figure may be quite low since people don't know about the site yet. Over time you'd expect this figure to increase, but don't be surprised if it plateaus eventually due to stagnant content and a lack of Search Engine Optimization (SEO).

Time on Site
Another stat worth keeping an eye on is Time on Site.

This is the average amount of time people are spending looking around your site before they decide to go off and do something more important like watch Big Brother or floss their teeth. For most websites a low figure (e.g. 10-20 seconds), means something is seriously wrong. A low Time on Site tells us people just aren't hanging around for some reason.

There are some instances where a low Time on Site is not necessarily a bad thing. Imagine a website with weather information, it doesn't take that long to check if it's going to rain or not.

Bounce Rate
Bounce Rate appears on page 2 of the report and is of vital significance.

From a visitor's perspective, Bounce Rate means: 'I came, I looked around, I left.'

So, a high Bounce Rate means most visitors came and left straight away. In almost all circumstances this is a bad thing (especially if you are selling goods online). It indicates people simply aren't finding what they thought they would at your website.

If you can't convince people to stick around, what hope do you have (even if you have bucket-loads of traffic)? This is why some would argue that this is the single most important metric to monitor, even above unique visitors.

Unfortunately you can't make everyone stay at your website (unless you're willing to stand behind them with a cattle prod). Simply put, if you don't have what they want, they will leave. If you can maintain a Bounce Rate of around 40%, that's good.

There are rare occasions when a high Bounce Rate isn't as damning as you may think. An example would be news aggregate site where there are headlines linking off to other websites.

You can go much deeper into how Bounce Rate metrics work, but that's beyond the scope of an introductory guide such as this one.

Top Traffic Sources
Top Traffic Sources can be found on page 3 of the Analytics report.

This shows you where your traffic is coming from, or another way to look at it is how people are getting to your website.

You'll see something called Direct Traffic or (direct) ((none)), this refers to people who actually type www.acme.com into the browser address bar (i.e. they didn't find you through Google).

The google.com (referral) stat shows people coming from Google sources other than their search engine (e.g. Google Groups).

It's not unusual for a large portion of your traffic to originate from Google. People are searching for a particular term and Google is presenting your site as the best possible match.

The organic part in google (organic) means 'not paid for'. You got that traffic from Google on the merit of having good useful content people want. Traffic stemming from an AdWords click wouldn't be counted as organic.

The reason why traffic sources is worth paying attention to is because it can show how successful promotional efforts have been.

Take the PM4Web blog (which you are reading at the moment). I spent hours searching the Stack Overflow forum for posts on topics I have written about. If someone was asking for recommendations on what project scheduling method they should use, I would give a few suggestions plus refer them back to my full blog article.

The next week my Analytics data showed a distinct surge in traffic originating from the Stack Overflow domain. This meant that the time I invested in promoting my blog had paid off.

Traffic sources are also significant if you are spending money advertising on another website. If you are paying $200 a week to be listed on a directory site specific to your industry and no traffic is coming from that source, then you know to stop wasting your money and invested it in commemorative stamps instead.

Keywords
The Keywords segment is located on page 3 of the Analytics report.

This basically says: 'what words did people type into Google to cause it to send them to me.'

How is this information useful? If lots of people are coming to your website because of a particular topic, then it would make sense to encourage additional traffic by providing more of the same kind of content (i.e. give people more of what they like).

This may also affect your writing style, especially with regard to Keyword Density. Say you had a page on your website where you talk about roof repairs. On this page you use the word 'restoration' 16 times, and the word 'repair' 4 times. If your Analytics showed that most people found your site using the word 'repair' (rather than 'restoration'), that would be a good reason to go back and change things around. The theory being you should see an increase in future traffic since the page is now keyword rich for the term 'repair'.

Country/Territory
Page 4 of the Analytics report contains data about which country people are visiting from.

For some people this information is largely irrelevant. To illustrate this point; imagine you repair motorcycles, chances are your target market is going to be mostly local.

For others, this information can be very significant. Take this blog for example; I'm in Melbourne, Australia, but most of my readers are in the United States (yes, I am riding a Kangaroo as I type this article). To accommodate my primary audience I use American spelling instead of UK English (e.g. 'summarize' instead of 'summarise'). In addition, I adapt the language I use. I would say 'cell phone' rather than 'mobile' ('mobile' is our term for a cellular phone).

This data can be valuable for people selling goods online. If your current policy is to only ship within your own region, but you find most your traffic is coming from overseas, that could be a trigger to seriously reconsider your shipping practices.

Top Content
On the report's last page there's a segment called Top Content. These are the pages most people looking at.

Analyzing this data is important for a number of reasons. If you've just spent a great deal of time or money on a page, you can verify if it was a worthwhile endeavor by checking if people are visiting it.

The other major reasons is this: if people like something in particular, why not give them more?

This data can be helpful when deciding how to direct future upgrade efforts. If you had a very basic gallery page on your website and found that it was becoming increasingly popular, these statistics could be enough to justify upgrading it to something fancier.

The 'who Cares' Figures
There's some areas of the Analytics report which are hard to get excited about. For most people, knowing what browsers people are visiting with or their broadband speed is of little value.

There are situations where this can be important. Say if you found most of your visitors were on a really slow connection (cavemen or the Amish). This may prompt you to re-compress all the JPEGs on your gallery page, bringing the average photo size down from 60KB to 35 KB. That would be of little consequence to broadband users, but a significant improvement in user experience for dial-up visitors.

I'm being a little flippant implying that the Analytics report contains 'useless figures', we all know Google does an excellent job with the services they provide, all the figures in the report are going to be useful to someone.

The bottom line is to let the data educate and guide you. Making informed decisions based on metrics is always going to yield better results then guess-work alone.

Subscribe to RSS Feed.

Basic Social Media Strategy - Part 1 (Twitter)

Developing a social media strategy to suit the needs of a specific business.

Due to the length of this guide it has been broken-up into two parts; part one focuses on Twitter, part 2 deals with Facebook.

The Internet is awash with tales of how Twitter and Facebook have helped businesses improve their bottom line. This is peculiar considering that neither of these tools was expressly designed for business use. Thanks to the ever-increasing push for innovative marketing techniques and down-right creativity by some boffins, these social networking mediums are slowly being commandeered by businesses. Far-fetched you say? Remember that the Internet first started as a military tool, than transitioned to an education tool, now it's largely about business, information-sharing, and self-expression.

What makes Twitter and Facebook so apt for business promotion? Is it the novelty, is it because of its low cost nature, or is it because it's 'trendy with the kids' (potentially prying open untapped markets)? Or, could it be because it's so well suited to guerrilla marketing tactics, what business doesn't like cheap advertising which gets too hard to reach customers? I'd say it's too early to begin speculating on why social media is gaining so much popularity with businesses (who knows, could it be just another fad?).

Whatever the reason for the meteoric rise of social media as a marketing mechanism, it can't be denied that people are increasingly asking "how do I put Facebook and Twitter on my website?" This brings us to the reason for this article; how do you develop a basic social media strategy tailored to the specific needs of a client? This guide is best suited to small businesses who are perhaps just launching their website, or are ready to get a bit more serious about marketing (but not serious about the expense of traditional marketing avenues; e.g. magazine ads, etc).

Like SEO, customers know about Facebook and Twitter, but don't necessarily understand how they work or how they can be utilized effectively for business purposes. They may have an appreciation for its importance, but don't really know where to begin. This is a good starting point, but it does require stepping back to provide context before delving into the intricacies of Twitter and Facebook.

It's important to point out early on in the exercise that a social media strategy has two major aspects to it. There is the work you will do as a technology supplier to develop the strategy (e.g. setup Twitter, etc); then there is the continual commitment the client will need to make to keep it all going. If a client is under the impression that Twitter and Facebook are 'fire and forget', they are sorely mistaken. Like puppies, Twitter and Facebook aren't just for Christmas. Clients need to be prepared to commit time every week to keep it fresh, and perhaps keep going for months before expecting to see some form of tangible return.

Now onto the actual pragmatics of the social media strategy. Because social media as a marketing tool is so new, I believe a face-to-face meeting with a presentation is warranted. I have developed a series of 11 PowerPoint slides. You can expect the meeting to go for one to two hours (depending on how often you stop to answer questions). One important factor of the slide-show is that it needs to be tailored each time to be specific to the business. If it was generic, it wouldn't be a consultative service. So it does take preparation before-hand to think about how Facebook and Twitter relate to your customer's particular business.

The entire slide series can be summarized as follows:

1. Introduction
2. The Basics: What is Twitter?
3. Let's Go Deeper: Twitter
4. Twitter for Business
5. Setting Up Twitter
6. Tips for Using Twitter
7. The Basics: What is Facebook?
8. Let's Go Deeper: Facebook
9. Facebook for Business
10. Setting Up Facebook
11. Tips for Using Facebook

Roughly half the presentation focuses on Twitter, the other half covers Facebook (nb. this is discussed in part 2 of this article). Some of the information in the slides may seem obvious and simplistic to you, but remember that the target audience is someone who knows little about social networking tools. The slides are meant to serve as triggers for discussion, rather than definitive sources of information. As you progress from one slide to the next, be prepared to stop as needed to discuss topics in more detail.

Introduction

The first slide sets the scene for things to come, outlining what will be discussed during the course of the presentation.

The Basics: What is Twitter?

This is a rudimentary introduction of what Twitter is. Some common Twitter terminology is also mentioned on this slide.

Let's Go Deeper: Twitter

This builds on the previous slide by mentioning more terminology associated with Twitter. The number of Twitter users world-wide is highlighted as a demonstration of the traction it has garnered amongst Internet users.

Twitter for Business

By this point the introductory portion of the presentation has concluded. You can begin to discuss Twitter's application as a business tool. It's important to draw some distinctions between Twitter and traditional forms of marketing.

Setting Up Twitter

Knowledge without application is largely useless; so this is where you list the actual work that needs to be carried out to make the social media strategy a reality. The name next to each task clearly shows who's meant to undertake the task (i.e. you or the client).

Tips for Using Twitter

The last slide puts forward some suggestions for getting the most out of Twitter.



One thing you may have noticed with the slides is they act as an information funnel. They begin quite general and narrow down to pin-point the actual application of the concepts in real-world terms (i.e. what work actually needs to be done to make it all happen).

Read part 2: Basic Social Media Strategy - Part 2 (Facebook).

Download the PowerPoint presentation.

Subscribe to RSS Feed.

SEO 101 - What to Tell Non-technical Clients

Explaining the absolute basics of SEO to non-technical clients

This article was born as a result of a question I'm often asked by clients. The question is usually along the lines of "how do I get my site to rank well on Google?" People generally know SEO is important, but they often don't understand how it relates to their own website.

A caveat before I go any further; I do take some creative license when explaining SEO. The liberties I take may cause a web developer to say "hey, that's not strictly accurate". Please keep in mind my explanations and examples are designed for lay people, not a lecture hall full of computing students.

Sometimes to answer a question you have to take a step back (in order to provide context). I believe this is the case when explaining SEO. Once a decent foundation is laid, the chances for an explanation to sink-in improve greatly.

So where do you begin when a client asks "how do I do SEO on my website?" As technology suppliers we often take for granted just how comfortable we have become with the web. Living in an online world can almost become second nature for some of us. This is the first key when explaining SEO to someone new to the topic - don't assume they're as comfortable with technology as you are.

The second rule may seem obvious, but it should be stated none-the-less; you don't want to be condescending when explaining SEO. There definitely is an art to teaching without making someone feel stupid. The specifics of this are beyond the scope of this article, but a good starting point is a book by Frank Luntz called Words that Work (it's about marketing and how successful communication is achieved).

A good place to start is by identifying the two major aspects of SEO: on-page and off-page SEO. Much of what happens with on-page SEO is controlled by the web developer. When a website is being created the idea is to code pages in a way which 'pleases' Google.

Google periodically comes along and spiders every website it can find (nb. sites generally have to be submitted to Google for indexing). Spidering is the process by which Google trawls through all the pages it can reach and catalogues them for searching purposes. The amount of time between spidering can vary from weeks (for a new website) to hours (for a popular website).

You won't be able to explain all the techniques available for achieving good on-page SEO, you would be there forever if you tried. Instead, you need to give a couple of examples. Examples are paramount when attempting to explain a topic that's completely new to a person. For instance, you could say page titles need to be unique and descriptive. If a website has details about a cell phone, a page title like 'Nokia N97 mini' would be better than 'Cell Phone Specs'.

This is a good point at which to make a distinction between what a developer does to achieve good on-page SEO and what a client needs to do. Arguably the most important concept to discuss is keyword richness. Again, this is best conveyed with a simple example. You could make-up a scenario about a website which sells hammers. In one version of the scenario the website's homepage has the following text: "our hammers are made with the finest materials. They are award winning and manufactured at our plant in Belgium". The other version of the text would read as follows: "our hammers are manufactured with the finest materials. Winner of the 2009 best hammer award and created at our factory in Belgium especially designed for producing the best hammers in the world". Notice how many more times the word 'hammer' is used in the second version. The name of the product (or service) being promoted should be mentioned on the website as often as possible - within reason. Be sure to warn of the dangers of keyword-stuffing. Going overboard with keywords could actually have a detrimental effect on search engine ranking (i.e. Google can actually detect when someone is over using keywords on a page).

If you wanted to recommend a simple on-page SEO strategy for increasing traffic, you could suggest providing 'value add' information. This would be information which may not be directly related to the client's business making money, but which would be helpful to their customers. For example, if the client sells bikes, they could provide maps of cycling tracks around the local area. Each time a person comes to the site for track information, there is the potential to show them products available for purchase.

To explain off-page SEO, you could start by saying it's about getting the word out there, getting known on the Internet. The more websites that talk about you, the more you move up in Google's ranking. Also, it's better to be name-dropped by a 'relevant' website than one that has nothing to do with your industry.

What do I mean by relevant? By way of comparison, imagine you have a bike store; if another bike shop refers to you, that carries more weight than say a furniture manufacturer referring to you. Google is aware of logical similarities, it 'knows' that tables and chairs have little to do with bikes.

Being name dropped by someone prominent and relevant is what's needed for good ranking. The trick is figuring out ways to get other related, preferably high-profile, websites to mention your website. Obviously, a direct competitor won't want to mention you on their website (that wouldn't make sense), but someone who would benefit from mentioning you would. For example, a tourism related website may be very interested in talking about you if you own a motel and are running a special offer.



In simple terms, it boils down to this: if everyone is talking about you on the web, than you must be the best source of information for your chosen area. If you are the 'go-to' person for your industry, Google will direct people to your website. After-all, Google only succeeds as a search engine if it's sending people to the right place.

Subscribe to RSS Feed.

Why Users Demand a Top-Notch Interface These Days

How UI and usability are changing the focus of software development.

Let's take a trip down memory lane. I knew years ago I wanted to be involved in UI design. Back at university I enjoyed making 'pretty interfaces', and for some reason had an inexplicable ability to retain information about design patterns. Sometimes my aptitude for UI design gave people the impression that it came easy to me, but like most people who've gotten good at something, there's a lot of hard work behind it all. The truth of the matter is that the skills had to be refined with long hours of research, reading, experimentation, and most importantly doing interface design.

By far, experience has been my biggest teacher. I've learned that it's 'not done until it's done'; if a UI design has to go though 14 revisions - so be it (and this has happened to me!). If something can be done with 2 clicks instead of 3, than that's my goal (than, I start thinking about how it can be done with just 1 click). I could tell years ago that companies would one day be scrambling for people with Interaction Design (IxD) skills. When software development began shifting away from desktop applications and towards web-based systems, it was clear a fundamental change was on its way (in terms of how we use computers). A number of other trends gave strength to this revolution, including; pervasive broadband uptake, mobile/wireless broadband becoming reasonably priced, and Apple consistently changing peoples' technology-use behavior.

One of the driving forces behind this fundamental shift was surely everyone getting access to low-cost 'always on' broadband. Without this, it simply could not have happened. If you've had the pleasure of reading Thomas Friedman's The World Is Flat, you'll see that the reason we ended up with pervasive broadband was partly due to the optic fiber 'fire sale' which took place after the dot com crash. In a nutshell; what happened was businesses invested heavily in expensive optic fiber cable. Then they went broke and were forced to sell their assets. Other companies came along and snapped up all this cheap cable at a bargain price (which in turn, they passed on the savings to customers).

Technology wasn't the only catalyst for change. Another big factor was the shift towards the Application Service Provider revenue model. Finally the industry had found a way to stop software piracy dead in its tracks (i.e. host the software online and get users to pay a subscription fee for access to the service).

Personally, I think that thanks to companies like Microsoft, Google, and Apple the average Internet user has become spoiled rotten in terms of the UI and user experience they expect. The bar has been set very high, but people don't appreciate that Google and others pour millions of dollars into their interface design efforts. People now expect this level of quality from all their Internet enabled software. This is probably a good thing since it forces companies to produce software the way it should be; designed for normal human beings, self-evident (i.e. no manual required), and suitable for a broad audience.

So why is it that Internet users demand such high standards from their online software today? I'd say it's because 'doing things online' has become a cultural norm, or even a borderline necessity. Gone are the days when paying bills online or booking airline tickets was something only nerds did. Would you not look at a colleague sideways if they said "I'm just popping down to the post office to pay a bill" (as opposed to paying it online)? The reality is people still are clinging to the old way of doing things (e.g. people still physically go down to the bank).

The next stage of 'doing things online' could coincide with the dissolution of the traditional outlets of commerce. For instance; there are ISPs now who expect you to sign-up online, and they only accept payment via automated electronic mechanisms (e.g. monthly direct debit). Is it so far-fetched to think that in the not too distant future we will be voting in elections via a website?

The media has also played a pivotal role in this transition. Notice how every poster at a bus stop these days has the Facebook and Twitter logo on it? Mainstream media's ability to shape social habits shouldn't be underestimated.



As more of the traditional physical outlets of commerce disappear in favor of their lower-cost online variants, it's as though the general public is being forced to do things online. If that really is the case, than the number of non-tech savvy users will skyrocket. This is what causes the demand for high quality interfaces, because large numbers of people who wouldn't normally do things online are beginning to convert. The companies that can deliver ease of use will no doubt prosper whilst those slow adapt will fall by the wayside.

Subscribe to RSS Feed.

Conducting a Tech Briefing Session

Reviewing the spec with programmers before they code.

A business analyst or project manager often gains a deep understanding of a client's business during the scoping phase. Probing questions during this process create a contextual back-drop for the project. Why is context so important? Because it makes you care, otherwise it's just another IT project. Having context mixed with experience and intuition results in the right questions being asked. If these questions aren't asked early on, trouble may ensue later down the track. For example, a paper-based task which the client takes for granted may in fact be a technical nightmare to implement (potentially jeopardizing the feasibility of the project).

Unfortunately, programmers often miss-out on this context. Developers are stuck in the office cutting code whilst analysts are out hobnobbing with clients. It would be unrealistic to expect programmers to attend all these client scoping meetings, if they did than who'd be back in the office doing the actual work? This is not even factoring in that documenting requirements is a particular skill-set, something a programmer may not have cultivated by this point or even be interested in.

The standard in most teams is to relay requirements to developers via specification documents. Whether that's a separate functional and technical spec, or just one document, in either case this document forms the basis by which a programmer turns concept into reality. But handing a spec to a programmer and saying "here, code this" isn't enough in my opinion. A spec often won't have context, sure, user cases help a lot, but they can often be limited, and a printed spec doesn't answer questions a programmer may have.

This is where a technical briefing comes in to fill the gap. The attendees would be the project manager, the business analyst, and any programmers who have been assigned tasks on the project. As to how much time will be needed, that depends on how big the spec is. What you are doing is going through the spec screen by screen, reviewing each interface in detail, discussing underlying functionality, stopping to answer questions, and providing contextual background which may be missing from the spec (e.g. what the client's business does, what systems they currently have in place, etc).

What's wrong with just giving programmers the specification and asking them to read it - you do trust your developers don't you? This is an important point; a briefing meeting may send the message that you lack faith in your technical team. The meeting does seem like a hand-holding exercise. Personally, I hate taking any action as a PM which diminishes a developer's chance for self-autonomy. But I hate failing at a project even more.

At the end of the day, if you hand a spec to a programmer and say "here, read this", they may very well read it. Or they may not. A programmer's primary focus is to cut code. They may be over-worked and under pressure themselves. Sending programmers in to code without arming them with context is like sending your troops to capture a machine gun bunker without weapons. They are part of the team, so why wouldn't you do everything in your power to set them up for success?

Another reason to undertake technical briefing sessions is because of the impact it will have on the type of bugs logged during the QA cycle. Without a tech briefing session, you will find a significant amount of bugs being logged for missed features (i.e. features in the spec which weren't coded). When enough 'missed feature' bugs are logged, you can start to deduce a pattern. A pattern that indicates that the programmer didn't absorb enough of the specification - they may have read it, but it just didn't sink in.

Once inside a tech briefing meeting, programmers can't escape; they have no choice but to sit there and absorb the business domain. A tech briefing done right will drastically reduce bugs which occur because of blank areas in a programmer's understanding of the system (anecdotal proof for this can be found during the project post-mortem bug analysis). The time alone spent on not having to fix these kinds of bugs makes up for the time the programmers spend in the meeting.

So is a technical briefing session just about not trusting programmers? No, it isn't. It's also about buy-in and caring. If programmers care about a client's business, they are more likely to do a good job. As I mentioned earlier, a BA or PM has had the benefit of many meetings with a client, a programmer hasn't. The tech briefing session gives you the opportunity to transfer some of this knowledge to the technical team. It's likely you will be able to condense this knowledge and feed it to programmers at a more concentrated level.

A typical agenda for a technical briefing would look something like this:

10.00am - 10.05am: greetings and hellos (Everyone)
10.05am - 10.20am: background on client's business (PM/BA)
10.20am - 11.20am: screen-by-screen review of wireframes (PM/BA)
11.20am - 11.45am: programmer Q&A session (Programmers)

The real magic happens during the screen-by-screen wireframe review. This is where you can inject a great deal of unseen detail. You can spend a few minutes talking about the rationale behind a particular screen. This could be a big deal because without it, a programmer could be looking at a complex wireframe and not even realize how critical it is to the operation of a business.

In terms of location and format for the meeting, ideally you would want to book the board room for a couple of hours, but if that's not available, any quite room away from computers will do. If you can get your hands on a projector to display the mock-ups for everyone to see, great. If not, big A3 color print-outs of the mock-ups will do. Should programmers be required to take notes during the meeting? I don't think so, leave it up to them to note down whatever they want. The main point is for them to listen rather than bury their heads in a notepad or laptop.



The sort of returns you can expect from conducting a tech briefing session aren't realised until the end of the project. The time you spend early on relaying context to developers will more than pay for itself later down the track. Programmers won't need to approach BAs or PMs as often to ask questions, they probably already asked the question during the Q&A segment of the briefing meeting. Fewer bugs related to missed features will be logged, and programmers are less likely to make bad assumptions about ambiguous features considering they have some understanding of the business rationale behind their work.

Subscribe to RSS Feed.

Writing Short, Easy to Read Fee Proposals (Part 1)

Creating fee proposals which are quick to write & easy to understand.

Due to the length of this article, it has been split into two separate but related parts. The first article provides the reasoning behind the proposal style. The second part describes the various sections of the proposal structure in more detail.

A while back I wrote an article called Writing Fee Proposals, since than I have learnt a few things which have led me to produce a new streamlined fee proposal structure (or tenders as many refer to them).

What prompted me to develop a better proposal structure? I had an experience last year where I lost out on a new contract. The client said I didn't get the job because my proposal was "too complicated". Up to that point I had thought being thorough and documenting everything in painful detail was a good thing - I guess not (at least not for everyone).

The biggest driving force behind the development of this new proposal structure was this thought: "people are busy, give them the facts and let them get on with their work". To achieve this goal, the proposal had to be short (generally 4-5 pages), it had to use the military principle B.L.U.F or Bottom Line Up Front (where facts are favored over 'fluff'), and it had to use language which would be universally understandable.

One of the major themes of the new proposal is setting up expectations. You've probably heard someone say "you have to manage customer expectations". Ideally, you want to lay down the ground rules for how a project is going to be run early on. What better point to do this than before the project has even started? I have seen projects in all sorts of trouble because it wasn't explained to a client early on that "this is how we run a technology project at our company". Trying to explain protocols once a project is underway is an uphill battle (not impossible, just harder than necessary).

I personally believe a proposal should tell a client exactly what they are getting for their buck. Seeing a line item like 'development cost' or 'consultancy service fee' is really no help to anyone. Having vague line items like these in a proposal just tells a client you aren't listening and don't recognize their specific business needs. Better line items would be 'development of shopping cart mechanism' and 'consultancy regarding off-page SEO strategy'.

One thing to keep in mind is that this structure is mainly suited to small to medium sized projects (e.g. 20 to 150 hours). I don't believe it is appropriate to use this format for bigger projects. You would risk under-pricing the project since you don't have enough detail to produce good estimates.

Let's take a brief look at the overall structure of the new proposal style (nb. part 2 of this article series goes into more detail about each section).

The First Page

• Big bold document title (e.g. Fee Proposal - ACME Website)
• Subtle note saying supplier & contractor details are in the appendix
• A single line describing what the document's purpose is
• A Cost Summary table (including the project's total budget)
• Change of Requirements block - this sets out important ground-rules
• Project engagement sign-off box - client's signature goes here

All this should fit on the first page, it's like a big executive summary.

Appendix

• Introduction
- Purpose of the Website - briefly state the project goals
- Client Background - demonstrate you were paying attention & care
- Technology to be Used - what language & database will be used
- Project Schedule (not the actual schedule, mention one will be used)
- Non-requirements (saying what isn't included in the project budget)
- Contractor & client details
- Project Team (brief history & qualifications of people doing the work)
• Costs
- Change of Requirements - affect of adding new features mid-project
- Budgeting for Additional Features - prepare client for extra costs
- Third Party Costs - (e.g. hosting fees aren't included in the budget)
- Payment Stages - when milestone payments will be triggered
• Terms - when invoices need to be paid, that a deposit is required
• Software Warranty - describing what happens when bugs are found
- Logging of Bugs - describing how bugs are to be reported
• Content Management System - CMS license details

The most radical change is that I shifted nearly everything into an appendix. If it wasn't absolutely critical for the client to know something straight away, than it got shifted to the appendix. What this meant was that the client could potentially read just the first page and approve the project from that (not advisable of course). From the client's point of view, the first page contains arguably the two most important pieces of information; what am I getting, and how much will it cost? From a technology supplier's point of view, the first page lays forth the most important rules for the project (e.g. how feature additions will be dealt with).

The reason why the majority of the document is in the appendix is because it's hard to say what's most important to a potential client after stating what the costs and deliverables are. Delivery date would be high on the list too, but you can't know that until you've done the project schedule. The appendix contains many sections which probably fall under the category of "who cares" as far as the client is concerned, but nearly everything in the appendix is a bureaucratic must.

With regard to the language used in the proposal, you have to remember that the client may not be that tech-savvy. This means you can't just drop words like 'SEO' without explaining them, you have to at least expand the term to 'Search Engine Optimization'. Being overly technical isn't the only pitfall to watch out for. The single biggest thing which will improve the overall readability of your document is to use short sentences (don't be stingy with your full stops). If you really want to improve your writing, I suggest you look into something called the Flesch Reading Ease Test and Flesch-Kincaid Grade Level Test. Microsoft Word has features built into it which support these metrics. You will have to Google this if you want a deeper explanation since it's beyond the scope of this article. Suffice it to say I use both these tests prior to posting any article to this blog.

After submitting a proposal, it's good practice to make a follow-up call (or arrange a follow-up meeting). Once sent, let at least a day pass so the client has a chance to read the document, than ring up to ask how they went with the proposal (e.g. "hi Bob, it's Tony. I'm just ringing to see how you went with the proposal, check if you had any questions I could help with"). This does a few things: 1) it keeps you at the forefront of the client's mind (a good thing if you are vying for a project amongst other competitors), 2) the client may have not understood things in your proposal (so you have a chance to clarify), and 3) the client may be very busy with their business, so they may not have time to call you - you are proactively pushing along the project. On larger projects, with more granular break-downs of project deliverables, its best to organize a meeting to go through the proposal and explain things step-by-step. That way the client will know exactly what they are getting for their money.



One last thought about clients and how they view proposals. Consider that people have different learning styles (e.g. some are more visual learners, others are auditory learners, etc), the same may be true for how clients relate to different styles of proposals. Certain styles will appeal to some but not others. One client may like a detailed break-down of exactly what they are getting, because they want to know exactly where every dollar is going. Other clients may not care about the fine details of the project; they just want to know what the grand total is. This phenomenon poses a tricky question; do you tailor proposals structures to suit individual client tastes? I haven't tried this out, but there may be merit to the idea if it means the difference between locking in a contract or losing it. Obviously there are some draw-backs, including: 1) it would be a time investment to maintain multiple proposal documents, and 2) how do you even know which structure is best suited to a client you haven't had much time with yet?

Read Writing Short, Easy to Read Fee Proposals (Part 2) for a detailed break-down of each section in the proposal.

Subscribe to RSS Feed.

Writing Short, Easy to Read Fee Proposals (Part 2)

Creating fee proposals which are quick to write & easy to understand.

Due to the length of this article, it has been split into two separate but related parts. The first article provides the reasoning behind the proposal style. This part describes the various sections of the proposal structure in more detail.

You may be wondering why I haven't taken down my old article Writing Fee Proposals. After all, if I think this format is better, why bother keeping the old one? I think it's important to remember where you came from, and the things which helped you get there. In addition, there is still relevant information in that article, and who knows, the older format may appeal more to some people.

Now it's time to delve deeper into the new structure, with some concrete examples to help get things moving. In big-picture terms, the document is broken down into two major sections: 1) the first page - this acts as a high level executive summary, and 2) the Appendix - everything else goes here.

Big bold document title

When someone picks up the document, they will know what it is immediately. I always start with the word 'Fee Proposal', but there's nothing wrong with calling it 'Tender' or 'Quote'. I follow with the company name and than what the system is (e.g. 'ACME Website', 'ACME Online Booking System', etc).

Say where supplier & contractor details are located

This is a single line saying that contractor and supplier details are located in the appendix. This information is often put on the front page but I don't believe its value justifies occupying such prime real-estate.

Document purpose

One line describing what the document is about. You can use a standard line like: 'Document purpose: to outline the work & costs involved in undertaking the ACME project'. This will be helpful to anyone picking up the document for the first time.

Cost Summary

Arguably the most important part of the document (at least from a client's perspective). This is where you present what you plan to deliver and what it will cost. At the bottom of the table, you have the project's total budget. The key here is brevity; you should be able to get things onto a single line most of the time. There will be times when it goes beyond one line, for instance; if you're listing specific web pages you intend to deliver (e.g. About Us, Products, etc.)

There are line items which are common to most web projects, these include: creation of wireframes, requirements gathering, integration & customization of the CMS, creation of a specification document, and quality control/testing.

You also need to capture tasks which aren't technology related, but which you spend time on anyway. For instance, people commonly forget to charge for the time it took to create the fee proposal, or the time it takes to generate and send-out invoices. This is time you are spending on the client's behalf, why shouldn't you be remunerated for it?

Some commonly missed items include: client communication (status updates, further requirements gathering, etc), setting up the live hosting environment, bug management and support.

Keep in mind that the person reading the document may not be tech-savvy. Explain things as much as possible, instead of saying 'PayPal integration', expand this to: 'Paypal integration (service used for taking & retrieving online payments).'

Change of Requirements

This section is very important from a supplier's point of view. It sets out the ground-rules for the development process. Scope-creep is known to be a massive project killer, that's why this is the ideal point to make it known to the client what happens if they change their mind. The two points to emphasize are; 1) additional features increase the budget, and 2) that adding features once the project is underway will push-back the delivery date.

I can't stress the importance of having this block on the first page, it is just good professional practice to make these vital points known to the client before the project begins. I also mention that the proposal only covers the cost of features described in this document, and nothing more.

Project Engagement Sign-off

The project engagement sign-off seals the deal between both parties. The head stake-holder from the client's side signs here, as do you. For large projects, it's very risky, and down-right unprofessional to not get this physically signed. For smaller projects, an email from the client is enough, something like this will suffice: "I'm happy with the costings in the fee proposal, please proceed with the project. - ACME"

This covers the contents of the first page. Everything else goes into the appendix.

Introduction

The appendix is split into a number of sub-headings. Begin with 2-3 bullet points describing the over-arching objectives of the project. This will go some way towards demonstrating that you've paid attention to the client's requirements.

The client background section demonstrates that you've been paying attention and care about the client's business. One paragraph will suffice, succinctly state what the business does, perhaps who their target audience is, what their market segment is, what service or product they are known for - that sort of thing.

Technology to be used

This is a good place to make a statement about what programming language you intend to employ. Also, you should mention what database system will be implemented. This information could be significant as there may be third party costs or performance issues the client needs to be aware of (e.g. MS SQL Server has to be hosted on a Windows server and costs more, MS Access only supports so many concurrent users, etc). If a CMS is being used, this is where you would say which one. You should also make a brief statement about what browsers will be supported.

Project Schedule (or production checklist)

Mention that a project schedule will be used to track tasks and resources. When smaller budgets are involved (e.g. 40 hours or less), I tend to use a production checklist instead. This is a checklist of tasks and a percentage marker to indicate the status of the task.

Non-requirements

A fee proposal says what a client will get for their money, but it's just as important to say what they aren't getting. This section goes a long way towards squashing assumptions before they become a problem. For instance; if you're building an online shop, you should say if international purchases won't be supported. Imagine if the client assumed they would be able to sell their goods world-wide, but you haven't coded it that way. All of a sudden you are in a situation where you could be pressured into undertaking a significant amount of unpaid work.

There is another situation where this section is of vital importance. It may happen that during scoping discussions the client brings up a feature they really have their heart set-on. For whatever reason, you decide it can't be done (perhaps for technical reasons, or maybe because of budget). This is a big danger. 3-4 months may pass, and the client may ask "hey, where's the user satellite tracking feature?", you reply "don't you remember, we discussed this and agreed it wouldn't be included?", client: "no". This could be a problem. You would be in a much safer position if you could say "the non-requirements section of the proposal says it's not included".

Contractor & client details

This section holds information about the client's business and contact details. Your information as a supplier goes in here too. There is a degree of personal taste at work here, it's not a big deal to do this differently or to leave it out entirely. I also sneak in some information about the date the proposal was created, and how long it will remain valid for.

Project Team

A short paragraph describing key members of the development team (e.g. a word or two about their qualifications). You could leave this out if you wanted, to a degree it's a matter of personal taste. I like to put this in for the sake of credibility, so your client at least knows they are getting a qualified person for this money, not some kind of code monkey.

Costs

This section doesn't need to be more than half a page. It does however cover some very important points which the client needs to be made aware of.

Change of Requirements - there was brief mention of this on the first page, but it's so important a topic that it bears repeating. Again, you need to spell it out that the fee proposal only covers items described in the proposal document, and that if new features are added, they will cost more and may push out the delivery date.

Budgeting for Additional Features - this is something which is often omitted. As developers we know that not everything will be thought of during the planning phase. Therefore it's important to tell the client to set aside money for unforeseen features they require. As a rule-of-thumb, I tell clients that they will need an additional 10% of the project's total budget in reserve.

Third Party Costs - this helps avoid any surprises. Let the client know in advance if they need to budget for things like hosting, or a SSL certificate.

Payment Stages - in this section you set-out the payment milestones for the project. My personal preference is to take a 20% deposit before the project begins in earnest, than a 70% payment when the project reaches 90% completion, and the final 10% upon sign-off.

Deciding how to set out your payment milestones is a topic in itself, one which is beyond the scope of this article (see Payment Structure on Small Projects if you'd like to learn more).

Terms

My terms and conditions section is relatively short, but this is likely to change on the next large project I do. This is in order to protect myself from clients that willfully disregard SDLC ground-rules established at the beginning of a project.

One of the important points I mention here is that the project won't begin until the start-up deposit is received. Other terms include: how much time a client has to pay an invoice once its sent, CMS licensing information, and 'development staging' of the website.

Development staging means that the site is up live and available for the client to review, but it's not easily accessible to the public (e.g. a place-holder index.html page takes precedence over the default.aspx page). A site is only launched (or taken out of staging) once final payment is made.

Software Warranty

In this section, I describe the warranty I provide with my work. Generally I commit to fixing bugs for free for a period of 6 months after launch. I know some people provide bug fixing for an indefinite period of time, and others that only do it for 3 months. You will have to find a time period that suits you. It is also very important to state just what a bug is, in your mind that may be very clear, but skip this definition at your own peril.

Logging of Bugs - I have a couple of lines stating that bugs need to be reported via a bug tracking mechanism. If you want any hope of getting clients to use your bug tracking software, you must discuss this early on in the project. Even then, it may be an uphill battle getting them to use it.

Content Management System

This section is optional, depending on whether you offer a CMS as part of the project. Nearly all of my private contracting work comes with a proprietary CMS I built called AURON. I have an example screenshot of the CMS in this section, along with a very basic description of what a CMS is. I also make note of the limitations of the CMS, mainly that it has no WYSIWYG editing capabilities.
___


A quick note about document style, you may have noticed from screenshots in this article that my word documents are very plain and unsexy - 'straight meat and potatoes' if you will. I have seen many fancy document templates at companies, branded with the company logo and lots of 'useful' information in the footer.

I understand the reasoning behind this, but I take a different path. The reason why I don't put logos, colored headings, footers with copyright notices, etc in my documents is to make it easier for new people to pick-up the document and run with it. When a person picks-up a foreign-looking document for the first time, they have to make an investment to get their head around it, decide what to ignore and what's of value. This may seem like heresy to a marketing or business person, and I doubt I would get broad support on this topic. I admit there is an element of personal taste/opinion at work here too.

There may be things about my proposal document structure which you don't like, and that's OK; just take the parts you like and adapt them to suit your needs and personal tastes. One strange thing I do is not bother including a table of contents ("sacrilege!" I hear you say), but hear me out. What need is there for a table of contents when a document is so short that you can just flick through it looking at bold headings to find what you want? What need is there for a table of contents now that we have Ctrl+F (i.e. the Windows search dialogue)?

Read part 1 for the background reasoning behind the new proposal structure.

Special thanks to Moin uz Zaman and Petras Surna for providing input and feedback during the development of the new proposal structure.

Subscribe to RSS Feed.