415.701.1110
Confluence
Case Study – CustomWare Asia Pacific
- Headquarters
- Sydney, Australia, with offices in Melbourne, Singapore & Malaysia
- Industry
- Software development, consulting, and integration services
- # of employees
- 50
- # of JIRA projects
- 150
- # of JIRA issues
- 18,000
- # of Confluence users
- 43 employees and 100 customers
- # of Confluence spaces
- 200
A conversation with Rob Castaneda, founder
CustomWare Asia Pacific designs, builds, and supports integrated business systems and portal solutions for multinational companies such as Johnson & Johnson, Sony & Corporate Express. The company not only customises JIRA and Confluence to build and support industrial-grade online systems for its clients, but also runs its own business using Atlassian software.
Let's start at the beginning. Why did you start using JIRA and Confluence in the first place?
We started off as a small software company providing integration solutions. As we worked more with organisations subject to strict government regulations, we needed to keep a clear and accurate record of what we were doing. We adopted JIRA as our project management and issue tracking backbone, so when a customer asks, 'What exactly have you done and how have you done it?', we have the answers. We also wanted a faster way to bring people up to speed on a project. JIRA really shortens ramp-up time.
We chose Confluence because we needed a knowledge base that wasn't just another way to manage Word documents. It gives us the flexibility to add in bits of information as we get them and massage them later to create the official documentation that we need. We became involved with Confluence and started providing it to our customers at a very early stage, which was somewhat of a risk because very few of them even knew what a wiki was. That hurdle was quickly overcome, and we're very glad we went down that track.
And you use them together to run your business?
Yes. Given that we are a company that offers services, our goal is to keep our knowledge in a central system. Every key process area has its own JIRA project. And for every project running in JIRA, there is a corresponding Confluence space for all related information. This gives us a consistent view and repository of information for each process or project.
- "We win deals and a lot of repeat business because of how we use Atlassian software." Rob Castaneda, Founder
How do you typically use Confluence with customers?
It's not easy to show customers a wiki and get them to start using it because most of them still "live" in Microsoft Office. So we present Confluence as a document management tool. We create custom Confluence spaces for each client, which they view as Web pages where they can upload their Word documents and look at the information we've generated for them. Some clients are more technologically savvy, so they take advantage of more Confluence features.
How do you adapt Confluence for each client?
Every client has a different way of doing things. One of our pharmaceutical clients needs to comply with FDA regulations and other pharmaceutical industry standards, so they want all of their information in a particular format. Other clients might use a rational unified process and need documentation in that format. The biggest benefit of our wiki-based approach is that we're able to store information how we want to store it and then create a high-level graphical representation of how the customer wants to see it. This allows us to maintain consistency internally while creating individual client environments.
How do you use Confluence internally for daily business?
We use it to communicate asynchronously, especially about projects. We have staff at different sites, and they all have internal blogs that are basically free-form status reports. They write what they did today and what they're going to do tomorrow. It's not the kind of information you'd get from a more formal report, but more FYIs on things like, 'This issue was a major headache today because...' or 'I worked out a really cool way to test pages using x software," or "I'll be in the Sydney office tomorrow." You'd be surprised how much cross-pollination this generates between consultants. We use it in our recruiting process as well. Each candidate has a Web page where we put our interview comments.
Let's talk about customer support. I understand you have a unique approach?
Support is a key part of what we provide to our customers. We believe that most project methodologies leave this out – they only include the process from the time the client agrees to pay for something until it goes live, then you walk out the door. Our mentality is that a project really requires support from day one.
Support is especially critical for our customers since we develop systems that run their organizations. A bug can't wait a couple of weeks to fix. We have to react quickly and transparently. At the same time, when we're working with large companies we need to make sure all regulatory requirements are met, which is where JIRA comes in.
How exactly do you use JIRA and Confluence in your support process?
We use JIRA for issue and source code management and an associated Confluence space for each project as the configuration database repository. If a support request comes into JIRA for the project, we don't run a separate JIRA instance. It's the same project, just a different issue. We cross-link and balance the systems so that JIRA tracks the reason for the change and Confluence holds the documentation about the change and how it affects the system. Links from issues in JIRA let us search Confluence to see if someone's already documented a procedure for that particular support issue. One of our goals is to measure the percentage of support requests that can be answered this way.
We can also draw solutions out of JIRA into standalone documents in Confluence. It gives the client a great deal of comfort that they can search the repository and see the body of information growing. This is a very good differentiator for us against our competitors.
All this process discipline can be perceived as more work. How did your employees take to it?
It can be perceived that way, and you run the risk of developing a policing culture, so we always make sure we can answer the question 'what's in it for me?' from everybody's perspective. When a senior consultant sees that there's a centralized place to do things and a rich repository of information, the benefits quickly become clear. From a developer's perspective, we're reducing the barriers to entering information in JIRA and providing feedback about how valuable their input is.
How have customers responded?
From the customer's perspective, we think we've hit it right on the head. They love what they see. Just as an example, one really cool thing we do is create a blog that says, 'ready for release' or 'ready for deployment' every time we complete a version or a tag. We can then link up an RSS feed from the blog in the project space to the customer's portal that ticks away announcing the new developments. For the guy in charge of IT, this means we're not only his development team, but part of his marketing team as well. He loves it because he's getting free marketing for his group. It's a win for us because we provide extra services - marketing and infrastructure - with very little overhead.
Any examples of measurable benefits with customers?
We don't put a dollar figure on it, but we win deals and a lot of repeat business because of how we use Atlassian software. It gives us a competitive edge because we customize it. We are not just contractors. We are a full-fledged outsource partner that provides an entire infrastructure for a corporate IT department. We can provide all the SLA metrics and other measures a COO needs with these tools.
Governance and methodology also play a big part in our presentations. We were working alongside a large consulting company, and they had a team twice as large as ours. They ran their project management off Excel and we made them look bad compared to our integrated infrastructure using Confluence and JIRA! Again, providing infrastructure rather than just being a body shop is a big benefit.
And with CustomWare's internal business?
From a company perspective, the benefits are huge in terms of the time we're not wasting on rubbish. Before we started using Confluence, there were a lot of trivial questions being asked and answered by phone or email. 'What's the password for this?' 'Where is that located?' 'How do I do this?' Now we spend our time growing our knowledge base. We're also reducing our dependency on any one individual and protecting against things like someone's machine crashing and losing everything in email. (Later, Rob added, "I remember walking into Atlassian last year when development was underway for 1.4 and suggesting that it would be really cool if Confluence could read email, so that's how that feature came about.")
Another major benefit is that ramp up and ramp down is much shorter than in a traditional environment. It doesn't take a week for someone to get up to speed and work out what they've got to do, which is critical for a company that has to constantly move people around between projects. For example, every project has a key. With the key, our developers can instantly find out how to set up their development environments, how to get source code, where to read the documentation, and what the issues are.
From an employee perspective, the best feature (again, 'What's in it for me?') is if I'm on a project that I don't like, the more I document what I'm doing, put my issues in, make it transparent what I'm up to, the easier I can get out of here. This is how we avoid consultant locking. As a testimony to that, we had a lead project architect leave just as a new phase of the project started. We were given our requirements late, and the client actually moved up the deadline. A new leader was able to come in and deliver. We couldn't have done that without this software.
How do you expect your use of JIRA and Confluence to evolve?
I see a big push from our customers in the IT governance space. Non-technical users don't necessarily understand how to structure a space. A wiki on its own can be too flexible. Customers need pre-defined schema and a form. For example, we have a three-click rule that says if you can't find what you're looking for in three clicks, the information needs to be moved. That's the abstract layer that we provide. Going forward, we want to be able to show customers our system and then help them organize their own projects the same way. That way, we gain a long-standing customer by providing infrastructure and keeping it up-to-date.