There are several project management processes acceptable for use on web development projects. These include “Waterfall” methodologies, PRINCE2 and “Agile” workflows. Here is our take on some of these solutions and our experience of working with them. These thoughts are generalised, so not set in concrete and not true of every project of its type.
Waterfall
Waterfall project management is generally used in construction projects and historically has been used in the ‘construction’ of web sites in the past. The process requires defined stages of development with set procedural gates between each stage. A project is unable to proceed to the next stage until the gate has been passed, requiring agreement of the developer and the client. Generally, the stages involved include: Definition, Design, Construction, Completion and Close out.
Unfortunately, a waterfall process has never really been suitable for web development projects because it requires a clearly specified and well-understood definition before a successful project can start. In construction, you would have a set of architect's drawings and blueprints. In web development, you have a set of needs, challenges and expectations that need to be fulfilled... usually they are not well defined or specified!
Waterfall tends to slow down the completion of a project because we have to work towards each gate in turn and our concerns are focused entirely on making sure that we are ready to get through the gate at the appropriate moment, rather than focusing on what you have asked us to solve.
Indeed, waterfall projects tend to result in solutions that satisfy only the specified aims and objectives as set out at the start of the project. Anything that crops up during the project tends to be either neglected or bolted–on as an additional cost. As a result, waterfall projects usually end up costing the client significantly more money and tend not to solve the real problem that the client wanted, resulting in disappointment and project failure in the long–term.
PRINCE2
PRINCE2 is a heavily structured project management framework suited to large projects in medium– to large–sized organisations. There is a much stronger emphasis on process and on organisational structure within a PRINCE2 project. PRINCE2 is not a very flexible project management process and requires a significant amount of reporting and role–reporting within the project structure.
Like Waterfall, in PRINCE2, there are a set of specifications and requirements set out at the start of the project, which must be completed by the end of the project. Equally, there are a set of stages and approvals that need to be completed along the way. The difference is that PRINCE2 expects a project to define its approach through planning documentation, logs, reports, registers and lists. In many circumstances, this can result in the project becoming bogged down in committee meetings, approval processes and reporting rather than to responding to changing business needs, changing environment, updated user expectations and infrastructure specifications.
As a result of the additional burden of bureaucracy, reporting and documentation, often PRINCE2 is not considered suitable for smaller scale web development projects and are often cited as the main reasons for such projects failing.
Agile
Agile is a relative new–comer to the project management spectrum and was first discovered in the undergrowth of some software development projects. Because it grew out of software development, the transition to other “soft” projects like web development is fairly easy and it has in place many of the concepts that are important to these kinds of projects where Waterfall and PRINCE2 don’t.
Unlike PRINCE2, Agile is designed as a process to emphasise project execution over explicit management of the project itself: rather than talking about how to manage a project, it describes what the project will do and focuses on actually doing it.
In an Agile environment, there is an acceptance that requirements and specifications may, or even are likely, to change during the course of the project. This is because the client isn’t sure what they need to specify at the start of the project, or indeed how to specify heavily technical requirements; and the developer isn’t entirely clear on how to deliver often very soft specifications and requirements. As a result, Agile expects there to be a close collaboration between clients, stakeholders, users and developers who work as a team (at key moments during a project) to ensure that the project is ultimately successful.
The Agile concept is very different from PRINCE2 and Waterfall; if you are used to the latter types of project management, it can be a challenge getting used to Agile. In essence, Agile focusses on continuous planning, commitment, execution and review to deliver a set of “Products” or requirements at the end of each Sprint (a short project stage that is used to deliver key elements of a project). The project has a list of requirements (Products) to be delivered and during each Sprint the stakeholders agree which will be delivered and how they will be accepted. At the end of the Sprint, there is a demonstration of the Products to be accepted and an update of the list of requirements.
Agile projects require robust, disciplined mechanisms of process control, including constant feedback loops and continuous project improvement as essential management techniques. The project planning, requirement specification, governance, development, implementation, reporting and acceptance are built into the process throughout the project. It engenders transparency and brings decision–making and management to a participative level. Decisions are made on project operational certainties, rather than on predictions based on schedules and Gantt charts that are usually out–of–date and ineffectual.
Our process
At Redcentaur, we can work with each of these project management processes. However, the use of PRINCE2 or Waterfall adds a significant amount of additional resource to a project as a result of the need to report, specify, track and approve that these processes require. As a result, the cost of the project will rise significantly if these are used.
Our preference is to work with our clients to ensure that the project we deliver meets their needs, rather than a pre–defined set of specifications that may, or more likely will not, meet your needs at the end of the project. An Agile environment tends to offer the ability to work together in flexible way to meet the challenges of the project and deliver a product that is fit for purpose.