Nice cheat sheet to get more web accessible: Monika Piotrowicz at a recent Toronto Accessibility and Inclusive Design meetup.
Category: Web Development
Sketchnote: Measuring Web Accessibility Conformance
Accessibility: Checklists and Team Work
How to guarantee the success of a project
I've just finished reading a thought-provoking article on ProjectTimes.com about scope definition and the heavy price of ignoring this critical phase of a project.
It brought to mind the old chestnut about stopping to smell the roses. It seems to me that stopping to smell the roses is more than a trite piece of advice on how to live a good life: stopping to smell the roses is a key factor in the success of a project.
Many of us, when confronted with a project that needs to get done, are anxious to complete the project and eager to get started. By the time many clients approach me, they've been debating and wringing their hands for some time. Thus, there's no time to lose, and we must start the project right away. However, when asked to define the problem and to describe the constraints under which the problem must be solved, many are unwilling to take the time to do so. After all, so much time has already passed between the time the client acknowledged the problem and conceded the budget to resolve it.
And yet this unwillingness to fully describe the problem is precisely the cause of project failure: the failure of a vendor partner to deliver the right solution, the failure of the project being completed on time and within budget. Whose FAULT is it?
Project failures are more often than not the result of irresponsibility on the part of both the client and the vendor partner. They are the result of failing to stop and think before an action is taken. They are the result of the mindset of "if you start building it, the right answer (i.e. the scope) will materialize or can be managed".
Once a project starts, it becomes a stressful juggling act for all involved: the client, the account manager, and the project manager. The account manager struggles to manage scope creep that erodes profit margin and client satisfaction. The project manager struggles to nail down a problem long enough for a solution to be built before new requirements are thrown into the pit to jeopardize budgets and timelines. The client struggles with a superior who cannot understand why the product they've paid money to get produced isn't meeting the company's needs and is now delayed, just to add insult to injury.
So why do so many agencies put themselves in such situations, why do we capitulate to poorly defined scope requirements when agencies are the ones who end up paying the price of failure? It's simple enough to say it's the fear of losing the project to a competitor; or to say that in business (and in life), nothing ventured is nothing gained. It's hard for me to accept this because a real alternative exists that practically guarantees project success and all-round happy project participants.
From a client's perspective, any vendor partner who leaps head first into a project without asking many detailed questions is a risk factor. Such vendor partners might be the lowest bidder at project initiation, but the math might not work out that way when the project fails.
Are methodologies scalable?
Requirements gathering is one of those steps in any project that can't be missed. Whether it's conducted vigorously and methodically, haphazardly and unconscious, it's done.
It doesn't matter whether you're ordering a hamburger at Harvey's or a web site build: the person taking your order needs to gather your requirements.
When you go to Harvey's, you don't just say you want a hamburger; the person taking your order will want to know if you want a classic or whatever, the person making your burger will want to know what kind of toppings you want. You could be remiss and say "just give me the toppings most people get"; not a problem, unless you really detest ketchup, which is what most people get on their burger.
Recently, I was discussing with a colleague the issue of requirements gathering methologies. In our experience, SMB's and micro-businesses, in particular, tend to work within very short temporal cycles. They can also have pretty short fuses and regard methodical questioning and any information probing to be, at best, extemporizing tactics and, at worst, unresponsiveness. How often have you been challenged with, "Why do you need to know so much? Why are you asking all these questions? I just want a ballpark, an estimate. I'm just a small business and don't have the time to be talking about this. I just need to get it done."
So we came to the tentative conclusion that enterprise-level business methologies don't necessarily scale down to the micro-business and even SMB (small to medium businesses) level. Is this really true? Do we need to develop a completely different style of requirements gathering for different classes of clients?
How much does it cost to build a web site?
This question is asked so often and by so many, there should be a Wikipedia entry for it. And it should be tagged as an "Existential Question," along with other questions of similar ilk: How long is a piece of string? How much does a car cost? How much does it cost to build a house?
You get the drift, I hope.
The fact is, the only way to truly capture and contain your web development cost is to quantify your project accurately by determining its business requirements. This is the most important phase of your project – a fact that most people fail to realize.
The implication of an incomplete scope definition goes right to the bottom line: project costs that spiral out of control, paying too much for features and functionalities that serve no business purpose, allocating inadequate funds to properly build a functional site, etc.
Caveat emptor: if a web firm blazes in with a cost estimate that doesn't include a scoping phase, RUN. How could they possibly provide realistic pricing for a project about which they know next to nothing?
Web development 101
If you're thinking about building a web site or making a change to your current site, this post's for you.
Please, please don't be tempted to start your project with pretty pictures and a snow storm of words. Unless your site consists of 3 pages of text and images that don't link to one another, please take the time to think about how the site should work before you fantasize about how it should look. Along the way, you'll be tempted: stay the course, don't fall off the wagon.
Let's get started.
What follows is a highly simplified overview of what's involved with developing a web site. Depending on how much content there is and what you wish to accomplish with the site, development could be a fairly straightforward task that you could undertake in part or completely; or it might be a beast that's best left to the professional.
Who is the web site for?
Sometimes we think we know, but more often than not, we say we do but really, we don't. Ask yourself the hard questions:
- why do you think you need a site?
- who are you building it for?
- what are these visitors' needs: are they all pretty web savvy or will they likely get confused by newfangled technology?
By not asking yourself these basic questions, you risk spending effort, time, money, and emotions on something that either isn't necessary or that you'll end up abandoning.
What's going on the site?
First, consider the content that's going to be on your site. How should it be organized? How you organize this content depends entirely on those who will want access to it. On the flip side of this, ask yourself if anyone would be interested in some of the content you're thinking of putting on your web site.
Updating the site: who, what, when, how?
Consider who will be updating the site's content: is it the marketing coordinator who doesn't know what html is or even stands for, or do you have a team of computer science grads who can code and program an entire web site from scratch? Which sections of the site will most often need updates? How often will these updates be available or required? how do you plan on getting this content updated (…a question that's related to the first one about who will do this work)?
OK, what's next?
Only when you have thought through these question is it even time to start worrying about how your web site should look. In fact, after you've worked through these questions, it's still not time to start getting excited about how your web site should look. The next thing you should be thinking about is how your web site should work.
Be nice to your site visitors
Ever been frustrated by a web experience? Ever felt like you have no idea where you are on the site? Ever felt confused by what exactly the site expects you to do in order for you to get to what you want? If you've ever felt any of these things, you've been the victim of poorly designed navigation and site flow. Don't be part of that crime ring: be good to your site visitors; after all, they made a decision to spend some hard-won time on your web site – the very least you could do is not tick them off.
Once you've done the leg work to working out a navigation scheme and how your visitor should go from one screen to the next, then and only then should you start thinking about how pretty (or not) your site should look.
Budget: time & cost
Some basic guidelines: If you had 100 hours to spend on your web development project, asking yourself and answering those questions I posed above should take about 25 hours. The next most important chunk of time should be devoted to designing the navigation and site flow: plan to spend another 25 hours working on this part. You're now in a position to start thinking about colours and fonts and other eye candy: spend 15 hours on this. Finally, remember: you don't have a site until you hand the work you've done over to the developers who will actually code the graphical user interface and program the working components of the site (e.g. just typing "click here" will not make it click: someone has to turn that switch on). Be good to yourself and your site visitors: make sure you allocate 35 hours to make all those great ideas actually come to life.
Garbage in…garbage out
Every project is different: some need more time with content and structure, others need more time on the programming end. It all depends on what the site's purpose is and who the visitors will be. Just be sure to remember that the way a site looks is the very last thing you do before the site is coded, rather the first. Think of it this way: if you were building a robot but spent most of your time working out how the robot will look first and only think about how it will work afterwards, you'll likely have a great looking bimbo.
