The freelancing business part 3: scheduling your projects

By R Blank

• Previous article—The freelancing business part 2: budgeting your projects

Introduction

Previously in this article series, we discussed budgeting and pricing; in this third article we carry on the discussion about making money as a freelancer, covering the role and importance of schedules in profitability.

What is Scheduling?

Scheduling is the process of creating and maintaining schedules. Schedules map tasks (things to do) and resources (people to do those things) against time on a calendar. Schedules bring order to the planning and execution of any project, and provide you with information that allows you to increase your control over whether a project is profitable or not.

On one level, of course, scheduling is a simple concept. We have things to do, and only a limited number of hours in a day, so let's plot those things (or 'tasks') on a calendar, and - voila! - we have our schedule!

But in the context of our discussion, that just scrapes the surface. In real-world project development - even when you're a freelancer working alone - schedules aren't just used to determine what you'll work on today. The process of scheduling is fundamental because it helps us answer several very important questions, as we'll shortly address.

Just as a project specification provides significant detail on the functional performance requirements of our project (the individual features required in the application), a schedule provides that same type of detail on how the project is executed - the individual tasks that are required to build the application. Once your schedule is complete, you should know, with as much specificity as possible, which tasks are required from which resources on which days, for the duration of a project.

By outlining these tasks, you can determine realistic deadlines, evaluate the relative priority of individual tasks and features, and define dependencies (what other tasks must be completed before starting a given task). Maintaining this schedule of tasks throughout the project allows you to adjust your deadlines in advance, given unpredictable events (a client misses a deadline; a blizzard knocks out internet for all your developers for two days, etc.), enabling you to control expectations in advance, and increase charges when appropriate.

The more clarity and detail you have in your schedule, the more likely you are to run a profitable, low-stress project that is completed on-time - and the earlier in the process you will know if the project is trending off-course. In the absence of an accurate or sufficiently detailed project schedule, it is entirely possible to obligate yourself to deadlines that you do not realize are unrealistic and miss deadlines without advance notice.

Types of Schedules

There are, of course, many types of schedules. But in my estimation, in the world of service work (the type of work we all do - where we earn money based on each hour we work), there are two broad types of schedules: task-based and resource-based. These account for the two broad ways in which projects are conducted in our industry: waterfall and agile (these broad, general groupings are applied for convenience, as more or less any software development workflow can be categorized under one or the other).

The waterfall project model (Wikipedia entry for 'Waterfall Model') defines structured, consecutive project phases. For example, you first define the requirements, then move into a full design phase, then implement (or 'produce', or 'engineer') the design, verify the end result, deliver it and enter into maintenance. The agile model (Wikipedia entry for 'Agile Software Development') was created to support a less structured, more agile way of producing projects in an iterative manner, in which definitions, features, designs and requirements can change throughout the project.

In those projects I group under the broad term of waterfall, the tasks are fixed, and then you apply the necessary resources to hit your deadlines (functional requirements are fixed, and resources are variable). Such projects more readily conform to task-based schedules. In those projects that fall more under the Agile model, resources are fixed, and then you determine what tasks you can take on (the resource calendars are fixed, and the functional requirements can vary). Such projects often follow resource-based schedules. Both types of schedules have benefits and drawbacks.

In task-based schedules, you need a pretty accurate list of tasks in order to derive the schedule. That means you need to put a lot of thought, up-front, in to exactly what tasks are required to build the project - including the dependencies of these tasks (for example, 'configure server' must be executed before 'install Drupal'). Such task-based schedules are commonly applied to waterfall-style projects, where detailed specifications are authored prior to execution of production labor. It is also generally easier to sell projects in this manner, because your clients have a definite, guaranteed feature-list prior to production (again, because the specification is defined in detail prior to building the software).

In resource-based schedules, you have a list of resources - generally people, for example designers and developers and QA testers and project managers and so forth. Then you place those resources on calendar, and say 'you have resources X, Y and Z for 3 weeks, and resources P, Q and R for 6 weeks'. The key benefit here is that you can start your production more rapidly, based on a less detailed project specification - and you don't have to invest the effort into planning documentation. It is for this reason that such schedules are more appropriate for Agile-style projects, where complete documentation is the result of, not the precursor to, production. The trade-off is that there is (in my opinion) significantly more project management overhead for the duration of the project; the project specification (which is more or less sealed prior to production under waterfall) is in constant flux, and tasks and requirements must constantly created, modified, assigned, and re-assigned.

Scheduling tools

Later in this article, as I discuss the process of creating and updating your project schedules, I will assume the use of software for the task. There are a class of project management tools, but many people prefer using spreadsheets for the task, so here I outline a few options of both types.

Spreadsheets

There are several popular spreadsheet programs available, including Microsoft Excel (PC and Mac), Apple Numbers (Mac), OpenOffice (free for PC, Mac, Linux and UNIX), and GoogleDocs (browser-based, cross-platform). And all offer the same core functionality.

Spreadsheet programs are an invaluable tool for any variety of data representation and calculations. But in terms of project management, they only get you so far. Spreadsheets are good for handling resource-based scheduling, and they are also useful on simple projects, or projects requiring only a few resources. But on task-based projects, with multiple resources, spreadsheets are only useful for ball-park estimations; spreadsheet tools lack several of the core features that are standard in project management tools (described below).

With that disclaimer, I want to encourage as many freelancers as possible to start using spreadsheets for project planning. Because many of you will not move to project management tools until you start taking on more responsibility on larger-scale projects, in the interim you should feel comfortable using spreadsheets (which are, in truth, amazingly flexible and powerful) to help you plan your projects.

Because spreadsheets are so flexible, there is really no fixed or set way to use them to help you manage your project schedules. In this context, you should think of a spreadsheet as a blank project calculator that you can build from the ground up, to help you track and calculate whatever data your specific project requires.

Project planning tools

While spreadsheets are useful, they will only get you so far - they lack some key features that make project planning much easier. There is a wide array of project management tools available for purchase (I have yet to find a suitable one for free), for desktop and for web.

The industry-standard in software and interactive is Microsoft Project, which is an incredibly powerful tool. However, there is no version for Mac. If you are on a Mac, you have options that include Project Wizards Merlin (which is roughly of the same complexity and power as Microsoft Project), and OmniGroup OmniPlan (which is much simpler, and less expensive, but with much of the same functionality). There are, I should note, a large number of web-based project management tools, as well (such as Project Insight), which bring similar project planning functionality to the browser. Because of platform, simplicity and cost, we have standardized around OmniPlan at my company, Almer/Blank.

All project management tools share the same core concepts - a set of data structures and calculation features specific to the needs of schedule management. All of these tools have features that go far beyond these items, but these are the core concepts shared by all of these tools, and the ones that you should understand in order to use any of these tools. These include:

Data Structures:

• Tasks: Something that must be done. Most commonly, tasks are assigned to resources (defined immediately below). A task can be shared by multiple resources (such as if an engineering feature requires two developers instead of just one)

  Most tasks take time, and you can estimate that time (also known as 'effort') when creating the task. If a task does not take time, it is known as a 'milestone', which is a type of task that represents a goal that must be met (such as the task in your schedule for the client to approve a deliverable)

• Resources: Someone (such as a developer), or something (such as a sound recording booth), that is required to execute tasks

• Calendars: Represents the availability of resources, including how many hours in a week these resources can work, and when those hours will occur (such as "developer x works 9AM to 5PM - with one hour for lunch, Mondays, Wednesdays and Thursdays, for a total of 21 hours of work each week"

• Dependencies: Represents the relationship of two separate tasks. There are different types of dependencies. The most common is 'Finish-To-Start' (or, 'FS'). If you specify task Y as having a finish-to-start dependency on task X, then task X must be completed before task Y can begin (and, relatedly, if task X is late, task Y will also be delayed). Other types of dependencies include Start-to-Start (or SS, in which both tasks must start at the same time -- neither can start until both can start) and Finish-to-Finish (or FF, in which both tasks must end at the same time -- neither can be considered complete until both are complete). There is also Start-to-Finish (or SF), which is the opposite relationship of FS (meaning, if task Y has an FS dependency on task X, then task X has an SF dependency on task Y)

  In all cases, if two tasks have a dependency, unless otherwise specified, there is assumed to be no lag. So, if task Y has an FS dependency on task X, then task Y can begin as soon as task X is complete. Sometimes, however, you need to anticipate a delay. For instance, if you need to test a new website at the correct URL, the testing task is dependent on the task of pointing the domain name to the right IP address (through, for example, GoDaddy), a process which might take up to two days. In this case, the testing task has a finish-to-start dependence on the domain change, with a two-day lag. So, you might write that it has an 'FS +2' dependence. You can also have negative lags. For example, if task Y has an 'FS -3' dependence on task X, then task Y will begin three days before task X is complete

Functions:

• Leveling: Leveling is an amazing feature that greatly eases the process of schedule management. If you can think of the process of setting up all your data (the concepts defined immediately above) as akin to gathering ingredients and writing up a recipe, then you can think of leveling as an automated chef. Leveling takes all your ingredients (the tasks, with their estimated effort, assigned resources, and interdependencies, and the project and resource calendars) and generates realistic dates for all tasks. It is called leveling because it is like taking a knife to icing on a cake, smoothing the assignments across the entire project plan - ensuring, for example, that no resource is assigned to work 30 hours in a single day

• Baselining: Schedules are not only created, but maintained. Even under master project managers, overseeing skilled experienced teams, no project schedule ever proceeds 100% according to plan. So, as you maintain a schedule, it will deviate from your initial estimates and assumptions. If, throughout the project life cycle, you wish to understand the precise source of the discrepancies between your estimates and your actuals (that is, which tasks are taking more or less time than anticipated), you will want to establish a baseline for your project

  Baselining your schedule is sealing a draft of your schedule -- akin to turning on 'track changes' in Microsoft Word. So that as you continue to edit and modify the schedule throughout the project, you can see the precise differences between what you thought would happen, and what is actually happening

Building and Maintaining Schedules

Creating a Schedule

There is no fixed way to create a schedule. The schedule creation process will depend entirely on the specific requirements of your project - at Almer/Blank, we create schedules in multiple ways, depending on the individual nature of the project. And this is another way of saying that the process of creating a schedule is a meditation on the project. Having to author a schedule forces you to consider the various aspects of the project context, to consciously determine the appropriate model for a project, and to ensure the feature scope, deadlines and budgets are realistic.

Creating a Task-Based Schedule

Creating a task-based schedule is necessarily an involved process, as it requires you to think through the project in detail, up-front. Because of the complexity, in this description, I will assume you are using a project management tool rather than a spreadsheet program to author your schedule.

The basis for a task-based schedule is a detailed project specification (you should only ever take on fixed-fee work if there is a detailed project specification; otherwise, you should work on time and materials, or proceed with a resource-based schedule). Without a detailed document defining each aspect of the project being executed, creating an accurate schedule is impossible - the best you can do is estimate, based on past experience. Of all the materials we generate and use in a project, the schedule is often the only comprehensive list of all tasks on a project. So, authoring the schedule is usually the only the opportunity we have to analyze the comprehensive list of tasks. This, in turn, is important because analyzing the entire list of tasks at once is the best way to reveal dependencies, that is, which tasks can not start without other tasks first being completed.

Any task-based schedule has the key ingredients of tasks, dependencies, resources, and time. As described above, The relationship of these ingredients is that: resources perform tasks in time, constrained by dependencies.

First, you will wish to break the project down into top-level phases (or task groups), which might include items such as 'Discovery' or 'Wireframing' or 'Graphic Design' or 'Engineering' or any number of other various categories, which depend on the specific work you are doing and the process you are following. The next step is to define the tasks for each phase. You should be able to generate the list of tasks directly from the project specification.

Even with a detailed project specification, the process of generating a list of required tasks can be challenging, and you will often wonder whether you are applying sufficient detail in your breakdown. The more refined a list of tasks you can create, the better, since it gives you the opportunity to think over each aspect of the project in detail, and establish the inter-dependencies between these tasks. But, you should only break down tasks with the degree of detail you feel is required to properly understand and track the work that must be done. As long as you can accurately account for the work that must be done, and understand all the important dependencies, you've covered the basics.

There will often be occasions in which some of your resources will need to work, but not on the type of tasks that might be represented in a project plan. Some examples are the Project Manager, Producer or Account Manager. You might sometimes hear the phrases 'above-the-line' and 'below-the-line' (terms taken from Hollywood's movie making operational model) - and while 'below-the-line' talent, like an engineer, can be readily assigned to tasks, 'above-the-line' talent, like an account manager, can not. But, of course, their hours are still valuable and billable. So, to calculate the labor requirements of 'above-the-line' resources like project managers, we use a formula (say, 30% of the total hours of the 'below-the-line' talent whom the project manager manages), and then create a blanket task 'Project Manager Allocation', reflecting those hours.

With your list of tasks, you then proceed to estimate effort for each of those tasks (or, alternatively, set them as milestones), and assign the resources responsible for each task. Once that is complete, you can level your project.

While you will often view your project plan as a table similar to one you might create in a spreadsheet program, one benefit of using project management tools is the ability to view your project as a Gantt chart (Wikipedia entry for 'Gantt chart'), which is a visual summary of tasks, along with their dates and dependencies.

Sometimes, your project will look good after the first level, but often you will not be able to make your target dates with the initial draft (you compare the dates of your milestones, against the dates your client has requested, for example). In this case, you need to alter your assumptions as appropriate (for example, re-assigning certain tasks, reducing some turn-around times, removing some features, or moving deadlines), and then re-level.

This process requires the confidence to make a tremendous number of assumptions and guesses (after all, you are trying to plan out an entire project) on a wide variety of questions, including the effort required for each task, who will execute the work, inter-task dependencies, when third parties will be able to provide key deliverables, and many more.

You must be comfortable making assumptions, otherwise you will be paralyzed, and unable to complete the process. It can be incredibly and painfully easy to spend far too much time worrying if task X is going to take four hours or seven hours. While you of course want your schedules to reflect accurate assumptions, you should not over-think:

1. There will be variances throughout the project - even on items that you didn't think were guesses - and so you must be prepared to handle variances anyway
2. You will get better at guesswork over time
3. The purpose of a schedule is to get a realistic benchmark, not the absolute truth, so four hours instead of seven is not the end of the world (see the note on Buffering, below)
4. Odds are, your mistakes will go a good deal towards canceling each other out. So, for example, task X might take seven hours instead of the estimated four, but task Q ended up being totally unnecessary, saving three hours, netting your variance out to zero in this simplified example.

Again, the point is to make best guesses (which will improve in quality over time) and not to author the definitive truth. The only time a schedule is ever 100% accurate is when the project is over.

A key part of this process - and one skipped at many companies - is to review the assumptions in your schedule with all relevant stakeholders (the people involved, with a stake in the project). You should sit down with all team-members and the client and ask questions such as such as 'is four hours realistic for this task?', 'can you make these deadlines and turnaround times?' and 'do you see any missing dependencies?'. Their input will be very helpful in refining your draft plan into a more accurate schedule. And once you are complete drafting the schedule, you can seal the baseline.

So, the process of authoring a task-based schedule, while not easy, is simply described as follows:

1. List all resources, along with their accurate work schedules
2. List all tasks
   • Estimate effort
   • Assign the task to a resource(s)
   • Estimate dependencies
3. Level
4. Review with stakeholders
5. Update & re-level
6. Establish the baseline

As a sample, I have authored a broad project plan for a moderately complex project, involving eight resources (as well as placeholders for the client, ACME Corporation, and us, Almer/Blank, so that delivery milestones might be assigned to firms, rather than individuals). The tasks are grouped into phases (such as 'Project Requirements Definition' and 'Interaction Design') and the phases are grouped into what we term chapters ('Discovery', 'Design' and 'Production'). Many of the tasks, task groups, and phases have dependencies (for example, Information Design can begin only once the Product Requirements Document has been finalized). Then the tasks are assigned to the resources who must carry them out. And finally the plan is leveled and the baseline established – check out my sample taskplan.

This sample plan is typical of one that we would author at the start of the project, and thus effort is greatly simplified. For example, under Beta > Engineering, you will see that 'Engineering' is a single line item scoped to 100 hours; in this example, the actual individual beta engineering tasks would be defined, and inserted into the project plan, following the software design phase.

We use OmniPlan for our project plans, but all of the major project management tools available contain convenient export functionality, so that plans can be converted to CSV, XML or MSProject files, or HTML summary output (you can download a full project plan sample package and check it out, or check out an OmniPlan version of the plan).

You can also generate bitmap snapshots of the Gantt chart of the project plan, as indicated in Figure 1.

Figure 1: A Gantt chart of our sample project (click the image for a much larger version).

Maintaining a Task-Based Schedule

Because so much effort went into authoring the project plan, as long as it is realistic and there are no significant changes, maintenance is a relatively easy task. Simply update the 'actuals' - the data representing the actual way the project has proceeded (as opposed to the estimations you applied up-front). You will enter actual data for hours worked, percent complete, and start and end dates. If you want to track deviations in detail, be sure that you have set your baseline before updating any values.

If changes in the project require that tasks be added, removed, or re-assigned, or that task dependencies be altered, you may do so in your project plan as needed. Once complete, you will need to re-level, to view the impact of these changes on your deadlines.

Creating a Resource-Based Schedule

Creating a resource-based schedule is, in many ways, much easier than creating a task-based schedule. However, this process requires different skills. First, you must be able to gauge required resources (such as roughly how many developer hours are needed) from a vague or incomplete specification. And second, once the project is in motion, you must constantly update the specification and resource assignments.

The basis for a resource-based schedule is some sort of feature-list. Even though a detailed specification is likely absent, you still need to gauge, from a top-level, the broad requirements of the project. From this top-level feature list, you will need to estimate the required efforts of the various resources on a project (which could include roles such as project manager, producer, software architect, engineers, visual designers, user experience designers, production designers, information architects, QA testers, and others). Once you've done that, however, the job of creating the schedule is easy, because you can simply plot those out on a calendar - for example, 3 engineers for three weeks at 30 hours a week, a visual designer for 2 weeks at 40 hours a week, and so forth. A resource-based schedule often completely lacks any indication of tasks and assignments - it is reflective simply of availability.

I've authored a simple example of a resource-based plan spanning nine weeks with three milestones - each occurring during a 'pink' week – see Figure 2. At the start of the project, based on initial discussions of scope (and, perhaps, following a separate Discovery project, in which the project requirements and goals are established), I sit down and make assumptions about which resources are needed (in this case, seven of them), and what their weekly allocations will be (you could take this down to the daily level if you want to). The result is the number of hours required from each resource, each week, and the total number of hours available to execute the project.

Figure 2: A simple resource-based project plan.

Maintaining a Resource-Based Schedule

While authoring a resource-based schedule can be easy, maintaining a resource-based schedule is much more involved. It is less a matter of maintaining the schedule, than it is of maintaining the feature specification. Throughout the project, you must constantly update the project specification, to reflect the actual tasks that are being executed, and the features of the final deliverable in production. The schedule itself should not vary, unless the client decides to extend or reduce the engagement - so you must maintain vigilance over the progress and the specification, ensuring that features are removed as needed, in order to maintain the schedule.

In order to maintain vigilance over progress, you must be able to track the time and progress of your resources on their work. Which means you must still break the work into separate tasks, so you can see how much is being done. Since this task list is not reflected in the source schedule, a separate document must be created to track these items. And because they were not established up-front, they must be created and maintained in real-time, throughout the project. Often times this is done in another spreadsheet, or with a web-based time-tracking system (or, in some Scrum environments, on Post-It^TM notes) - but it is a necessarily involved process (which is why some agencies who use systems like Scrum, offer training to their clients in how to work with it - because the on-going overhead requirements of such just-in-time production methodologies are so significant).

Following on the simple example above, each week the Project Manager tallies the actual hours, enters them into the spreadsheet. By the end of your project, you have the actual number of hours consumed on the project – see Figure 3.

Figure 3: Actual hours worked on a project.

Taking this one step further, you can simply subtract your actual hours from your planned hours, and see where all the deviations come from – see Figure 4. In this sample, I've applied color-formatting rules to each cell to quickly indicate if the resource came in under or over hours for the week. In this example, while there was a lot of variation for each resource each week, overall, we came in 18 hours over budget (a negative variance of just under 1%, which is not too bad).

Figure 4: The variance on our project – how the actual hours differ from our estimates.

Buffering

With any schedule, you will want to create some leeway - space in your planning to accommodate the surprises that inevitably await you. This helps maximize the chances that you can keep your promises. Which means accounting for uncertainty. In the context of schedules, accounting for uncertainty is primarily handled through a process called buffering. There are two very easy ways to do this.

On task-based projects, one way to buffer is to buffer your dates. That is, if you've filled out your schedule, and it says the work will be complete on March 15th, you can tell the client that it will be ready on March 22nd, giving yourself an extra week. This will help you deal with unforeseen events, such as server downtime, or another client calling you up with an emergency that takes you two days to resolve. Because you buffered your deadlines by a week you have time to handle all of this. And you might still have a little extra room to accommodate client change requests, and you might even deliver early! Another way to calculate a similar buffer in task-based projects is to reduce resource schedules. For example, if your team works 40 hours in a week, in the project plan you might indicate that these resources work 30 hours, creating a 25% buffer on deadlines.

On resource-based projects, since the resource calendars are fixed, and the tasks are variable, buffering occurs on the tasks. Instead of adding everything to the specification, you can create a list of 'nice-to-haves' (or, roughly speaking, the 'backlog' in Scrum-speak). This way, if you complete everything that is required, you can deliver on some extra features; but if some required features take more time than anticipated, you can drop those extras.

The Relationship of Scheduling and Budgeting

In this article, I've covered the importance of scheduling primarily from the perspective of time - that is, representing accurate project timelines, and ensuring you hit your deadlines. Because we all work in service roles (again, because, roughly speaking, each dollar we make is due to an hour we worked), schedules directly inform budgets (which I addressed at greater length in my article, Budgeting Your Projects).

At the start of a project, with both task-based and resource-based schedules, as described above, you have a total number of hours to be worked by a list of resources. Simply multiply the number of hours each resource works by the cost of that resource (and account for other expenses, such as travel costs or software licensing fees) and you have your project budget. If the budget that flows from your schedule exceeds the available budget, then you know in advance that you need to trim features and resources.

In our task-based example, simply enter rates for each resource into the resource entry in the project management tool, as seen in this task-based costing page. Let's assume for simplicity that everyone's rate is US$100 per hour, in which case our budget totals to $98,300. If we update our rates, resource assignments, or hours, the project cost will update automatically.

In our resource-based example, we can calculate the budget by multiplying each resources hours, by his rate. Let's assume for simplicity that everyone's rate is US$100 per hour, in which case our total budget is $184,200, as we can see in Figure 5:

Figure 5: Calculating the cost of all our resources.

Once a project is under way, maintaining the schedule is a process that proceeds hand-in-hand with protecting the budget. When you properly maintain a schedule during a project, it is easier to detect and understand variances earlier in the process, and if variances in the execution of a project are leading you to exceed your budget, you have more time in which to respond (perhaps by increasing the budget, or dropping other features, or eating into your planned profit).

In any case, a good schedule is essential to ensuring that you maintain your budgets and execute your projects profitably!

Conclusion

In this article I discussed the importance of proper schedules in profitability. I covered what scheduling is, the broad types of schedules, how to create and maintain project plans, available project management software, and the wisdom of buffering your plans. I ended by linking the schedule to the budget, which was covered in an earlier article.

Thus far in this series we have covered pricing and budgeting and scheduling. Developing a sophisticated grasp of these topics (in addition to creating a good project specification document, which I consider to be more of a technical topic, rather than a business topic) is incredibly valuable in helping you to maximize your profitability.

In the next article I will begin to cover the importance of contracts in ensuring profitability. Your price, bid, budget and schedule all rely on a series of assumptions. You are responsible for, and in control of, some of those assumptions - other assumptions (such as turn-around times on client approvals, or access to the client's servers) are out of your control. Since many issues that are out of your control are vital factors in your profitability, you will need a way to enforce those assumptions (such as that your client promises to make all turn-around times in two days). And that's what contracts are for in this context -- to ensure everyone promises to do what is required to ensure the project gets done and you make a profit! Thus the remaining articles in this series of how to make money as a freelancer, will focus on ensuring that all your assumptions reflected in the budget and schedule are adhered to, and everyone plays fair.

• Previous article—The freelancing business part 2: budgeting your projects

R Blank

R Blank is an entrepreneur, author, community leader and teacher. R has specialized in the development of rich interactive applications for over 13 years and has focused on Flash Platform technologies for the past 8 years.

R is currently CTO of Almer/Blank (almerblank.com), an Adobe Solution Partner based in Venice, California that specializes in video and application development in Flex, Flash, AIR and open source technologies, for clients including E! Entertainment Television, Microsoft, Apple and IKEA. R is also the Director of Training at the Rich Media Institute (richmediainstitute.com), which offers workshop training for digital professionals from industry leading talent.

R founded and manages LA Flash (laflash.org), a community of over 2,800 Flash industry professionals, and home to three Adobe Users Groups for Flash, and also teaches Flash and interactive technologies on the Information Technology Faculty at the University of Southern California Viterbi School of Engineering.

R is the author of the DMTS Flash CS3 Jumpstart online training, AdvancED Flex Applications from Friends of Ed, and the DMTS Inside Flash 8 instructional DVD. Previously, R co-founded Wildform, where he co-created Flix, the first video encoder for Flash.

This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.