Web projects can be their own animals sometimes. Their own process. Customers tends to come at them differently, the urgency can be different – sometimes much greater with a shorter timeframe expectation than a typical enterprise application development or implementation project. The projects can range from simple corporate websites to mission-critical intranet applications or, in the case of an Internet startup, the project can be the product itself. And, of course, there are always the me-too requests – “I want it to look like ‘x’ site or be the next big ‘y’ site.”.
So I’m often asked… do we do anything different – from a project management standpoint – for Web development projects over, say, an enterprise CRM implementation? Do we plan differently, do we manage the project a different way, do we engage the customer differently? The answers should be “no,” “no,” and “no.”
First let’s review what best practices for project management really are. There can be many different interpretations and versions of what best practices are – it can often mean something different to each organization, to each PMO director, to each Web developer, to each customer. But there are some core practices or thought processes… or perhaps actions… that are critical for successful project management. And yes, these are relevant to Web development projects as well – the amount of effort we spend on each of these and the detail that goes in will often depend more on the budget and the customer than the type of industry or type of development that is being performed. I’m sure there can be hundreds of items on this list, but these are my basic six…
Start with a formal kick-off
This can be a 15 minute meeting or a two-day event. I’ve done both. But formally choose a kickoff point and use that event to review the statement of work with the project client, set expectations, confirm milestones, and set the tone for how the engagement will be run and managed.
Conduct regular status checks
No matter how crazy the project is during any given week or how slow it is moving at the moment, make time to have regularly scheduled status checks with the stakeholders – at least weekly – and keep the documentation up to date. During a crunch time that may need to be daily. If you start to skip it, then skipping it can become habitual and eventually you’ll run into some satisfaction or frustration issues with your project client.
Manage the project with a project schedule
Even for small projects, put together a schedule and use it to drive the weekly status calls with the customer. Keep it up to date and review accomplishments, the current status of live tasks, upcoming tasks and who’s assigned to what and use it to manage risks. The schedule can be a traditional waterfall approach using MS Project or a more Agile, fluid approach using user stories and a planning tool like Pivotal Tracker … or a mix of both.
Monitor the budget closely
A 10% budget overrun is easier to correct than a 50% overrun. That’s common sense, of course, but if you’re on top of the project budget every week and revising the forecast then you’ll likely never hit that 50%…you’ll take corrective action at the 10% mark.
Pay attention to testing
User acceptance testing (UAT) is necessary and it should involve the customer as far as possible in order to avoid any bias testing on your part. But customers are often ill prepared for UAT – be ready to ‘train’ them on how to test the product… facilitate wherever possible.
Provide post deployment support
Finally, make sure you provide some post deployment support. Don’t just deploy and move on. You never know when they’re going to come back for more work or to whom they might be referring you. This point of the project is where you can sometimes win back a customer who was previously frustrated during earlier parts of the engagement.