Question: I write and edit online courses for an e-learning developer that builds custom courses for big corporations. I'm concerned that I spend too much time making last-minute changes submitted by the developer's clients. More detail on the situation: I work on a flat fee, but I'm not concerned about my income -- the fee covers the many hours required to make changes. I'm more concerned about my sanity. Many of these changes would have been avoided (or would be billable) if the developer required a signoff on content early in the process. However, the developer doesn't require content approval until the course is done. How can I help the developer minimize changes from their clients? Their current process: Write a design doc that includes details about animations and content. Client approves it. Write the content, sending drafts as Word docs to the client for their changes. No official SME review or approval is required. Put the content into HTML and Flash. Do an alpha test. Make expensive changes because stakeholders and SMEs didn't see the content during step 2. Do a beta test. Get content approval and deliver the course. I think the developer should require formal approval of the content in step 2, when things are easy to change. Is this reasonable? Any other ideas? Answers: Two Philosophies of Development: I'm reminded of the old joke about psychiatrists: "How many psychiatrists does it take to change a light bulb? Just one, but it has to really want to change." I suspect that changing your client's process is going to be very difficult, especially if your client doesn't perceive the frequent changes as a problem. If it's driving you nuts, you could start charge a flat fee which includes X number of change requests, and then charge by the change afterwards. In some ways, it's effectively the same as charging per hour, but it may make your client think twice before requesting any changes. That does nothing for your client's client, but you only have control over how you operate. In any case, I used to be a software developer, and there are two basic philosophies to managing constant changes. One philosophy is the old-style waterfall approach, where the design and requirements are signed off and iron-clad before any development actually begins. The entire project is designed all at once, and then developed all at once--any changes after development begins are slotted for version 2. In practice, waterfall development is seldom this disciplined, but this is the ideal. The other philosophy is to embrace constant change. There are a few names for this, the most general of which are agile development, or iterative development. Essentially, instead of one big design/development cycle for the whole project, you have many short iterations (e.g., two weeks) where you gather requirements, design and develop a small but complete section of the larger project. After every iteration, you have a complete, standalone project. Every iteration is treated as a new version in that you can add new things or change the old version, but the scope of all the changes must be small enough to fit into your short iteration. Agile methods require a lot of prototyping and interaction with the client. I'm a big fan of them for in-house IT development, but off the top of my head, I don't know how well this translates to courseware development. Persuade them with numbers I agree that it will be difficult to change your client's processes if they don't see them as a problem, though you have some good ideas. There are a couple of things you can do to point out the seriousness of the issue: Run the numbers. I can guarantee that your client and your client's client will sit up and listen if you can show them (for example) that a change in the design phase costs $10, while a change in beta costs $1000 and a change after final signoff costs $10000. If your gut is saying that they can save 25% of their cost of doing business by tweaking their process, then back it up with a little research and a concrete example. The client will appreciate it and you will get more business. For example, if I add 2 topics in the design phase before the content is written, I can make the change by adding line items to the outline or storyboard and the information gets incorporated as I go and the opportunity for error is small because I haven't done anything yet. If I add the topic after the content is written but before it is compiled, I then have to figure out what other topics that new content is related to; revisit existing related topics to add links, or to tweak the content according to the new content; edit all the related topics to be sure I didn't miss any; go back through the review process; and the opportunity for error is medium to large, depending on the size of the change and the complexity of project I'm working on. If the change occurs after compilation, I have to do all the steps above, plus recompile and retest, which adds even more opportunities for error. Add a change management process to your list, where changes are prioritized and ranked on a scale of 1 (vital) to 4 (new feature, scope change). In the early phases of development, all changes are fair game if they fit the scope. Later in the process, the project team needs to be more strict about prioritizing the changes. Also, every person on the team who can request changes should be aware that the change at this stage will cost $X. They may still want to make the change, but they are making the decision with a better idea of the consequences. Examine the process and the changes you are receiving and see if there is a way to increase the communication with the client's client. For example, are you allowed to attend the project meetings or have access to the SMEs? If not, is there a way that you could gain that access? This may be a way of reducing the number of changes. If all else fails, take a deep, cleansing breath and repeat the mantra: it all pays the same (assuming you are doing time and materials). I have to remind myself of that when clients do things that go against my better judgment. At a certain point, if you've told them what the issues are and they refuse to see it, you have two options: a) fire the client or b) allow them to pay you twice -- once when they do it wrong and again when they ask you to fix it for them. Actually, when I feel strongly that a client is going the wrong way (and I know they have a sense of humor), I sometimes tell them that b is a viable option by saying (while smiling) something to the effect of "well, you can choose to do it that way if you really want to pay me twice for the work -- once to do it the way you want, and when your way doesn't work, the second time to fix it." It usually takes them aback enough that I can then explain the cost/benefits in more detail. CAUTION: I only recommend that approach if you know the client really well and have a long-standing relationship with them and they trust you. Add more signoff points: You've gotten some great ideas with which I wholeheartedly agree. Since you're not on hourly, your pain is obviously more than the folks that can just say "bill 'em." I agree with your process, and here's where I gain sign-off: Design Document -- for content scope and approach Prototype -- primarily for look and feel Storyboards -- (on a unit-by-unit basis) for content appropriateness, accuracy, and completeness as well as appropriate methods/media Key frames -- when using a great deal of Flash art, I like to get signoff on the key frame art prior to animating it. I like to give it to SMEs in a flat course with the associated text so they can see it come together prior to full animation Alpha/unit review with full animation, interactions, etc. Beta/integration review of full course It seems like a lot of sign-off, but it does save headaches. Since your client is reluctant to change and sees no benefit, then the suggestion of tracking time is a good one. With most of my projects, I add a rework category to my timesheet. I can even add a rework category for each stage, especially those past prototyping. For example, if I have to rewrite a storyboard to include new content, then those rework hours need to show up. In reality they reflect on the review of the design document. As everyone has pointed out, the amount of hours it takes to correct a change that should have been caught at an earlier stage increases the farther into the development process you have to make it. If you can do this detailed tracking (and for one project, we built a database), you can really show where your processes are breaking down. It does, however, take buy-in from a project manager in one client company or another. Another way to manage it, especially for those on T&M, is to document every change as a change order. We're building a house now, and it's all documented, priced, signed off on, etc. And I want it as much as my contractor does to control costs). You can give them a few freebies and then say, holding up the stack of free ones, "I've done these changes without extra costs, but from now on, I'll have to charge you." I know this doesn't directly apply to your situation, but as a future reference . . . You also may have to look at your own "true rate" (actual rate/hour spent) against the "billed rate" to see how big the gap is. If you're in a position to give the fixed bid, then you need to either increase the estimated hours or your rate per hour to be sure you're being adequately compensated. You may also want to look at how contracts are worded, how scope of work is specified, the built-in assumptions, etc. I always build in some good assumptions that specify work outside these assumptions will result in additional costs--even if the project is a fixed bid project. I can then go back to those assumptions, if I need to, to point out where I had to do work not called for. And last, a good lead in to any consultative advice is, "I would be remiss in my duties as a consultant not to suggest to you that you . . . " (in this case) "could save yourselves some time and money if you took a hard look at your processes." Then you can offer to help them, if they are so inclined. Other than that, the psychiatrist joke applies :-).