A Simple Way to Handle Project Changes

Mid-project changes are common in many web projects. They can result in everything from delightful improvements in the user experience to wreaking havoc on the collective understanding of a project. While one development company may loathe the change as a cancer upon their pristine six sigma process another may embrace it as the quintessential essence of their innovative being. No matter what camp you stake your tent in, there are tools to help keep your project on track. I'm particularly fond of some paperwork called The Change Order Request. It is wonderfully simple and does a good job of maintaining a collective understanding of a project among project stakeholders; but particularly among those responsible for the contracts.

I’ll start off by listing the essential sections. Then I’ll wrap up with a few observations.

A Change Order Request should cover who is behind the change, what is the change, how does the change impact the project, when does the change need to happen and finally the approvals section. One additional section that we at PaleoSun recommend including is the deadline for sign-off. In other words, when does the Change Order need to be signed and approved before it is too late, and the agreement is no longer tenable? Let’s take a closer look at these sections...

There is the Header information:

• Document Title
• Client Name
• Project Name
• You could include Agency or Consultant if relevant
• The date the document was first prepared
• The document version (e.g. 2.0) and the date of the revision

The next two sections cover ‘Who’ is behind this change:

• Requestor: This could include the client’s name, perhaps a person or two who might be spearheading the change, and detailed contact information.
• Approved by: This should include one or more project stakeholders in support of this change including detailed contact information for each person, the person’s title and their place of employment.

With the next 3 sections we’ll cover the iron triangle... Scope-Time-Money:

• Description: What is being changed?
• Cost Impact: This could be as simple as, “The project cost will increase by $X.”
• Schedule Impact: The completion of this project has been extended by x days.

More dates:

• Activation Date: When can we start making these changes?
• Deadline for Sign-off: Sign-off is required to prevent unnecessary project delays. The deadline for receiving sign-off is Month Day Year.

And finally, the Sign-off (or Approvals) section:

• Say a few words about what it means to sign this document. For example, “By signing this Change Order you authorize PaleoSun, Inc to make changes outlined in this agreement and accept all conditions of this agreement including any time extensions and additional costs.”
• Change Approved by: (fill in client’s name)
• Authorized Signature:
• Name
• Title
• Affiliation
• Date
• If this project is significantly influenced by a third party like a consultant or ad agency then you might include a duplicate sign-off section for that third party.

Here are a few things we’ve learned from using Change Order Requests.

Manage Expectations: In your first full project team meeting, introduce everyone to your process of using a Change Order Request document. You don’t need to dissect the document pointing out all of the glorious details but rather just let people know that projects frequently change unexpectedly midstream and that a formalized Change Order Request Document is part of your process.

2.0: Change Order Requests can have many changes prior to approval. Keep the ‘versions’ section in the header up to date and always reference the version you are talking about.

Consider the Details: People have varying opinions when it comes to how much detail should be in a web development agreement. I find that most creative shops prefer to be as brief as possible. When it comes to highly functional websites I think it pays to be detailed. This Change Order Request document is about to override initial project expectations as well as the current contract so I believe details can be useful especially when talking about Scope, Time and Money.

Include an Appendix: On occasion we’ll reference more detail in an appendix to make the initial Change Order document easier to read. Your appendix could include complicated scope changes, detailed cost breakdowns and a revised timeline showing how milestones have been adjusted.

Follow-up Reminder: Add a reminder date to your calendar or project management system a few days or so before the Deadline for Sign-off. That way, if the client drags their feet you won’t forget to follow-up with them.

Magic Words: Finally, a change order is not always necessary. Deferring changes could be an option. Some changes might be worth the trouble of incorporating into an already active project but might be better served as a Phase II item. Make sure your client is aware of that option lest they feel their new favorite feature idea is a now-or-never proposition.