Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” That’s certainly not what you want out of your MuleSoft implementation! If you work with AVIO you can expect a clear vision of the end goal, a solid team and robust communication plan.
While a smooth project is always our goal, let’s be real. Surprises will surface. However we have a well thought out process for setting you up for success. It starts with the kick-off.
Before I start telling you all about the kick-off, let me emphasize a few details.
- This is not a technical blog post. Rather, it’s for anyone preparing to manage a MuleSoft implementation and looking for guidance on how to begin. If you’re curious about how AVIO approaches an implementation, then it’s for you as well.
- Soft skills make a difference. Respect, collaboration, communication, organization to name a few. I can go into great technical and functional detail about a successful MuleSoft implementation, but if you don’t pair it with soft skills, you could still be putting your implementation and your team morale at risk. At a tough point in one of my first projects as a Client Advisor, my architect said, “We’re a team. We win as a team or we lose as a team.” Because of that team mindset, we were able to maximize the use of each person’s skill set and create a really fun culture throughout the project. In summary, don’t forget to treat each other with respect and focus on a shared goal, Your project will be better for it.
- Guiding principle: This process is meant to help, not hinder you. If it makes sense to add or remove steps, go for it! Just do it thoughtfully. Keep in mind the goal is a successful implementation not following the process to perfection.
Let’s start with the outcome
So what should you expect at the end of the kick-off? Here’s a basic list. I’ll cover the process of getting there next.
- Shared expectations for project goals
- Clear communication strategy and meeting cadence in place. As a Client Advisor “no surprises” is my goal. The client should always have a clear picture of what’s happening with the project. Putting some structure around communication is essential. The following list is typical for most projects.
- RAID log for gathering risks, action items, issues and decisions
- Daily standups
- Estimation sessions (for the whole development team)
- Backlog Refinement / Prioritization
- Sprint planning
- Design sessions / Requirements gathering for future use cases
- Overall design validation including documentation such as sequence and architecture diagrams.
- A task management platform like Jira or Azure DevOps with 1 to 2 sprints of development work ready to go.
- Definition of Ready - Document the expectations for when a piece of work is ready for development. This is a great time to emphasize the need for success criteria and requirements in the user stories.
- Definition of Done - What is the team’s expectation for considering a piece of work “done”? Has it been reviewed? Is it unit tested, integration tested and QA tested? It’s a good idea to discuss this, write it down and make it accessible to the entire team.
- Time invested in building relationships and getting to know each other - This might be my favorite part of project work. Getting to know people in-person or virtually through routine meetings plus a few minutes of random conversation thrown in may not sound important, but it creates a more efficient team when it comes to resolving issues, clarifying requirements or addressing changes in scope. It also makes the project a lot more fun!
Now, how do you arrive at the outcome? It starts with the sales cycle. The delivery team needs a clear picture of client expectations from the sales cycle.
- Why are they investing in MuleSoft and getting help from a trusted partner?
- What are they hoping to achieve?
- Who are the key players?
As a Client Advisor, I find it’s invaluable to start collecting information and building relationships during the sales cycle. Honestly, I think successful implementations and happy clients are more likely when the sales and delivery teams work together. At AVIO, that’s standard practice.
Now comes the fun part: the Project Kick-off! I like to send my clients a proposed schedule about a week or two in advance. This gives them time to make any necessary arrangements and ensure the right people are invited and we’ve sorted through any scheduling issues. More importantly, I want them to be part of the planning process. Once again, “no surprises” is my goal. Here’s a peek at a typical one-week kick-off.
Day 1 - Overviews and Technical Topics
- In order to get everyone in the right frame of mind for kick-off, we start with lots of overviews! Ideally these are brief. The idea is to paint the picture of why everyone is working together.
- Kick-off overview - Go over the schedule and make sure everyone knows when and if they’re expected to attend meetings. When are breaks scheduled? When does the day end? Can they interrupt with questions and who’s taking notes? In other words, play the host and make your guests feel welcome.
- Project overview - Allow the client to spend a few minutes explaining their reasons for investing in MuleSoft and the pain it could address; What’s the big deal? Why did they invest all that time and money? What do they hope to gain during the implementation? Maybe mentoring is important to them? This is the time to confirm expectations when the whole team is there to hear them.
- MuleSoft overview - Allow some time to hear from your MuleSoft AE and CSM. They can review the details of your purchase and explain their role when it comes to support and contributing to your success.
- Use case overview - This is one of my favorite parts of day 1. I like to hear the client explain (in normal, non-technical language) what they hope to tackle using MuleSoft. Like the other overviews, this is intended to be brief. Deep dives come later.
After overviews, it’s time for an initial assessment of technical readiness. To say this includes lots of technical content would be a drastic understatement. It’s a little like drinking from a fire hose, but it’s necessary to understand the current state and start targeting areas for improvement. This is when we talk through monitoring and alerting, the CI/CD process, error handling and logging to name a few. By the way, if you read the 3rd blog in this series about project wrap-up, you’ll notice we circle back to technical readiness again.
Days 2 - 5 - Use Case deep dive
- After getting the overviews and technical landscape out of the way on Day1, It’s time for a deep dive into the primary use cases. You might wonder, “Which use cases are the best candidates for getting started?” Well, that depends. Thinking of them on a risk / reward spectrum helps. Here’s a list of attributes to consider when selecting the use cases best suited to your implementation.
- Provides the most value (ROI, financial reasons)
- Clear requirements and data mappings
- Quick win for bolstering organizational buy-in from stakeholders
- High potential for reuse
- Necessary for compliance / regulatory reasons
- Addresses one or more pain points
- New process or implementation (never been done before)
- High profile company initiative
Assuming you’ve selected 1-3 use cases for the implementation, then it’s time to dig deep. What’s the problem? What’s the desired outcome? Is there some sample data? Which systems and tables are part of the process? Who is the subject matter expert and do they have any data mappings? How does the use case translate to system, process and experience layers? Are there any internal deadlines?
If you’re sensing the need for documentation, you are correct! All the design specs need to end up in some sort of project wiki. Confluence or a Google Drive work well, but there are other options. The main goal is to capture the information.
Now you should be ready to begin development. If not, don’t make the mistake of starting anyway! Take one more week if necessary to sort through design obstacles, access issues, reconcile with your API strategy, and any other roadblocks to development. But don’t delay too long. It’s impossible to avoid issues once development begins. So it’s a balancing act of taking the time to prepare but getting started quickly. A good Client Advisor will collaborate with you to make the best decision for your project. At AVIO we like to think big, start small and move fast. We believe that’s the best use of our client’s investment in us and MuleSoft.
Next we’ll talk about development and testing: the lengthy middle ground between the project kick-off and project wrap-up.