Business tips

[bladeviper]

Any tips for someone just starting out in the Freelance web designing business. I got one client down, happens to be my college student government. But any tips on how to charge ppl and stuff more along the lines of the business side of things?

blade

[garion1]

Hi

I found this at http://www.ultrashock.com and found it very useful for running a project.

Introduction to Flash MX Projects
by Peter Elst, peterelst.com

Rule #1: get everything down on paper

This one is so important I just had to make it rule number one. From start to finish try to get everything down on paper and sign-off what you agreed upon both with your client and internally. It makes life much easier, and in the end is well worth the effort.

Most Flash developers, including myself, never really bothered with this process but with projects getting increasingly large and complex creating both a functional and technical analysis will help you and your team to be much more productive.

- Functional analysis

The functional analysis of a project provides a complete overview of all functionality the project will contain. This is also the tool you can use when communicating with your client on how his project should function.

Once the functional analysis is agreed upon you can move on to translating this into a technical analysis for the development team.

- Technical analysis

The technical analysis is in essence an extension to the functional analysis. It provides more detailed and technical information on how to handle each feature of the project and how these features should work together.

Rule #2: the timeline is your friend

We are all painfully familiar with deadlines and know how difficult it can sometimes be to keep them. This clearly illustrates the importance of managing a project timeline.

It is generally good practice to divide a project up into modules and assess where to put these on the project timeline. Module assessment is a very important step to effectively manage your timeline. Do not forget to take the dependencies of each module, the level of difficulty and the number of available people into consideration.

When you’ve got the project timeline laid out, make sure you leave some buffer-time between modules. The greater the difficulty of a module, the more likely it is prone to bugs, the greater the development time will be and thus the greater the buffer-time you will need to take into consideration.

One final word on the project timelines, how ever important they are don’t let them influence the quality of the end product and try to keep your timeline somewhat flexible to cope with unforeseen circumstances during the development cycle.

Rule #3: communication is the key

Communication is the key to keeping your customer satisfied, one of the oldest clichés in the book. The main objective is providing your customer with accurate and up to date information on the status of his project.

Rather than sending out daily/weekly progress reports or even worse have the client contact you to get information on the project status I would advise to put up a secure client area where your customer can log in and get a list of all ongoing tasks and their status.

At certain strategic times during development it might be wise to send out a progress report to your client. It shows that you are concerned with getting feedback and want him to actively participate in the project. Having your client give feedback during the development stage is really a necessary evil, avoiding it can cause much bigger problems in the end. The key is not to let it get out of hand, when small changes are made at the appropriate time during the development process it does not pose a big problem to your team.

If things do get out of hand, you can always fall back on good old rule #1 and show your client the functional analysis he signed-off on.

Rule #4: code management

Code management has become an essential part to developing projects with Flash MX. In the not so distant past the whole concept of managing your code almost seemed like a dirty word to many Flash developers but we slowly see more and more people adopting this principle and reap the benefits of using it.

Imagine the following situation without any form of code management: your client gives you a call and says he preferred last week’s version of the code but wants the changes implemented that were done today. At this point your average developer would start franticly browsing through lines of code banging his head against a hard surface trying to remember what changes were made (don’t try this at home kids!).

In a more perfect world the development team would have done a couple of things:

keep the ActionScript code in external files and version them
clearly comment the code for future reference
list all bugs and possible performance issues
keep a record of version changes and new functionality that was implemented
When you go one step further in this process you’re looking at systems like CVS (Concurrent Versions System) which allow you to easily and effectively keep track of different versions of your code and the changes that were made.

Given the same situation that was described above and with these code management measures in place you’ll be able to retrieve the correct code and apply the new features in literally a matter of minutes.

Rule #5: debugging and usability testing

You guessed it, yet another important issue when handling a Flash MX project: debugging and usability testing.

The first step in the debugging process starts with the developer, making sure the code works as it should. It’s often very tempting to simply track down a bug and start fidgeting around with the code till it stops doing what it wasn’t supposed to do in the first place. While this is the certainly the easiest approach to handle bugs it is also a very dangerous one. Always make sure you check your code for structural failure, if that doesn’t get fixed the whole thing remains very unstable and could come crashing down on you and your colleagues at any minute.

Try to submit bug reports for any bugs you encounter, even when the bug was immediately fixed it is good practice to do so for future reference. There is some great bug tracking software out there that can help you with this and that is obviously a much preferred over scribbling it all down on a piece of paper.

After this initial debugging process the next step would be to deploy the project to a local testing server. You would let some people run the application and have them write down any bugs they encounter. If bugs are found those are passed on to the development team, if not your project is ready to be subjected to usability testing.

Usability testing can be quite a complex and theoretical subject but in essence it is largely based on one principle “know your target audience”. When you know who your end user is and what the common tasks are that this user will want to perform you’ve got a basis from where to start testing. A few common mistakes are that the client is seen as the target audience for the project or that a good looking design is a user-friendly one. Those statements are not necessarily true and can’t be used as indicators for usability.

Be sure to keep record of the usability results to compare with any future releases and if possible run a questionnaire when the project goes live to help you assess and improve the reliability of your internal usability testing when it is exposed to the actual target audience.

Summary

The five basic rules I just discussed are basic principles that are hard to ignore when you start doing projects in Flash MX. The way you implement these features is not written in stone, you can have your own approach and see what works best for you and your team.

Whether you’re working as a single freelancer or have a group of developers behind you, the principles remain largely the same and will guide you throughout the project. We all know the best way to learn is to bring the theory into practice so I would advise you all the get your hands dirty and start working on some Flash MX projects.