The problems with JIRA

I speak with many Atlassian users as an Atlassian Expert. 

I hear many users telling me they have the same problem with their JIRA installation:  the managers can't figure out from the tickets when the project will be done.

Organisations, when they have an out of the box JIRA installation that has been up and running for a year or 2, come to realise JIRA is not helping them predict release dates. Some organisations at this stage, choose to do a deep dive in-house to rework their JIRA installation. Other organisations hire an Atlassian Partners (such as Venduco) to reassess their installation.  Partners have reworked many JIRA installations and work faster,  than an in-house team doing this for the first time. Partners also bring experience and perspective from other similar rework projects.

So how exactly should one diagnose and then rework JIRA installations?

Here's the process I have evolved:

First I carry out a Discovery phase ( I do this as  fixed cost ) to determine how the current JIRA installation works for your organisation, find your pain points, and what reports (metrics) you want to help predict completion dates. I also review the  technical details of your installation. I interview key personnel.Then I  generate a list of actions that you can carry  out to refit your installation so it meets your needs. You, as client,  prioritise this list according to cost and benefit estimates.Then we create a rollout  and validation plan. We choose between a big bang or incremental rollout.  Use test instances to experiment with changes.Implement changes from the list, validating with users as we go.Just before the rollout, I run training for all the users. Training is  an excellent time to receive final feedback from users so tweaks can be done before going live.Go live,  and of course - test to confirm they work!Run a "lessons learned" session.

The list of actions of course depends on the organisation.

These actions seems to get on every one of my lists:

Create a glossary so all different types of user agree what words mean, such as names of custom fields, project, priority, done, etcSpecify examples to be used for team "thought experiments" before implementing.Determine the principles that govern architecture decisionsDetermine who in your organisation is the JIRA system "architect" and makes the final decisions.Create a JIRA architecture that is simple enough to draw on the whiteboard. Simplify. Simplify. Simplify.Define the workflow cadences and feedback loopsDefine  feedback loops.Define the reports (KPIs, metrics) you want to get out.

So if your JIRA has a problem, yes, it can be fixed. The process is straightforward. And the result is a JIRA instance that gives you consistent, continually improving project status