Which methodology could make your complex Digital Projects a success?

Delivering complex digital projects for clients can be tricky. Think of the last time you hired a contractor to undertake general renovations at home: were you entirely happy when the work was delivered? Were there some misunderstandings or budget issues?

The same problems can arise with digital projects, further complexified by the abstract nature of its domain.

When a customer orders a car, one wouldn’t expect him to complain about the color or the engine’s performance upon delivery, nor would he expect to have these changed without paying for them. On the opposite, when a client orders a website, it’s not rare that he ends up asking for more animations on the home page or adding an extra field in a form. A lot of Project or Account Managers will agree with the fact that asking more budget to the client for this kind of forgotten or misunderstood features is always tricky and can create a bad client relationship.

Why are there such differences on these different sectors?

According to my experience, here are the main reasons:

• The complexity of some web projects are such that it’s really difficult for a client to think of all the possibilities of his future website or app. Complex web projects are not like cars, they are all different with an infinity of possibilities and of complex flows. The interpretation of features can also play an important role as functionalities obvious for the client might not always be as evident for the Project Manager.
• People with no technical background or who are not used to working with developers might think that changing something on a website is as easy as editing a cell in Excel and thus shouldn’t imply additional costs. Yes, changing a field in a web form could be as difficult as replacing a small piece of lego once your construction is finished.
• Clients usually receive a fixed budget for their web projects and can’t exceed it. Therefore, even a small additional cost could be a struggle to get.

To solve these frequent issues, agencies have thought of different solutions:

• Allocate a budget for unforeseen features. This can be useful even if it doesn’t prevent disagreements on the fact that a feature was foreseen or not.
• Before starting the development, ask the client to approve a deep functional or technical analysis that foresees all the different use cases and flows the website should include. This produces good results but also has significant disadvantages:

• This kind of deep analysis is long to produce and to validate and usually blocks the other teams from starting other project phases (Design, Front-end and Back-end development)
• When the client wants to make changes after approval, even minor ones, the process to include them is quite heavy especially if the development team has already started.
• It’s always difficult for a client to foresee everything in advance, especially when the market evolves quickly and needs a constant adaptation.
• Often, this kind of analysis is done once the project budget has already been approved but comes to the conclusion that new budgets need to be allocated!
• This kind of work requires a lot of time for the client at the beginning of the project whereas his help is almost useless during the development phase.
  
  This can be very tricky for the client as he can’t always adapt his own planning to the one of the agency. If he’s not fully dedicated to the project, there is a good chance that he won’t have enough time to validate the analysis in a reasonable time and that his project will be postponed to the next available slot in the Agency’s planning.

For all of these reasons, complex digital projects managed using the traditional project management methodologies have generated a lot of frustration and have shown limitations.

That certainly explains mainly why, in 2001 in Utah, 17 developers decided to produce the ‘Agile Manifesto’ that resulted in 4 core values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

To summarise briefly, managing a project using the traditional methodology could be compared to a relay race where each runner waits for the previous one to start his part and observes from a distance the rest of the race whereas the Agile methodology is more similar to a Rugby game where a pluridisciplinary team moves together progressively at the same rhythm.

Scrum, which is probably the most famous Agile method, implies a dedicated collocated team working on short iterations (called sprints) in a daily physical collaboration with the business (represented by the Product Owner). A Scrum team can be composed of internal employees but can also be provided fully or partly by a consulting agency specialised in Agile transformation and its application.

Having the Scrum development team working directly at the client’s office has a lot of advantages and can solve most problematic issues facing agencies as described above:The dedicated team is generally invoiced on a daily basis and therefore the budget is based on the time spent on the project/product and not on the functionalities. This allows to start the project very quickly and avoid endless discussions between the agency and the client on which features were foreseen or not. It follows the value “Customer collaboration over contract negotiation”. It also pushes the business to focus on the most valuable features. Instead of developing long and complex projects that could take often more than one year, the Scrum methodology encourages companies to deliver valuable products as quickly as (humanly) possible to directly experience the product on the market and quickly measure the outcomes. This way, companies are “Responding to change over following a plan.”

The client represented by the Product Owner is often seated next to the development team and is involved in most of the Scrum ceremonies and decisions. It allows him to give continuous feedback to the team and avoid having to validate long analysis. It follows the value ‘Individuals and interactionsover processes and tools’ and fosters ‘Working softwareover comprehensive documentation’.

It’s not a coincidence if Agile projects are 28% more successful than traditional projects. (Source: ClearCode) and that the Agile methodology has a 64% success rate, compared to just 49% for the waterfall mode (source Ambysoft).

Scrum is however not 100% applicable for all digital projects and clients as it requires firstly an important budget and secondly team members to be fully allocated to the project. Developing for example a showcase website for a few weeks using the whole Scrum methodology might not be adapted. However, an agency managing multiple small projects for multiple clients could still integrate some Agile principles such as having a pluridisciplinary team, holding scrum ceremonies, following a Scrumboard, etc. This is why at World Of Digits, we also have a multi-skilled team working in-house to provide web solutions for smaller projects for our clients.

To sum up, as soon as a digital project is complex enough, I would strongly recommend applying the Scrum methodology to go from a relationship of caution and tension with your clients to a collaboration based on trust and on the common desire of adding value to the final product and end-users. Such a change is of course challenging to implement. If you want to know more about applying Scrum in your company, contact our Scrum experts or get Scrum Master certified.

written by Samuel Gutmann