This is how to approach a digital project effectively

By basic services, we mean the recurring, structural services that are part of the core of your organization, such as implementing existing internal systems or renewing existing digital tools.

This means that a digital project could, for example, be a new software system, online document management, a collaboration environment, a new (corporate) website, or an administrative system (planning system, accounting system, etc.).

For a digital project as part of your basic services, you can clearly describe in advance the outcome you aim for and the impact the project will have on the organization.

Something new, that did not previously exist, and that needs to be conceived, designed, and developed from scratch (so not just something that needs improvement). Examples include games, tangible technology for public engagement, an app or augmented reality, or working with new applications of AI.

An innovation project often starts with many assumptions and uncertainties due to the 'new' aspect. The process also differs from a project for basic services: with innovation projects, the exact desired outcome is often not yet fully known.

In the exploration phase, you gather information, map out the target audience and requirements, try to refine the problem definition, and explore potential solutions. Much of this has already been done in the project canvas and briefing, so primarily exploring potential solutions is relevant.

You do this through, for example, research, interviews, brainstorming sessions, and analyzing existing solutions.

During this phase, concepts are worked out, and initial versions are built. Together with the tech partner, you look at functionalities and structure. You do this by, for example, creating wireframes, drafting technical designs, and building prototypes.

During the testing phase, you gather feedback from your future users. You identify problems and areas for improvement and validate assumptions. You do this through, for example, user tests, A/B tests, feedback sessions, and technical tests.

During this phase, you actually put the product into use. People are trained to use it. Note: this seems like the final phase, but in practice, you will often still deal with tweaks (adjustments) and bugs (‘errors’). You do this through, for example, launching the software, providing manuals and training, performing iterations and interventions, and offering support.

When you’re done, you’re not actually done. You will always find that things need to be changed because, for example, needs change or technology evolves. Built systems also need to be regularly updated, optimized for even better functionalities, and maintained. Include this in your budget.

With the Waterfall method, several phases are completed one by one (linear). This means step by step, in one direction. Hence the name Waterfall method; because a waterfall flows downward. This means that each phase thoroughly and exhaustively inventories and elaborates on all requirements. Only then can you move on to the next step. This also means that the product is only available at the end when it is completely finished, and never in partial products.

In a static world, this works excellently. The Waterfall method is therefore best used in environments that do not or hardly change: you determine your goal very well at the beginning and then pursue it very specifically and efficiently. However, in (digital) practice, this often doesn’t work this way.

With the Waterfall method, you have to make project-oriented estimates at the start. In a changing environment, this method carries the risk that the original scope no longer aligns; market, customers, desires, etc., may change while you were developing.

Simply put, during a digital project, you often realize that things need to be done differently. This is where ‘iterative working’ fits: constantly checking whether something needs to be adjusted or improved.

Iterative, or agile (in English) working, emerged from the need to respond better and faster to the changing market and changing needs and desires. Agile literally means agility, flexibility. When working with the agile methodology, you acknowledge that circumstances change. The methodology accommodates this and encourages testing partial solutions. No large master plan that is executed step by step, but smaller projects that build towards a large goal, the contours of which were only agreed upon at the start. When working iteratively/agile, you often work in small ‘sprints’ or rounds; this is called the scrum method.

When working agile, several aspects are central:

• The world around us changes, so environmental factors affecting our product also change
• The wishes of stakeholders will change during the course of a project
• To respond well to changes, you continuously check whether the work you are doing for the coming period is still the most valuable work
• To check frequently, you also release (partial) products more often
• During development, testing, checking what works and what doesn’t, and incorporating new insights immediately are central.

Hybrid is a combination of more traditional forms like waterfall combined with agile: both a fixed linear process and ‘moving parts’ and short spurts.

In our experience, a hybrid work method works well for most digital projects in the cultural sector. Some things can indeed be predicted and provide structure, while other parts focus on flexibility and incorporating new insights. This way, you can remain ‘agile’ during the project while also working realistically within the organizational structures that often exist in cultural organizations.

Source: Agile VS Waterfall (opens in new tab)

Within agile and hybrid working, the scrum method is often used.

Simply put, scrum is:

• Create a list of what needs to be built
• Decide what you will do during this period (the sprint)
• Meet daily and collaborate
• Show what you have created at the end
• Think about how to improve in the next scrum round
• And start again at point 1
  

Source: Agile VS Waterfall (opens in new tab)

The MoSCoW method was already discussed: Must have, Should have, Could have, Won’t have (for now). When preparing your budget for the project, the Must haves (essential) and Should haves (highly desirable) naturally take precedence. These are placed at the top. The Could haves (nice but not necessary) depend on both budget and priority. The Won’t haves are things that are not a priority now and are left aside. These are important ingredients for determining what must be minimally included in your digital project (MVP: minimal viable product). But what else needs to be determined?

The budget determination is then dependent on the following important things.

• Core functionalities
• Design needs
• Platforms
• Integrations (system linking)
• Is content creation needed? (and who does it: internally or externally?)
• Development and maintenance

Additionally, there are some questions you need to discuss with your technical partner/external agency:

• Are we working with a fixed price? Or is it determined per step?
• Which roles need to be fulfilled (explained in the chapter: Assemble your project team), what are the required hours, and what are the costs? (note: internal hours must also be calculated, and external hours are often expensive)
• Are we opting for custom work (and to what extent) or not?
• Are there licenses that need to be paid?
• What are the costs for hosting, support, updates, and development after launch? (and other long-term costs?)

NOTE: there are always unforeseen costs. These usually range between 10% and 30%. A realistic estimate is usually 20% on top of the total budget.

In addition to the budget for developing your digital project, it is also important to allocate budget for maintenance and development. This is sometimes forgotten — projects are often seen as end products, whereas they are only partially so because the world doesn’t stand still. The end product is therefore not the end product.

For successful development of your project, it is important to allocate sufficient time and budget for technical maintenance and for new insights.

Often, this is higher than you might expect initially; discuss this early with your technical partner.

A good rule of thumb is to allocate at least 20% of the initial budget annually for the following years. For example, with a project budget of 25,000 euros, this means an annual budget of 5,000 euros. The exact amount strongly depends on which products you have set up and the knowledge you hire and already have. It is especially important to discuss what your team can do itself and what you need the technical partner for; this greatly influences the budget.

The calculation you ultimately get based on all input:

Hours per role x hourly rate.
License and/or tool costs
=
Budget

+
Risk/buffer (20% of budget)
Development and maintenance (20% of budget)
=
Total budget for digital project development

NOTE: development and maintenance are calculated with this calculation for one year. Each year, an additional 20% of the original budget amount you initially calculated is added!

Determines the direction and priorities within the project and monitors the goals and content. Internal or external: preferably internal, sometimes both.

Ensures that the process runs smoothly in agile projects and removes any obstacles during the process. Internal or external: can be both, but is usually external, depending on the agreements made.

Designs the digital product and is responsible for the visual design. Internal or external: usually external.

Builds the technical solution. Internal or external: external.

Provides text and images (sometimes these roles are divided, or there is a coordinator who manages this). Internal or external: usually internal, in any case, needs to be checked internally.

Checks the functionalities, quality, and usability of the digital product. Internal or external: both, usually in small internal teams.

Once your digital project is live, it’s important that colleagues know where to go with questions. Not just for technical support but also about the new way of working. Ensure a clear point of contact or team that answers these types of questions. Think of: internal colleagues for answering functional questions and an external helpdesk for technical questions. The most important thing is that people know who to contact with which question. IT systems can support this but are merely a tool; the core is a clear organizational structure for support.

TIP: put a list of FAQs (frequently asked questions) online that answers common questions and clearly indicates who to contact with which question if you can’t figure it out.

There are different ways to gather feedback from users. Consider what suits your organization best and look at the size of the group you want feedback from.

A small group?

The smaller the group, the better it is to do this orally in a meeting. Prepare your questions in advance. To ensure everyone has a chance to speak, you can use a mentimeter (www.mentimeter.com).

A large group?

If the group is large, you can use an online survey and/or deploy key users or ambassadors: these are delegated colleagues who collect feedback from others.

Technical management involves the daily functioning of your digital product. Things like monitoring, performance tracking, security updates, and bug fixes. With proper technical management, your digital product remains stable, secure, and reliable. It’s an essential part of progress. Technical management can be handled internally, provided the necessary knowledge is available. You can also outsource it to the supplier; in that case, make clear agreements for a longer period. Either way, you will always need to manage, maintain, and adapt the system technically.

An innovation working group focuses on future developments. It identifies opportunities, collects ideas, and evaluates whether new functionalities are interesting. This group also experiments to explore whether technological developments can meet changing user needs. An innovation working group can be internal, external, or a hybrid of both, which tends to be the most successful combination.

Knowledge building ensures that information about the product is sustainably documented and shared, preventing it from becoming fragmented. Think of documentation, training materials, best practices, and lessons learned. This prevents essential knowledge from being concentrated with a small number of people, making teams more agile and onboarding easier. This knowledge is built both externally and internally, but ensure that it is also shared and preserved internally.