DEV Community

Discussion on: 5 Key Takeaways from my First Freelance Project

Collapse
 
taikedz profile image
Tai Kedzierski

Spot on. This is advice I've given many times on the back of my own experience even in corporate inter-team environments where the "customer" is "another team."

It is vital to make sure you define the scope of the project/task, and its deliverables, and clearly point out any new requiremetns later on that are not within scope. Not only can you keep to the stated scope, but if new things come in - especially through factors outside your control - you negotiate accordingly. The brief time I went into contracting, this is something that really bit me, and even today in corporate settings I have to keep it in mind. Where "dollar" is the important factor for contractors, "ability to deliver other features" is what is negotiated within corporations.

In our environment, I put emphasis on

  • Acceptance criteria (when the project's requirements as stated are effectively satisfied)
  • Definition of Done (what meta-requirements are needed for scope to be completed, e.g. documentation, handovers, presentations, etc)
  • Scope of responsibility (what specifically would fall outside of the scope of the project, and what ultimately may yet be considered within-scope)

Also, sometimes things that affect the initial premises/assumptions of your project may fall within scope, calling on your adaptability. It happens - but your time (or other dependencies/projects) is still subject to the base rule: it's extra, negotiate the way forward. Don't be a super-hero by tanking the effort. If you said "it will take X days" and a new requirement pushes that out, re-negotiate the duration - and the pay.

Set the scope, and do not stunt your other projects just because others have new, unforseen requirements. They are under pressure, and so are you. Set scope, negotiate, and set expectations.

Collapse
 
itsnitinr profile image
Nitin Ranganath

Prefect!