Following are some discovery questions I have found useful in getting a feel for what the client needs in a website. I found them in the book Web Redesign 2.0 by Kelly Goto and Emily Cotler

General Information
1.               What is the name of your company and your cur­rent (or intended) URL?
2.               Who are the primary contacts from your organi­zation, and who has final approval on the proj­ect?

3.               What is your intended launch date for the new site? Are there any outside considerations that might affect the schedule (for example, PR launch, tradeshow, annual report)?
4.               Do you have a specific budget range already established for this project? Can this project be divided into phases to accommodate budget and timing constraints?

Reasons for Redesign
1.               What are the main reasons you are redesigning your site (new business model, outdated site, expanded services, different audience)?

2.               What are your primary online business objec­tives with the site redesign? What are your sec­ondary objectives? (Examples include increased sales, marketing/branding awareness, and fewer customer service calls.)

3.               What is the main business problem you hope to solve with the site redesign? How will you meas­ure the success of the solution?
4.               What existing strategy (both on- and offline) is in place to meet the new business objectives?
5.               How important is it to maintain your current look and feel, logo, and branding?

Current Site

1.               Do you feel your current site promotes a favor­able user experience? Why or why not?
2.               What specific areas of your current site do you feel are successful? Why are they successful?
3.               What shortcomings exist with the current site, and what three things would you change on the site today if you could?
4.               Have you conducted usability tests or gathered visitor feedback for your current site? If so, how long ago?

Audience/Desired Action
1.               Describe a typical site visitor. How often are they online, and what do they generally use the web for? Give basic demographics: age, occupation, income level, purchasing habits. (Use as much detail as possible in profiling your target user. Profile more than one type if appropriate.)
2.               What is the primary “action” the site visitor should take when coming to your site (make a purchase, become a member, search for information)?
3.               What are the key reasons why the target audi­ence chooses your company’s products and/or services (cost, service, value)?

© Web ReDesign 2.0  | Workflow that Works (0-7357-1433-9)

So I’ve sweat and agonized over a proper estimate for my first client.  A redesign of a medium-sized non-corporate website. The estimate covers organization of content for ease of navigation, custom template design for homepage and inside pages, a blog, and an event calendar.  I also posed maintenance options: 1) keep the current content management system (Drupal); 2) replace Drupal with a hosted CMS, such as WaterCMS, 3) abandon CMS route and update by hand.

I took time for a thorough discovery of what the client like about the current site, what they wanted to change, and what they liked about other sites.

Two good things so far. The client has not, as of yet, not laughed in my face at my hourly rate.  Also, they have not as of yet expressed a desire for ebay-level functionality for less than $5000.

That said, I may well have to revise schedule to meet a reporting deadline for the client. This could mean that I put together the blog first, then build the template and organize the rest of the site content.  A little different, but doable.

I found several articles about how to set your hourly rate. Many involve elaborate calculations of current living expenses and potential business expenses. The following article at:

http://www.sitepoint.com/article/web-work-should-charge/

made things simple and fairly quick. Basically, you look up the yearly salary that most closely  fits the work you will be performing as a freelancer. They recommend dice.com or salary.com.  Divide the yearly salary by 52 weeks, then by 40 hours to get the hourly rate.

This makes sense to me as a shortcut to the tedious calculation of various and sundry living expenses, at least in my case.  I was already making a salary in the middle of the salary.com bell curve, a salary that was already enough to put food over my head and a roof on the table. What I needed to know was, how to set an hourly rate that would cover those additional business expenses? Legal fees? Additional taxes? Health insurance?  The article offers this shortcut:

Once you have an hourly rate for a salaried employee that does the work you are planning to do on a freelance basis, multiply that number by 1.5 if you plan to work out of your home; if you plan to rent office space, multiply by 2.

The result is a rate that covers both your living expenses and business expenses (“overhead”).  Now it’s time to build in profit so that you have something left after all expenses are paid.  Multiply by 1.15 for a 15% profit, 1.25 for a 25% profit.

So far, this method works for me, someone new to freelancing but with work experience as an employee.  Readers, how do you decide what an hour of your time is worth?

Recently I experienced an economy-induced transition from full-time employment.  How’s that for a fancy way to say, got laid off?  Coinciding with said layoff, I may have an opportunity for an independent web design project.  If indeed mine is the winning bid, what will follow over the next several weeks is a chronicle of the full system development life cycle of a project from planning through design, development, and launch.

From executivebrief.com comes a pithy interview with experienced Project Manager, Robert Bone: Managing Large Projects with Ease: 9 Pressure Reducers That Work!

The most interesting point, to me, was Bone’s first pressure reducer, Data Load Early in Migrations. Bone’s main thought here is that data load should not be saved to the end, but done either early in the project, or else in small batches throughout the project. Otherwise, several months have passed before a fatal flaw is discovered either in the database design or the legacy data.

I will agree that migration done early in the project can help meet deadlines and reduce or eliminate cost overruns, but how early? Surely the early load would be preceded by test data in order to find security holes. If data is compromised, let it be fake SSNs or CC#s.

While it can be helpful to break up data into smaller batches, I would try to get all data in one silo (e.g. all AP invoices, all admission applications) migrated over one weekend. Don’t let your users come in Monday morning to find that invoices 0001-2999 are in the new system, but 3000 – 30000 are in the old system. The fewer incremental changes your end users have to deal with, the less they will hate you later on.

Bone adds other pressure reducers that are solid common sense recommendations, boiling down to only working on what is required, and standing firm against unauthorized changes to what is required. I can hear the sighs from PMs of “In a perfect world…” and “If only…” but it’s true.

Bone also points out the team-oriented pressure reducers: Avoid resource bleeding, where you lose a developer’s time to anothe project, and reign in team members, or even whole teams, that isolate themselves from the larger group.  I have seen it many times, concurrent departments working on a similar solution, from an equipment checkout system to a course registration system.

In short, Bone goes over familiar territory for project managers in all disciplines, but I was left wanting a little more How To Do It to go with his What (Not) To Do.

Shared via AddThis