Summary

Using Atlassian JIRA and Confluence Capital City Consultants reduced the implementation costs for a CMS project by 80%. This was accomplished through the process efficiencies which JIRA and Confluence bring to project management.

Challenge

Over the past nine years Capital City Consultants has garnered a strong reputation for being a group of problem solvers. So, it was no surprise when one of our long-time clients approached us with their content management system (CMS). As it stood, our client had a custom CMS that was both written and managed by a one-man software contractor. The custom system had been designed when our client was relatively small and did not have any of the features available in modern CMS systems. In addition, there were various other issues which our client wanted us to resolve:

• Downtime due to excessive Apache rewrite rules - the web server would be unavailable
• Most modifications to the system broke other system functionality, leading to downtime
• Lack of scalability to support a larger more complicated client need
• Lack of a large company providing commercial support

Initially, our client consulted with an out-of-state, third-party implementer who specializes in web development. They soon discovered that there were hidden costs - everything from customizations, implementations, and licenses. When our client realized that the project was going to quickly exceed scope and budget, they called us in. Although Capital City Consultants does not typically deal with web development, we were confident it was a problem we could solve.

There were a myriad of problems to solve in addition to adding new functionality requested by the client. As with any project, the prevention of scope creep was a very justifiable concern. In addition to the problems mentioned above with the custom solution, the following problems were identified with the other 3rd party solution:

1. A Microsoft based system (requiring IIS) when the IT department policy excluded using IIS servers for internet exposed serveres
2. Only supported database Two dual-processor MS SQL Server licenses - one for the production system and another for the staging system
3. The proposed CMS was an expensive, closed commercial software package which would require several customizations to deliver the functionality the client required
4. High IT maintenance costs

Solution

Our project model followed our company standard: gather requirements, generate a proposal and project plan, execute the project plan and after go-live provide sustaining support.

CCC puts a very high value on properly gathering requirements prior to any work being started. While it never makes sense to 'lock down' the requirements, we consider it to be of primary importance to gather enough that no major project deviations occur. To this end we make sure that we gather and document:

1. Existing functionality
2. Hardware/OS requirements from the IT department
3. Project budget
4. New functionality

We gathered the requirements with client interviews (IT and Marketing) as well as by examining the existing solution to ensure we didn't miss capturing all existing functionality. Too often when a system is replaced the client only focuses on what they want the new system to do - neglecting to make sure they understand and capture all of the existing functionality. As we gathered the requirements we had the client prioritize them with the understanding that they wouldn't get everything they asked for with the initial release (due to cost/time constraints).

Understanding the value of the Agile development model CCC held two review meetings with the client during the week we gathered requirements. During these review meetings we were able to ensure that our solution would address all of their high priority concerns and some of their medium priority concerns. Other medium and low priority concerns were identified, discussed, and scheduled for a second project.

Based on the IT group's requirements we choose products compatible Apache, MySql and Linux, as well as limiting the products to those which had commercial support. With our architecture in place, we began evaluating different content management software. We worked closely with the client during the selection process of three finalists. Once we had three options we setup a demo of each one for the client. In the end the best CMS solution for the client was EZPublish. A versatile CMS that met each requirement.

But selecting the architecture and software solution which best matched their requirements was only the beginning. Now that we had the proper foundation we revved up our construction hats and really started to work.

First, we pulled out our trusty MS Excel and entered all of the project activities and related tasks. These ranged from work we'd already done - selecting the infrastructure, installing and demoing the candidates - to our next steps, meetings to narrow down the selection and the project launch date. Then, of course, we broke up the deliverables in to the more common Agile sprints, with each sprint deliverable tied to the related project activity and assigned resource.

Leveraging Atlassian Confluence we were able to use our custom project management console to provide our client complete and full visibility into the project. They received notifications throughout the project, but only when the notification required an actionable item for them or contained information of note which would affect the project timeline (JIRA tends to be rather chatty without changing the default notifications).

At any time the client was able to visit our Confluence pages and see a complete status of the project using our tri-level project reporting. An upper level manager report showing the different ongoing projects they have engaged us for - with each project displaying a brief description as well as a status meter identifying if the project was green, yellow or red. For Yellow and red projects the client was able to 'drill-down' into the project to the second level, the project activities. Here, for yellow or red status projects the client could easily identify what task, within what activity, was causing the problem. Finally, having the ability to drill down to the actual task they could read the developer notes and add their own thoughts/concerns/directions on the issue.

Giving the client such exposure into the inner workings of our company is to the core or how we work. We believe in strong relationships, honest feedback and a no-bullshit belief in straight-forward communication leads to the quickest and most effective solutions.

Allowing the client to frequently check in on the project plan/schedule/status through our project status Confluence pages allowed us to reduce the travel and meeting times to once a week to go over and explain all of the items in a common project status report. Now, one day a week can be quite pricey but with all of our results already in the open most meetings lasted lest than 30 minutes leaving plenty of time for any brainstorming on any of the changes/suggestions we'd come up with through our daily in-house Agile project meetings. The core result was a reduction in client face time - up to an estimated 50% reduction - while increasing the quality of communication we were able to provide.

Results

When all was said and done, Capital City Consultants was able to complete the entire CMS project for 80% less than the estimate provided by the 3rd party. We were able to perform this feat primarily because of all the process efficiencies implemented to manage the project, as well as having an excellent test group and well managed project from start to finish.

Our clients have access to their projects in the Capital City Consultants' JIRA system. By keeping them in the loop, they are quickly notified and can see/track when a task and/or project is delayed. From there, they can look into the task and see what the problem is. This collaborative effort on both our part and theirs helps to keep projects on track and moving forward. Another benefit of their access to our JIRA is task tracking- nothing is lost in email. All decisions are captured and can be found with their related issue. It also helps to cut down on the number of emails and client meetings while also improving the communication surround project status.

Typical project management solutions used when working project in JIRA is to use the concept of a JIRA 'Project' instead of just another JIRA 'issue' to manage the project. The problem with this approach is that it just doesn't scale to large organizations, especially multi-million international ones. It allows us to be much more flexible with the project processes, data tracked and project reporting. By tracking the project at a issue level we can manage multiple projects within a single group, as well as easily cross groups when needed to manage multiple cross-group projects. This approach is leading CCC to where we will be able to use JIRA to schedule and manage resources for as many simultaneous projects a client could throw at it - something completely absent, at least from a general solution standpoint, in the industry today (especially for the final pricetag we can deliver the solution for - software, hardware and configurations all inclusive).

Please contact CCC at info@capitalcityconsultants.com or via phone at 512.321.0339 to talk with one of our sales engineers about how we could help your company meet your production schedule.

Thank you for your interest in Capital City Consultants!