FAQ topic: Web development

The web applications and web sites we develop are not done in isolation. They are a result of working with you to understand you, your business, its challenges and objectives and the constraints of the budget you have available. We take time to understand your business and get to know you. This enables us to work in collaboration with you to find the best solution to suit your requirements and your business constraints.

Sometimes, this will be an off-the-shelf solution that simply requires some reconfiguration and additions to suit your needs and give you a web site that stands out from the other sites that use the same application. If this is the case, the cost will be minimal because it won't take us a lot of time and the project risks are lower.

Other sites will need bespoke development of a solution from scratch. While we work hard to keep the costs of such a project to the minimum, the budget for a bespoke build will be higher than for an off-the-shelf solution, in general.

So, the cost of developing your web site is a factor of your business challenges, objectives and constraints tied in against the proposed solution, the time it will take to build and the risks involved in the project.

Once we have spent time with you getting to know your business and your expectations, we will be able to produce a written proposal for you, detailing what we will do, roughly how long it will take and how much we expect it will cost you to do. We can then work with you to revise that proposal and agree the solution we will adopt and agree the terms of the project. At this point, we will produce a contract that sets out the various obligations, costs and the terms on which we will work together.

A Content Management System (CMS) is a web application that enables users to publish, edit, delete and otherwise maintain content displayed on a web site from within an interface designed for that purpose. Most CMS systems provide suitable procedures to manage workflow in a collaborative environment. 

In general, there are two parts to a CMS, a management application and a delivery application, which work together to manage and render web site content in accordance with the framework provided by the CMS.

Content Management Application (CMA)

The CMA is the part that a content author or administrator uses to produce, publish, edit and delete content. Most CMAs do not require the author to have extensive knowledge of web standards or languages such as HTML and CSS, as this is driven behind the CMA by the application itself. In fact, CMAs are designed and intended to ensure they can be used by people who do not necessarily have great technical skills and without the need for an expert.

Content Delivery Application (CDA)

The CDA uses the content created in the CMA and displays it on the web site in accordance with the technical and design principles applicable to the CDA. It is the Delivery Application that visitors to the web site will see when they visit a specific page of the CMS website.

 

Depending on the CMS and the particular needs of the organisation that uses it, there may be many additional features within the CMS that enables the automation of the collection and use of data and content on the web site. These features may be included in off-the-shelf plugins or modules that are specifically developed for the organisation or the CMS.

A static web site is a web site that is primarily coded using only presentational code and that offers users limited interactions with it. Presentational code includes HTML and CSS, which are the backbone languages used for presentation across the internet. By their nature, they are static: they do not offer the ability to dynamically change the data presented based on user interactions. What you see is what every user sees. In a static web site, only basic user interactions are supported, such as completing a contact form or navigating to a different page.

In a static web site, this principle is only marginally altered by the use of JavaScript as a presentational element. While JavaScript can be used to fundamentally interact with a server and present dynamic data, this is not a facility that is used within a static web site. Interaction with a static web site is limited to clicking on links to navigate to a different static page, entering information into a contact us form and otherwise basic interactions. 

In general, static web sites have become a thing of the past. These days, most web sites are some form of web application, offering users and/or the site's administrators the ability to interact dynamically with the web site to save and change the data that is presented.

A web application is a type of web site hosted on a server. While a web site generally just imparts information intended for public consumption, a web application will usually allow a certain amount of interaction by users and/or administrators. The effectiveness and value of a web application to its users depends on the level of interaction that is afforded to them.

For example, a web application may enable a certain amount of social interaction through its site, such as, Facebook™ or LinkedIn™; while a static web site will usually only link a number of pages together and offer users the ability to send the owner an email, for example. Web applications require a considerable amount of development, interaction design, testing and data management when compared to a “static” web site.

Some web applications do not appear to be applications to their visitors. This is because the interaction and management elements of the application are used by administrators to deliver the web site to visitors; these tend to be Content Management Systems, such as WordPress™ and Joomla.

Note, a “mobile app” can be a similar kind of arrangement but these tend to be web-style applications that users can download and use from their devices, interacting with a web server as required to store and retrieve data.

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.