Questions to ask to set a digital project up for success

By nature, a project is not a known day-to-day activity; rather, it’s a piece of work that hasn’t been done before, and is often complex and full of unknowns. Thankfully, there are questions that you can consider at the start of a digital project to help give it the best chance of success. Project teams who fail to discuss questions like these have a much greater risk of running into significant trouble and ultimately delivering a disappointing or unsatisfying result.

 

1. What are the success conditions?
   
   As these success conditions are both the purpose of the project and the bedrock for the rest of the project to be built upon, it’s worth ensuring that they’re absolutely clear to everyone involved.
   
   For most medium-sized or larger projects, the success conditions are not the same as the project scope; while the project scope is the actions we have to fulfil to consider the project complete, the success conditions are why we’re undertaking the project in the first place: for example, we’re doing this project because we want to raise our online sales, or we want to reduce calls to our customer service team, or we want to showcase our fantastic new product.
   
   Imagine that the project scope is complete and the project is finished: how will you know if it has been a success and achieved what you want it to achieve? While the project scope is the ‘what’ and sometimes ‘how’ of the project, the success conditions are the ‘why’.
   
   
2. Have we validated any assumptions?
   
   If we know that a project has been planned with assumptions in mind, we should consciously consider these before starting work on the project in earnest.
   
   Ideally, any assumptions should be validated (or disproven) before we begin; for example, if we have assumed (but aren’t sure) that using tool x will allow us to do y, it would be preferable to confirm this before starting. Then we can either proceed more confidently, knowing that this won’t cause issues mid-way through project implementation, or we can adjust the project plan to shift away from the disproven assumption. Validating our assumptions in advance can save a lot of time, budget, and stress later on.
   
   If there isn’t the time or appetite to validate the assumptions involved in the project, it needs to be a conscious choice to proceed regardless: these assumptions should be clearly documented where all relevant stakeholders can view them, and the whole project team should be in agreement about what happens if an assumption is discovered to be false while the project is in flight (for example, this may trigger a meeting about how the project’s timeline and budget will be affected, and more time and budget may be required).
   
   
3. Is the scope clear, and has all of the scope been accounted for and documented?
   
   The clearer the scope is to the whole project team, the more likely it is to be delivered correctly the first time, and the lower chance for misalignments and misunderstandings. If the scope isn’t right, or if it’s missing pieces when project work starts, then it’s likely that this will be discovered mid-project and that more time and budget will be required to compensate.
   
   
• Are there any non-functional requirements?
  
  While a functional requirement could be something like, “When the customer presses a button, x happens”, non-functional requirements can be less immediately obvious or tangible things like a website’s performance, disaster recovery, capacity, or security.
  
  For example, the website may work perfectly according to the functional requirements, but if each page takes several seconds to load the stakeholders may not be pleased. Thus, a non-functional requirement for a project could be, “Each of the website’s pages load within 3 seconds”.
  
  
• Are there legal/compliance requirements?
  
  If there are any legal or compliance rules that need to be followed, it’s necessary to include these within the project scope and plan around them accordingly. While these can often be industry or location specific, it’s important to be sure. For example, requirements like GDPR (which is European) applies to Australian businesses, too, so long as those Australian businesses are processing the personal data of anyone from the European Union.
  
  
• Have we considered users outside of the ‘happy path’?
  
  The ‘happy path’ is the default or usual way that your users will navigate through a website or system. 80% - 90% of your users will generally follow this workflow, and thus this is the workflow that (reasonably) receives the most attention. However, it is still well worth considering your users who deviate from the ‘happy path’ - what happens if they click on unexpected things, encounter unusual errors, or their needs are not met by the usual workflow? Ignoring anything outside of the ‘happy path’ can create a variety of poor user experiences, negative publicity, and potentially even legal issues.
  
  
4. What are the risks?
   
   If we know what the project risks are likely to be, then we can decide whether to invest in strategies which mitigate or remove the risk, and/or develop a plan to deal with the risk if it eventuates. Many project teams like to record this in a Risks Register or similar document.
   
   
• What can we do to mitigate them?
  
  These are actions that we can take to reduce the likelihood of the risk happening, or to reduce its impact if it happens.
  
  For example, if we are undertaking a complex improvement project for an existing website and are concerned that some of our development changes may negatively impact unexpected parts of the site, then we could undertake regression testing after completing the initial development to check this.
  
  
• What do we do if they ‘come true’?
  
  What is our plan if the risks actually happen? If possible, it’s very useful for the project team to know this in advance, so that there is no confusion if/when problems occur.
  
  
5. What are the dependencies?
   
   What activities need to be completed before other activities can be started? It’s important to define these dependencies so that everyone is clear on the ‘critical path’ of activities that are needed to fulfil the project scope and deliver to timeline. Ideally, everyone should also be clear on the consequences if any of these dependencies are not completed on time.
   
   
6. What integrations do we need to account for?
   
   During digital projects, there is often integration work that needs to happen to connect your product to other systems, websites or applications (for example, to integrate a payment system). This can often be one of the trickiest and most time-consuming parts of a project, and thus it should be clearly identified and thoroughly considered in advance, particularly if you need to allow time for significant communication with, or deliverables from, the external parties who own the systems, websites or applications you need to integrate with.
   
   
7. Are the estimates realistic, and have they been double-checked?
   
   It’s vital to feel confident about a project’s estimates before proceeding with the work. Has enough thought (and research, if necessary) been put into the estimates? Has more than one person reviewed them, and ideally discussed them with the wider project team to make sure there are no misunderstandings or misalignments?
   
   If the project estimates are too low, then the project team is likely to discover that they need more time and budget part-way through the project, which can cause significant issues.
   
   
• Is there some buffer involved, based on the understood risk?
  
  Different projects, and different activities within a project, will each carry a different level of risk. Ideally, the buffer on the estimates will correspond to the level of risk. For example, if a project activity has been estimated at 4 days of work, but it’s a high risk activity with significant complexity or unknowns, we may want to bump up the estimate for that activity to 5 days. On the other hand, if it’s a medium risk activity, we may only want to add half a day of buffer, and if it’s a low risk activity that’s well understood and where little can go wrong, we may not need to allow for much buffer at all.
  
  
8. Which parts of the project are the highest priorities to complete, and what is less crucial in case the project runs out of time or budget?
   
   Having a clear collective understanding of the project’s priorities may help to ensure the project is still a success, even if it runs out of time or budget early. This is because the team can make sure that the highest priority work is completed first. If 100% of the project cannot be completed as expected, at least the most critical pieces will be done.
   
   
9. How flexible is the project - is there room for pieces of work to be adjusted or swapped out if priorities change?
   
   Some projects are more flexible than others. If circumstances, knowledge or priorities change and the project would be better in an adjusted form, is there room to accommodate that? If so, what is the process for implementing these adjustments?
   
   For example, some projects allow for unstarted pieces of work to be swapped out quite easily, provided both pieces are the same size. Alternatively, additional or changed scope may be able to be accommodated with formal approval for more budget and (where relevant) acknowledgement of the impact to the project’s timeline.
   
   
10. Are the right people involved, and have they been assigned the right roles and responsibilities?
    
    If the project team isn’t made up of people with the right skills to do the work, then the project will fail. We want to make sure that we have the right people on board, that they’ve been allocated appropriate responsibilities, and that they’re available to work on the project for an appropriate amount of time.
    
    
• Is there any work that only one specific person can do? What if that person gets sick or leaves?
  
  Having a single-person dependency on a project can be a big risk. If there’s any work that only one of your project team members can do, consider what action you would take if that person had to leave the project before completing their part of the work, or if they became otherwise unavailable. Even a temporary sickness can cause major problems for a project if a key resource is unavailable during a critical time, especially if their activities are a dependency for further work.
  
  
11. Has a single person been chosen as the project owner, and thus the final decision maker for project requirements/scope?
    
    While many stakeholders may want to provide feedback on the project’s scope and implementation, it’s important for a single person to be the ultimate decision maker. This person is often referred to as the project owner or product owner.
    
    The project team needs a single point of contact who they know will provide them with accurate information on the requirements. If there is not this single point of contact, it’s easy for the project team to receive conflicting or inaccurate information, or requirements that don’t come together cohesively. This can waste a lot of time and effort, and ultimately produce an unsatisfying result.
    
    
12. What training or change management activities may need to be done in conjunction with the project?
    
    Many projects will require some training or change management processes to accompany them. If a new system is built, but the users of that system haven’t been taught how to use it properly, then the ultimate purpose of the project could fail.
    
    Consider what people- or process-focused changes or training may need to be implemented alongside the more tangible project outputs to make sure it succeeds.
    
    
13. What needs to be done after ‘go live’ to make sure that the project is a continued success?
    
    The project launch is often just the beginning. What actions need to be taken after go-live to make sure that the project continues to be successful? This could be the monitoring of KPIs, a continuous improvement and iteration process, regular maintenance, additional staff training, customer service, or anything else that will ensure that the investment of time and money in the project continues to pay off in the long term.

In order to minimise unpleasant surprises during a digital project, it’s well worth considering these questions at the very start before project work begins in earnest. Project teams who have discussed these questions and are clear on the answers are much more likely to deliver a successful project and to have the outcome delight their stakeholders.