5 tips to guarantee a successful delivery to your project support team

• the load. How many colleagues will there be to have a bit of your cake?

• the choices you have to make. Will you bring one cake, or several? What flavor(s)

• delivery. Is the kitchen table available? Is there sufficient space? Can everyone access it easily?

• security. Is the cake safe for everyone to eat? Have you taken gluten or lactose intolerances into account?

• testing and measuring. How many colleagues are in the office the days before your birthday? Is the kitchen table large enough to support the cake(s)?

• knowledge transfer. How will you let your colleagues know you’ve brought cake?

If you’ve taken everything into account, your project should be ready for launch. You’re happy, and hopefully your customer is too. Process finished.

However, when you’re launching a project, the go live is only part of the delivery process. Once your project is live, you’ll have to support it. That means handing over the project to your support team and that… may be difficult at times. In this blog post, we give you 5 tips on how to prepare for a successful go live and hand over your project to your support team. Minimal amounts of stress and lowest organizational impact guaranteed. 😎

1. Good agreements make good friends

In contrast with what people might think, the preparation for delivering a project to your support team starts in the very first meeting. It’s a good idea to invite the entire project team for this kickoff meeting. For some team members attendance is required, such as the business owner, financial sponsor, product owner, project manager, customer proxy, architect/lead developer, Devops lead and the support lead. Others are welcome, such as the development team, testers, … as long as the group is still manageable and the total amount of attendees does not interfere with the focus of the meeting.

During this meeting, you’ll want to address 5 important topics:

1. Introduce the team. A solid introduction takes away the hesitation and stress at the beginning of a meeting. Act as if it’s the first time you meet. Play a little game, or try to introduce the person next to you.
2. Set the scene. Create a frame on which everybody agrees. This may sound as a simple step, but by agreeing on some basic principles, you facilitate communication and transparency, which leads to trust.
3. Define your governance. Who is responsible for what? What’s the communication flow? What’s the escalation path? What are the response times? Who needs to be informed about what?
4. Mitigate risks. Think about the disaster scenarios. Don’t refrain from expressing your fears and concerns! Defining possible risks in the beginning of the project keeps everybody alert and creates a shared responsibility.
5. Define a timeline. When does the team expect to do what? Agree on high level deadlines, but make ’em strict.

As it’s the beginning of the project, not all questions should or can be answered in detail and nothing is written in stone. But by capturing the above information and drafting a project charter, you have a guideline you can use throughout the project. Save this project charter somewhere where it’s accessible for all attendees. Make sure you update this document when new information is at hand and share the new version with the attendees of the meeting. So what does this have to do with a successful delivery to your support team? You might have noticed the required attendance of the support lead for the kickoff meeting. By involving the support lead from the beginning and keeping them up to date during the project, the support team is able to

• designe SLAs and support agreements,
• free up resources in time, for support during the go live, but also fo the necessary support activities afterwards, and give insights during the project which can have an effect on support tasks.

2. As solid as a rock and as flexible as chewing-gum

It’s good practice to gather performance acceptance criteria for an application before the start of the project. These requirements can influence the architecture of the system as well as the choices regarding specific technology. However, it’s not always easy to define realistic and measurable requirements. Your predicaments will often be based on assumptions or even wishes. Luckily, there are some tips and tricks to aid you in defining realistic requirements. Looking at historical data of similar applications is already a great help. Turning your estimations into measurable requirements is necessary to be able to test and adapt during the project. Use performance tests to keep an eye on the performance goals during the development of the system and eventually assess production readiness, but also to

• test the stability of the system,
• facilitate the tuning of individual components,
• plan the required system capacity,
  
  
• and discover the scalability limits of the system.

Why is this so important for your support team? A stable and performant environment causes less problems once the project is in production. The right measurements and a good monitoring make sure that the few problems that do pop up, are alerted to the support team before they become a problem for the end user. Finally, a flexible architecture allows the support team to scale the environment instantly.

3. Divide and conquer

While testing software is hard, solving problems or bugs is often even harder. It’s a well-known fact that the complexity of a software bug increases almost exponentially with the time it takes to discover the bug. So it’s key to identify bugs in an as early as possible stage. But how? Easy: very short feedback loops.

Before a developer’s code is merged with the rest, a business/functional analyst goes over the delivered functionality. You’d be surprised how quickly a fresh pair of eyes can identify flaws in the software. Once the code is checked in, the continuous delivery process kicks in. This process ensures that a test environment is deployed with the latest version of the software every single day for a tester to validate. In this step, not only the small piece of work that was added is tested, but also the interactions of this piece with what was already added before.

Each of these quality gates is an opportunity to discover software flaws in an early stage, even before they get to the acceptance testers. In an iterative development process (e.g. sprints of 2-3 weeks), bugs that happen to slip through are identified within the span of a sprint. The functionality that produced the bug is still fresh in the developer’s memory, ensuring an effective and efficient solution that can be retested as soon as it’s (continuously) delivered back on the test environment. The acceptance criteria of a story (a small and independent piece of functionality) also serve as input for the test documentation for that functionality, including the support engineers that have to deliver support for the product.

4. Develop every line of code as if it’s a piece of art

Not only does writing top quality code bring pride in your work and great satisfaction for yourself, but also it has some considerable long-term advantages. The exercise of translating a difficult feature to quality code means you have to think through the functional aspects of this feature. This means you’ll probably think of some alternative or exceptional flows you maybe would have forgotten about otherwise. You’ll also find bugs faster and more easily. In the long run, spending more time thinking about what you code will actually save you a lot of time.

Code that reads like the brush strokes of the Mona Lisa is a pleasure to work with. You and your support team will have to read through your project’s code base a lot! It’s best to make this an enjoyable experience, reducing the number of WTF’s and increasing the amount of smiles on everyone’s faces. Not having to wade through tedious unreadable spaghetti code also means that people who have to go through your code will be able to focus on the problem at hand. Bugs are easier to find and fix, hot fixes are simpler to add. Performing these support tasks won’t make the code an even bigger mess, as quality code is flexible and adding onto the existing codebase will feel like a walk in the park. Not sure how to start? Robert C. Martin’s book Clean Code is definitely a great guideline to writing superb code.

In short and perhaps obviously: the less bugs your project contains, the less effort your support team will have to invest in supporting the project. Then again, we all know a 100% bug-free application is like a golden unicorn. Thats why we still need to invest in a solid knowledge transfer to the support team, which brings us to the next point.

5. Strive for the best, but prepare for the worst

When do you start explaining the ins and outs of the project to the support team? If you have to assemble all information at the end of the project, for sure you’ll miss out on some important ‘special cases’ you tackled at the beginning of the project. Of course, these special cases were covered somewhere in a story… or was it a bug, raised in a story that indicated that the system reacted strange to real world data, which triggered a new story? 🤔

If you build your knowledge base from the very start of the project, together with the code base, the knowledge transfer to the support team is a walk in the park. Make the documentation part of the development and validation proces. By doing this, not only is it built piece by piece, but it’s also validated and kept up to date with every next functionality that is built. Every stakeholder of the project benefits from the knowledge base during the entire project. But every stakeholder is also responsible for keeping it up to date. From analysts over developers to testers, they all use the information and, if necessary, update or complete it. Even the support team has to join this exercise. Imagine you can start an extension of an old project and the support team has kept the documentation up to date in the same way that the project team did during the initial development. How much easier would it be to get started on the new scope?

Additionally, make sure that your documentation is process oriented. The details of certain functionalities can be found in the stories or the code, whereas the processes can guide you to the correct stories to look for information. And no, you don’t have to write entire books. You just have to make sure that your documentation has enough context for you to be able to pick it up within a year from now and still know what it’s about. If you write more, you run the risk of it becoming outdated and inaccurate. And let’s face it: wrong documentation is even worse than no documentation.

It’s important to clarify in an early stage which process you’ll follow, which SLAs you agreed on and what the expectations are for all parties. If you start drafting these ‘rules’ and expectations during development, you can already test them during the user test phases. No doubt the users will come up with a bunch of questions, issues and bugs (according to them) that are not to be taken into account during the acceptance phase. Handling those requests in a similar way as during the support phase smoothens the support process. It also makes life easier for the support team, since the users are already custom to the ‘rules’.

🚀 Takeaway

To wrap up, here are our 5 tips for a successful delivery to your project team condensed in just 5 lines:

1. Involve the support team from the very start of the project.
   
2. Define realistic performance requirements.
3. Keep feedback loops short.
4. Make sure your code’s quality is top notch.
5. Build your knowledge base from day one.

We hope these tips will help you out. As always, if you have any questions or would like to share some additional insights, don’t hesitate to contact us!