One-time Jira Cloud Project Workflow Update for 2 Issue Types for a Company-managed project.

[Md Wahiduzzaman Satu]

We need assistance with updating a Jira project workflow. We have some new requirements: for a Jira cloud project, we need to update a workflow for two different work types of that project. We already did some changes, but now we feel that it's too complicated for us. For that we are looking for a Jira workflow specialists who offer fixed-price consultations for small tasks like workflow restructures. 

[Marc -Devoteam-]

Hi @Md Wahiduzzaman Satu 

Welcome to the community.

If you require consultancy, see the Atlassian Partner directory. You can find partners worldwide or close to where you are based.

https://partnerdirectory.atlassian.com/ 

[John Funk]

Hi @Md Wahiduzzaman Satu 

My approach is mostly to capture the actual process used by your organization for that thing. I don't view it as it should be optimized for the tool you are using. If you're process is complicated, then the workflow in the tool is probably going to be complicated. If you put it in the tool and you feel it is too complicated, then change your process because the tool is probably showing you that what you are doing is not the best way to handle things. 

For example, at one place I worked, we did the initial workflow and it was 21 columns wide on the board. People started complaining about Jira and how complicated it was. Then we pointed out that it was simply their existing process. They were shocked. To add to that 70% of the workflow included Approvals of some sort or another (including things like testing and QA as an approval type effort, because it really is). 

So they modified their process to reduce several approval steps, and voila! the board in Jira was much simpler. 

So, another general rule that I have about steps in the workflow. Are you reporting on that step or is the step being performed by a different person - i.e. the assignee is different from the previous status. If the answer to either of those is yes, then it is fine being there. If both answers are no, then cut it out. 

But if your workflow works, go with it. Doesn't matter if it "appears" to be complicated or not. 

[Arkadiusz Wroblewski]

Hello and Welcome @Md Wahiduzzaman Satu 

Please provide screenshots so we can understand what you have already done.

Second, there is a very important best-practice rule: keep it simple. Otherwise, it becomes a mess to maintain.

[Md Wahiduzzaman Satu]

Here are the requirements.

to clarify the financial approval process better, we split into several parts:

Budget approval: Open → Ready to order

Teamleaders to approve: after colleagues have a requirest to purchase and open a ticket

controlling to approve: vs budget; judge rationality

Management to approve: XX

DGSK management to approve: YYY

if applicable (>xxxx EUR):  CEO to approve

Order by GSM

Ready to Order → In progress

GSM confirmed starting purchasing/ purchase is arranging

In progress → Order completed

GSM finished purchasing

Payment approval: Order completed → Finance to confirm

Teamleaders to approve for payment: after delivery

Management to approve for payment

Management to approve for payment

Finance to confirm: ready for payment by cashier

Payment completed: Finance to confirm → paid

[Md Wahiduzzaman Satu]