h1

Lessons learned: Self-project management

17 October, 2009

Got back last night after my fourth and final week working in Sydney. It’s been interesting, my first full-time private sector gig in over 7 years and at a different level than the $22k junior web application developer role I had at Catalyst Interactive where I last worked in private sector before joining the APS.

Brought back memories, especially as the client in this case and the sort of work was similar to one of the projects I had back in 2001 – pixel-perfect designs, cross-browser compatibility etc.

I’ve learned a lot from the past few weeks; important things that will help me kick off my new freelancing career – and I want to record them and share them here. I should note that my advice below should not be taken to indicate that the project I’ve just completed suffered all these problems – but it did at the very least inspire me to think about these issues and solutions:

Project ramp-up and initialisation:

Be wary of projects that have no clear baselined documentation and specifications! It is likely that new documentation, new requirements or changes will reveal themselves over the duration of the project and without a firm foundation to estimate and work from it will make life difficult. Obtain baselined documentation and commit to work from that. If new requirements are revealed that supersede that baseline, then stop, analyse the discrepancies, re-evaluate your time and resource estimates and escalate. Don’t just absorb it into your current timeframe and work plan.

Demand a proper project briefing and initialisation, at least a kick-off meeting with everyone involved at a low level. Know who you’ll be working with and engage with them, build a good work relationship with them as soon as possible. State your expectations of them and let them reveal their expectations of you.

To “hit the ground running” does not mean you should forfeit this opportunity. Even if you’re dropped in the middle of a current project, your work is still a project in its own right.

Project management and methodology:

Do not assume that the absence of a process and methodology implies that people do not expect it. Methodologies are used for a reason – for predictability, for risk management, for reporting, for planning, for resource allocation and issue response. You need these requirements to be accommodated, so having no process at all will not do.

At the very least identify the phases of your work and disclose those to the client. Allow yourself an adequate analysis and evaluation phase, a design phase, development, testing and deployment or whatever phase framework suits the work you’re doing. Even an agile methodology has phases. Just bumbling your way through it as fast as you can without any plan is not agile. It’s a disaster.

Estimates:

Never provide an estimate for just the main component of your task. Just as you have a ramp-up and ramp-down for your project, each task will have other activities wrapped around it. If you quote for just the main part of a task then you’re locking yourself in to do all of the work associated with that task in a greatly reduced timeframe. Don’t expect project managers or clients to pad out your estimate for you.

Don’t commit to others’ estimates. Never say “yes” to an estimate – always give your own, in your own words with any caveats and assumptions, and yes I know to assume is described as being the “mother of all fuck-ups” but assumptions are an important part of project management – you can’t have all the facts and you have to draw the line somewhere. If those assumptions fail, your estimates fail. If you haven’t stated your assumptions and made it clear that you can complete task by X date but only as long as Y and Z remain true … and then if Y and Z fall through, then you fucked up.

If working for a fixed period of time that was set before you started then you are being hired to work for that fixed period of time, not to complete a deliverable. Make that clear. If you haven’t been given the opportunity to properly evaluate the work, to assess the environment and the relationships, the allocated resources, attitudes, other influencing factors and are being engaged on someone else’s estimates and assumptions and being commited to complete deliverables then you’re walking into a trap. You might have to just do that … but know the risk; if their estimates are off, if there are no baselined requirements, if resources change, if there’s no project management methodology then you’re lining yourself up for a nice stroll through the fires of hell.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: