Redbone

Business
The Beginner's Guide to Web Projects
By Dan Horne

Psst... Want to buy a Website? 

Whenever you need to engage the services of outside experts there are always concerns. I hate taking my car to a mechanic. Can I trust the diagnosis? Am I going to be charged for services I don't need? You may be having the same concerns about your web project.

This article is designed to alleviate some of these fears. It's not aimed at brochure sites as these simply advertise your products or services. Rather, it is intended for those of you who may find yourselves looking to implement a site with an element of complexity, but who have little experience in this area. We point out what to watch out for, and how to keep on top of your project so that you experience the sweet feeling of success when it goes live.

Before the Project Begins

Do You Know What You Want?

Before you consider professional web services, you need to know what you're after. Sometimes it's possible to specify your requirements in great detail. At other times, you may have a general idea of what you need, but would like some assistance in clarifying your thoughts.

Regardless, you need to have at least a broad vision of what you want. Although it's less likely to occur now that the Internet hype has died down, there is a history of companies embarking on web projects because they felt that they needed to, and not because of specific business drivers. This can end up being very expensive.

You should write down your requirements. This helps to clarify the details in your own mind, and also reduces ambiguities.

Choosing a Supplier

Once you've decided to go ahead, ask your friends and colleagues for supplier recommendations. Generally, if they're happy, there's a greater chance that you'll benefit from the supplier's services too. However, don't just rely on recommendations unless you know the sites the supplier has written for your friends are exactly the kind you want.

With a simple web site, say a company brochure advertising your products or services, what you see is what you get. So it's easy to judge a supplier by their past record of brochure sites.

If you require something a little more sophisticated - say an e-commerce site - it is probably worthwhile evaluating a number of suppliers.

The suppliers should provide a detailed breakdown of their estimates. This means that you are less likely to get a guess rather than a carefully considered response to your requirements. If your requirements haven't been fully formulated, the suppliers may be wary of providing you a fixed cost for the project. If someone is willing to nail down your expenses in such a case, then you should treat the offer with suspicion. It would be like a mechanic telling you the cost of fixing your car before the problem has been diagnosed.

It's hard to overstress the importance of a detailed breakdown. Firstly, you get a better idea of what the supplier thinks is involved in the project. It also means that you can track the project's progress relative to the component estimates once the work starts.

How do you evaluate the range of quotes before you? If a supplier only provides a single figure, you should ask them to resubmit their quote with more details, and if they can't then you should refrain from using their services. You want to deal with professionals, so you should only consider suppliers who act professionally.

Ask each supplier to explain their solution proposal, and also discuss the pros and cons of alternative solutions. They should be able to do this in a way that makes sense - you don't want to be blinded by the jargon. If they can't explain things in layperson's terms, then you should rule them out. Don't risk your money on something that you don't understand.

The proposals have to solve your business needs. People who are passionate about their work sometimes get so excited about their tools that they lose site of their customer's objectives. This is especially the case if the web developers get the opportunity to try out new technology. Technology that hasn't been proven in the field is often referred to as the "bleeding edge." You may be able to reap benefits from being an early adopter, but do you really want to be the guinea pig? Leave the risks to someone else.

Once you've eliminated the poor suppliers from consideration, the next step is to start differentiating the remaining candidates. Do one or two seem to be substantially more expensive than the others? Ask them to justify their figures. They may have a more sophisticated understanding of the true costs, or they may be charging too much. Judging by the breakdown, you should have an understanding of the solution's complexity and hence a fair idea of whether the justification sounds reasonable.

Likewise, ask the least expensive suppliers to explain their costs. Don't play them against the others, just mention that they are cheaper and ask them to clarify their figures. Some charge too little just to get the work, and this is reflected in the resulting quality. If their explanations don't seem reasonable, then they should be ruled out of consideration.
 Next, ask your suppliers about their project management techniques. How open are they? How are you kept informed of the project status? You need to know how project risks are being mitigated.

You should start rating each supplier using the following broad criteria:

  • History of successfully developing the kind of site you want.
  • Their understanding of your business. If they can't understand your business drivers, then don't engage their services.
  • Their ability to explain the technology.
  • The professional rapport you have with the main supplier contact. Do they seem trustworthy? Be wary of sales representatives who over-promise. Chances are they will under-deliver.

Awarding the Work

Once you've decided on a supplier, the terms of the project will need to be agreed upon. Simple brochure sites should be easy. You'll typically have something like five to ten pages to be completed over a one to two week period at the quoted price. Within reason, you should have the opportunity to provide feedback and ask for changes to wording or the design. Be aware that once you've approved the content or the look of your site, it isn't fair to ask your supplier to make sweeping changes, unless you're willing to contribute towards the cost and accept that the deadline may slip.

Larger projects need to be handled a little differently. You typically won't pay on completion but rather in stages. This may be monthly, or it may be when certain milestones are reached - agreed points in the project where certain tasks have been completed. You may wish to define these in your contract.

If your requirements are a little hazy, now is the time to nail them down. Feel free to ask you supplier to help out with them, but there will generally be a cost for their time. Firming up on the requirements can be a shock for both parties. It is possible that you've misunderstood each other, and the quote or estimate may not appropriate. Consequently, you should invest a lot of time in defining the requirements before evaluating the suppliers.
 
The Project

Understand Your Project Lifecycle

The lifecycle of a project can vary due to the methodology employed by the supplier, and will also depend on your specific requirements. Here's one example but be aware there are whole books on this subject that offer different perspectives:

  • Supplier: Write Functional Specification. This documents the functionality that needs to be implemented based on your requirements
  • You and Supplier: Review the specification together. Add anything that is missing, and correct mistakes.
  • Supplier: Write a technical specification. This includes the technical design of the system, and the components required to implement the solution. This may be a complete specification, or the specification may be written in stages throughout the project for each major phase. Depending on the project design, and what was agreed in the contract, some of the project costs may be refined here.
  • A module will generally consist of:
    • Graphic and screen designs.
    • Programming of the behind-the-screen functionality.
    • Unit testing - that is testing the individual components that have been developed.
    • User testing - your users try the system and provide feedback.
    • Integrated testing - testing how all the components interact.
  • Promotion to production. The system is moved from the test environment to the final production system.

Each of the above items should have had a time and cost allocated in the supplier's quote.

Your Role in the Project

Once the project has begun, it is up to you to ensure that it is a success. Don't leave it to your supplier, as there is a good chance that things will get bogged down and issues may arise that you should be aware of. You should have a project plan listing the milestones and delivery dates. There's no guarantee that all milestones will be met every time, but you need to keep on top of things.

While no one wants a project to get into in trouble, they sometimes do. Often the signs of problems were known in advance, but everyone ignored them. Below are some ideas for keeping a project on track:

  • Maintain an active interest in the project. You need to champion it within your organisation.
  • Have weekly or fortnightly project meetings - either in person or via a phone conference. Make sure someone is taking the minutes, and that they are sent to the appropriate people within a day of the meeting. This way, people will be aware of any actions that they have been assigned. It also provides the opportunity to supply feedback and make corrections if necessary.
  • Ask for a weekly status report. Each report should detail:
    • Accomplishments for the week.
    • Tasks were not completed the previous week.
    • Tasks that are expected to be completed in the following week
    • Tasks that were undertaken but were not planned.
    • The time taken by each team member, against each item in the project plan. This allows you to see quoted costs against costs to-date at a glance.
  • Maintain an issues document, detailing problems encountered, and potentials project risks that are identified from time to time. This may be attached to the status report, so that the issues can be perused each week rather than disappearing from view.
  • Keep other people in your organisation up-to-date and let them have a say, too. You want people to "buy into" the project. The more support you have, the less likely people will try to undermine it - either actively or through apathy.

 
Scope Creep

The words "scope creep" strike fear into the hearts of many project managers. Sometimes you might change your mind about what you want, so the scope of the projects starts changing. This can be a problem on a fixed cost project because the supplier doesn't have any margin in the budget to be able to afford those changes. The supplier's project manager only has two options available - try and accommodate your requests, or refuse to do the changes because they weren't in the requirements. Either way, one of the parties is going to feel aggrieved.

What causes scope creep? Sometimes you don't know what you want until you visualise some of the alternatives. If you think that this might be the case, allow for the building of prototypes in the project plan, and budget accordingly. In this instance, a prototype is a simple model of what will be built. It will have very little functionality behind the scenes, but you'll be able to see what the end solution might look like.

Your staff may be another source of scope creep. If the site isn't just aimed at the public but will also be used within the organisation, then the last thing you need is for someone to declare: "but that won't work with our accounting system!" Make sure that you keep the right people involved.

The reality is that most projects will have to endure changes of some sort. But there's a difference between refinements and complete redesigns. If there are grey areas that can't be fleshed out before the project starts, allow for them in the budget, and then finalise costs for these components at the earliest possible opportunity.

User Testing

The developed solution will require testing by one or more people from your organisation. The risk is that testing is approached in a cursory fashion and bugs or functional issues get missed. Testing needs to be thorough and complete. Devise and document a detailed plan with your supplier that tests each and every individual piece of functionality. Whenever changes are made, rerun the tests.

It is important to remember that your testing doesn't obviate your supplier from unit and integration testing. It's not your job to find the obvious bugs, but to ensure that the functionality meets your expectations. Start testing as soon as possible as this will allow you to gauge the quality of the work from an early stage, and take appropriate measures if you encounter problems. Too many bugs early on could be a sign that there are fundamental problems with the project.

Managing the Issues

As I mentioned earlier, you'll need some kind of issues document that records problems, potential problems and project risks. Some risks may be known in advance - say the production  hardware may not arrive before the system needs to go live, and some are identified during the project's lifetime - continual slipping of the milestones, project budget problems or even personality conflicts.

Firstly, you need to identify the problems early, and then come up with a contingency plan. If the hardware isn't going to show up in time, then can you make do with lower specification alternatives, or can the deadline be moved?  If the first couple of milestones are missed, then there's a good chance that all the rest will be too. In this case you will need to decide on the appropriate action. What does it mean to your business if the project is late? If you're the business owner or manager, then you may decide to live with things. If you need to approach your manager or the board, then you may need to be more circumspect.

The weekly status report and the issues document provide early warning systems. They give you an idea of the project momentum, and also allow you to calibrate future tasks.

But Wait, There's More!

This article provides a small overview of a big topic. I hope that you have found enough information to set you on your way, and that it has provided a foundation for further research. If you have any questions, or would like to provide feedback, I look forward to hearing from you.

The Last Words

  • Document your requirements in as much detail as possible before engaging a supplier.
  • Ask around for supplier recommendations.
  • Any quotes or estimates should contain a detailed breakdown of the costs.
  • Ask each potential supplier to walk though their solution and explain the details in layman's terms.
  • Make sure that the suppliers can justify their costs.
  • The project plan should have a list of milestones including costs and deadlines at each phase.
  • It is up to you to keep on top of the project's progress. Make sure you get regular status reports and act on any problems straight away
  • Keep track of all issues and risks.
  • Test early and test often. It may be the only means that you have to judge the quality of the work before it's too late to take action.
  • Changes to your requirements can be expensive and can put the project deadline under extreme pressure. However, small changes should be easily accommodated.
  • Identify potential risks and devise contingency plans.



© Copyright 2005 Redbone Systems Ltd
www.redbone.co.nz