Waikiki Kahuna May 22nd, 2010 at 1:17 pm

Does this happen on projects ? Why would Collins project have been exempt ?
<<Contractor or Scapegoat? Keys to Successful Contracting
By Georgina Laidlaw
February 17th 2005

Reader Rating: 9.2

It seemed like a great opportunity at the time. A business acquaintance contacted you with the offer of some contract work. It sounded perfect: you’d get to work on the project you’d always dreamed of without taking on any of the client management hassles that freelancers usually face. You’d deal only with the project manager, do great work, get paid, and it would all be sweet.

But now you’re working round-the-clock to get the work to the client on time, despite the fact that the job bears barely any resemblance to the project you initially discussed. The scope keeps creeping, the bug alerts are coming in thick and fast, you’re three months past the original deadline, the clients are getting antsy even though they’re yet to provide you with various pieces of required information … and when (if!) you ever get finished, you’re only going to be paid what you originally estimated before work commenced (and things got out of hand).

If you’ve ever contracted for someone else, you know how hard it can be to keep a grip on the project. When you find your own freelance clients, though you must endure the client management burden, you also enjoy the benefits of controlling the relationship. But often, when freelancers contract for someone else, it becomes difficult to maintain that level of control. They find themselves in the position of "resource", rather than "respected professional", and things spiral out of control from there.

At the same time, in the unpredictable world of Web design or development, things can — and do — go wrong. And all too often, the sub-par project manager points the finger at his or her contracted staff, crying "the contractor did it!" Too frequently, contractor equals scapegoat.

The good news is: it doesn’t have to be this hard! Independent designers and developers can protect themselves from the perils of contracting … once they understand why these problems arise, and grasp the tactics required to combat them.

This article aims to explain some of the common pitfalls and identify the tactics you can take to protect yourself the next time you find yourself in the questionable position of "project resource".

First, we’ll look at the kinds of situations in which the trusting contractor can unwittingly set themselves up to be exploited. We’ll then talk solutions, showing exactly how each tactic can help you answer tough questions from your project manager or clients themselves.

The Problem
Often, contractors feel like they have little or no control over a project — as we discussed above, they feel as if they’re "just a resource". This feeling can increase in a number of circumstances — circumstances that contractors should work to avoid! Let’s take a look at them now.

Inaccurate or Nonexistent Specifications or Briefings

Often, the client and project manager want to start work as soon as possible. So you have a meeting, scope out the project in a very rough sense, and then someone asks you how long it will be before you can "get something to us".

In other cases, the project manager will go away, write up a spec — a spec that may or may not be as specific as you would ideally like — and have it signed off by the client before you’ve even had a chance to ask questions. Or perhaps you just dislike the scoping process, and, itching to get started, begin before the project has been specified in detail.

Obviously, this is a recipe for disaster. Projects need clear scoping and, though it might seem dull now, nailing down the finer details of exactly how the product inventory administration system/Latest News Calendar functionality/search facility is required to work will pay off — big — when the going gets tough.

Scope Creep

This problem is so common that it barely needs discussion, yet its prevalence in the Web industry indicates that many people — from those in big organizations right down to independent freelancers — still struggle with scope creep.

Naturally, a clear, formally agreed-upon project spec goes a very long way to solving this problem, but keeping the client on a tight reign throughout the development process is also critical. Problems can arise, though, when you’re "only the contractor" and don’t have ready access to — or sway over — the client.

Lack of Agreement on Deadlines or Unreasonable Deadlines

The client said "I want a May launch", the project manager relayed this to you, and you said, "no problem." Now you’re wondering what on earth you were thinking!

Perhaps scope creep has added months to the delivery timeframe. Perhaps you were researching the development as you went and, in the absence of a clear development plan, you now find yourself scratching through thousands of lines of sketchy code that was really only ever intended to be used for the project prototype but now com
but now comprises the body of your work. Or perhaps the client has called the project manager to tell him that "there’s a trade show in a week and we’d really like to have something to wow our prospects with — the new site would be perfect. Can we have something ready by then?" …and, like a fool, you agreed!

The root of the problem in all scenarios is expectations. It’s essential to set expectations about deliverables and timeframes up-front, before the work has started. If you don’t feel confident to provide timeframes without having done some research, it’s important to say so — and to come to an agreement as to when you’ll be able to provide a timeframe or estimate. And yes, this applies even if the project manager originally approached you saying "I need someone to build this ecommerce-enabled Website in three months — can you do it?"

Once the project is scoped, you should have room for maneuver in terms of what, specifically, is delivered when.

Failure to Pay
Ill-planned projects often lead to client dissatisfaction. It’s a rare type of project manager who is willing to forego the more basic aspects of project management (project scoping, having agreements signed off, gaining written client approval etc.) but is then able to keep the client happy while the project runs completely off the rails. It’s more likely that they will turn around and blame "the contractor" when the client starts to demand what they believe the project manager promised.

So it might occur that, even after you’ve burned all the midnight oil you have, busted your gut, and got the project to the client — late, but complete (almost!) — the client remains so irate about the way they’ve been treated that they withhold payment.

Now, if you have an appropriate agreement in place with your project manager, you might be able to convince him to pay you regardless of whether he has received payment or not. But if you have just a couple of emails discussing an estimated
price, you’ll be lucky to receive any kind of payment at all.

This actually happened to a friend of mine who was contracting for a friend of hers. And though she placed a lot of trust and faith in that friendship, and, when the client declined to pay, believed she would be remunerated regardless, unfortunately it just didn’t turn out that way. If only she’d had a suitable contract in place…

Lack of Contractual Obligation

Contracts can help ensure that you’re paid (or have valid legal recourse if you don’t get paid!), but they serve a range of other purposes.

Imagine you developed a portion of the project as discussed (but not clearly scoped!) and, after a review, the client announces that this "is not at all what we had in mind". Or perhaps they’ve just decided that the functionality is unnecessary. Who owns the code? If you’ve researched and developed the functionality from scratch, do they own the idea? Or can you apply it to some other project for which you might
get a return on the investment of time and energy you put into it?

The answer should lie in your work agreement.

The Question of Responsibilities

Perhaps when you agreed to do the work, you thought you were going to be able to hole up in your studio for weeks at a time in a creative haze, coding or designing without interruption. That would be your responsibility — the rest would lie at the feet of the project manager who hired you.

Think again. It’s this approach that leads many unsuspecting contractors down the path to sleepless nights, broken promises, unprofitable projects, and working relationships that suffer to the point at which they become unsalvageable.

It’s in this issue — the question of responsibilities –- that the solution to the contractor problem lies.

The Solution
For the freelancer acting as a contractor, the issue of responsibilities can be difficult to grasp. Who’s writing the spec: you or the project manager? Who’s setting the deadlines?
Client or project manager? Do you get a say? On which issues? Before or after those issues have been discussed by project manager and client?

We all know that, for any technical work, it’s important to identify up-front the project’s responsibilities and delegate them to appropriate parties. This is a truth, but a nebulous one.

How can the contractor ensure they never get burned? Make sure that you take responsibility for every piece of work you take on.

As this discussion has shown, it’s all too easy for the contractor to cop the blame if something goes wrong. It’s in your best interests to take complete responsibility for everything you do.

This doesn’t mean you need to take over the project manager’s responsibilities. It doesn’t mean you should bypass the project manager and deal directly with the client if this is not the work practice that has been agreed. After all, the project manager has a job to do, too.

The Role of the Project Manager
The project manager doesn’t exist solely to provide a nice, friendly buffer between you and the client. Nor can he or she take responsibility for your work.

The role of the project manager is to manage the project:

ascertain client needs

match those needs with design and development skills in an assembled project team

ensure that the project team (even if it’s a team of 1!) has everything it needs to complete the job to a high standard on-time and on-budget

In order to fulfill these responsibilities, the project manager needs your help — that’s why you were hired! He or she needs you to make informed decisions about what’s achievable. If you don’t feel informed, you need to make sure you get that information: ask the project manager. He or she wants to make sure you have what you need to do the work. If you’re missing something that you’ll need, tell the project manager!

Ultimately, the project manager wants to make the client happy. The setting of expectations
, and meeting of deadlines and deliverables, is critical to client happiness. Help the project manager to set appropriate expectations, and to keep his or her promises, by maintaining an open dialogue.

Now, if you’re getting the impression that the secret to working with your project manager is communication, you’re right. However, it’s true that the project manager’s responsibilities only go so far.

While the project manager is responsible for ensuring that the team delivers the project on-time and on-budget, it is ultimately the team that must deliver.

And, if you’re going to be held responsible, you’ll want to make sure you can stick to those deadlines and deliverables.

Therefore, before you agree to do any task — at any point in the process — you must make sure the project manager has provided you with everything you need in order to take that step. This rule of thumb applies equally to estimating timeframes as it does to developing the project itself. Ask for
whatever you need — a detailed spec, signed agreements, an agreed set of deadlines — and make sure you get it. Only then can you make reliable promises to complete portions of the work, to meet deadlines, and so on.

Contractor Protection Essentials

It’s not difficult to take the steps that will ensure you never become the failed project scapegoat. In fact, these practices should form part of your standard contracting procedure. Follow the simple essentials outlined below, and you’ll be better protected!

Always get a brief and/or clear specification up-front, before you promise, design or build anything. Have it agreed upon and signed by all parties, including the client.

This document will make it easy to identify scope creep, and to assess whether proposed additions to the scope should be added to the project (and cost estimate!) or deferred until the job’s next phase.

Conducting research and development simultaneously? Find a development framework in which
you’re confident to work, then agree with your project manager on a plan that fits the project’s development into this framework.

If you’re trying out a new approach or framework, tell the project manager, and try to build "fat" into the development schedule. Make sure you develop a plan that you feel is manageable and with which you can work.

Once you have the spec, work with the project manager and client as appropriate to identify timeframes, deliverables, responsibilities and the points at which you will invoice for work.

Put the timeframes, deliverables, responsibilities and invoicing details into an agreement, and have it signed by all parties.

At any point at which you feel as if you’re trying to second-guess someone or something, work without complete information (or the most complete information obtainable), or you simply have questions, speak with your project manager. If you have a problem,
behind, so that he or she can adjust the clients’ expectation of the deliverable.
"I’m sorry. We’re having financial difficulties right now. Can we defer this payment for a month or two?" Response: "I’m afraid that our agreement for the work stipulates that I am unable to continue with the work until this invoice is paid. Perhaps payment by installments would be easier for you?" See? The time you spent writing up that agreement at the beginning of the project has already paid off!
"The client’s not happy with the work. They’re pretty upset about all the running around, miscommunication, endless technical difficulties and last-minute hitches. They want a complete, step-by-step description of what the heck is going on!" A colleague of mine was once in a position in which this statement was made to him. He calmly opened his laptop and commenced to draw up an itemized list of every single communication issue, information delay, unreturned phone call and ignored email that had passed
, they want to know about it (really — they do!).

Keep these rules of thumb in mind as you move through the contract work, and you’ll be better able to deliver on your obligations.

Contractor Beware!
Once you’ve adopted the philosophy that you must be utterly responsible for your role as a contractor in any project, you’ll feel more confident to take steps to ensure that you can justify any decision you’ve made, or action you’ve taken, when the chips are down.

To get you in the right frame of mind, here are a few of the standard comments you might hear in your contract role (if you haven’t already heard them a thousand times). They’re comments that should start your pulse racing… and see you do whatever it takes to ensure that you’re protected.

"I like that! Can we add that functionality to this section… and this and this? And if we just alter it slightly…" Response: "Great suggestions! Those additions are beyond the scope of the current project specification,
, but would you like us to re-spec the project to include them? Of course, we’ll have to revisit the timeframes and estimate to ensure we can accommodate all the additions."
"I saw this on a competitor’s site and really think we could use it on ours…" The response here should be as above, but, if your spec already incoroporates functionality that meets the need that would be served by the client’s proposed addition, be sure to explain that and ask which solution they’d prefer.
"Where’s that deliverable? You said it would be ready five days ago!" The range of possible responses here is large, but the bottom line is that every time you alter the scope, revisit your timeline to ensure the work can be completed in the agreed timeframe, and agree on a new timeframe if required. If you have done so, you should never hear this question. Even if you have merely fallen behind due to other commitments, you should alert your project manager before the delivery date, and as soon as you fall
behind, so that he or she can adjust the clients’ expectation of the deliverable.
"I’m sorry. We’re having financial difficulties right now. Can we defer this payment for a month or two?" Response: "I’m afraid that our agreement for the work stipulates that I am unable to continue with the work until this invoice is paid. Perhaps payment by installments would be easier for you?" See? The time you spent writing up that agreement at the beginning of the project has already paid off!
"The client’s not happy with the work. They’re pretty upset about all the running around, miscommunication, endless technical difficulties and last-minute hitches. They want a complete, step-by-step description of what the heck is going on!" A colleague of mine was once in a position in which this statement was made to him. He calmly opened his laptop and commenced to draw up an itemized list of every single communication issue, information delay, unreturned phone call and ignored email that had passed
between himself, the project manager and the client… and in so doing, illustrated clearly that he had gone beyond the call of duty to make the project a success. It was instantly apparent that the issues the client had experienced had nothing to do with him. But if he hadn’t had that paper-trail (and his dedication to doing a great job) to protect himself, he’d have been in hot water.

Protect Yourself!
In the world of freelance or contract Web development, it can often seem as if you’re responsible for everything. Well, when it comes to the promises you’ve made, you are responsible. It’s critical that you do everything in your power to ensure you can deliver exactly what you’ve been contracted to provide … and that you have the appropriate documentation — and know exactly where you stand — should anything go wrong.>>