The key to the delivery of a good project lies in the methodology adopted by the project manager.  If the method is sound, the risks for the project are well known and thus can be properly managed.

A good PMO (project management office) will lean on either internal resources or more commonly expert, specialist consultants like Digital Rehab to provide agile project management services. The methodology however should be instigated and policed by the PMO so as to ensure consistency in project status reporting and documentation.

From over 18 years experience running hundreds of medium to large scale projects, here are some of my tips and recommendations on how best to deliver web projects (be they websites or applications).

Documentation is a critical success factor behind a good project

From the outset make sure that all relevant documents are in place.  In my opinion these documents should include:

1. business case – this document is used to legitimise the reasoning for the project and usually includes cost benefit analysis, market pressures, summary of objectives, high level scope, financials (investment required, pay-back, other factors), resource utilisation, risks, success criteria/measures etc
2. business requirements – this document is to be used to underpin all decisions around scope and functionality. It also serves to articulate a businesses objectives.
3. project plan – outlining the key milestones or phases of the project, individual “micro” work tasks, responsibilities, risk level, and dependencies.
4. project timeline – Time is one of the critical factors often in a project. Your ability to deliver to the timeline originally outlined, committed to will be one the key yardsticks used to judge the overall competency of a project manager. It therefore is critical that this be a document that breaks all work tasks down and complements what has been included in the project plan.
5. project budget – a project budget however big or small will need to be closely managed by the project coordinator/manager. I have found that a good budget should look to include the following work sheets: Project Budget Snapshot (outlining total budget or budget phasing versus actuals committed/PO’ed against remaining budget), Approved Budget (listing the phasing, budget approved), Budget versus Actuals (showing a monthly breakdown of how the approved budget is tracking against actuals, where actuals are the costs either committed to or invoiced, identify the delta or difference between budget versus actuals and contigencies)
6. risk register – this document plots all known risks that may be incurred/experienced over the course of the delivery of the project.
7. decision register – this document serves to log all key decisions that have impacted the project often including such things as decision owner, decision taken, decision date, decision consequences etc.
8. solution design – this document maps out the solution architecture for the project.  How this project fits within the broader IT landscape and architectural vision of a business.  It looks at issues including but not limited to security, access, infrastructure, integration points, database configuration, performance, scalability, re-usability etc.
9. wireframes – these are schematics for how the solution should be structured from a layout / configuration and visual standpoint.  It is at this time that your solution comes to life and can be socialised for internal / external review.
10. front and backend designs (GUI) – these are the final visuals to be used during the build to provide both a front end and back end for the solution.
11. scope specification – this is often performed by a vendor with close controls and input from internal IT. The purpose of this document is to accompany the wireframes and designs and talk at how they should be built, with what interlinkages and how they should be controlled/managed.  From this the ‘build’ or development / execution can be informed.
12. launch strategy / deployment guides – these documents should be crafted to plan out the launch of a new solution – who shall be responsible, for what, when.  It should also include a communications plan for how the new solution will be marketed / embraced / delivered to its intended audiences.  A deployment guide should always accompany the launch strategy which serves to help with IT’s ability to understand how to deploy the application/solution again in the future without the need for a vendor to again be engaged to perform the task.

Ensure project delivery methodology and milestones broadly conform with a proven approach 

I would recommend that the following delivery methodology be used:

1. DEFINE & SCOPE (occasionally referred to as ‘Initiation’)
2. SPECIFY & DESIGN (also called ‘Planning’)
3. DEVELOP (also known as ‘Execution’)
4. TEST & LAUNCH (called ‘Delivery’)
5. EVALUATE, REFINE & REFRESH
   
   

This methodology and project phasing is important so as to ensure a business/client/key stakeholders have had sufficient levels of consultation, input, controls and approval gates so as to ensure the project satisfies its intended purpose and objectives.  Breaking the project into these milestones enables the project to be thoroughly managed and for clear checkpoints to be in place to help guide work tasks.

There is ofcourse other prevailing and dominant project methodologies – referred to as ‘waterfall’ or ‘agile’ – see below:

I personally prefer a hybrid of these two rather than being a purist to any one method.

This article was written by Alisdair Blackman.