Apologies if this sounds like an agonising 'which tool' question. It is not meant to be.

I have a client who has a global license for a tool called Workfront. They are setting up a new PMO to run primarily digital projects, carried out by scrum teams using JIRA (for the product development). My task is to evaluate Workfront for suitability. I have spent some time looking at reviews on g2crowd.com, and softwareadvice.com to gather data, and as expected (perhaps the same for any tool) there are some potentially serious problems which could arise. Some of the comments are pretty terrifying if applied to a large scale digital program.

I am absolutely not a fan of adopting a tool just "because we already have a license". My view is that JIRA and Confluence serve the information management, tasks management, and collaborative needs of a scrum team and PMO effectively, and if the PMO wants robust and mature tool for planning then MS Project is solid if you don't try to be too clever. From what I can tell, Workfront needs yet another tool 'guru' to be about for when people get stuck, to help decipher the admin UI and let people get back to productive work.

If Workfront cannot work reliably alongside JIRA it will not be recommended. Any wisdom on offer? Thanks in advance :)

2 Answers 2


The only real advice I can give is to back up your position with both facts and rhetoric.

The facts part is simple. Just make sure you document everything - all those comments you've found? Copy them down. Furthermore, it's unclear from your question, but I got the impression that you haven't actually tried Workfront yourself. You'll need to fix that. While you won't be able to test it for scalability or expert-usage scenarios, at the very least you cannot give an authoritative opinion on a product you have never actually used. And, as always, document all your findings.

Regarding the rhetoric part (which is unfortunately in many business cultures far more important than facts), you'll just have to make sure your speaking/persuasive skills are up to snuff. If they're not, then the best advice I could give is to practice. Once you've got your presentation 'ready', actually give it to someone (co-worker, friend, family...) and have them critique you. Then improve and try again. A truly great presentation shouldn't even need (much) understanding of the domain in order for the persuasiveness to shine through.

  • Thanks for this. The recommendation made is that the client will need to trial the product with their own team in the right context - i.e. with JIRA to assess its suitability. I have not put forward a recommendation but have highlighted the risks associated with simply mandating a tool outside of a trial with their own teams, in real-world contexts. There is a higher priority right now to get them to adopt a collaborative agile work management tool such as JIRA, plus a decent information / doc management tool, such as Confluence. Jun 16, 2017 at 6:39

Workfront is primarily considered to be a portfolio management tool. It is used by upper management to get an overview of projects in process. Although there are project management features built into it, normal procedure would be to continue to manage the projects, themselves, in Jira, and maintaining just enough information to provide a meaningful overview in Workfront.

If you find yourself doing double-documentation, you are overworking the Workfront end. Instead, think of Workfront as providing a way for you to help your management look at your project in context with other projects. It substitutes for a certain amount (but not all) status reporting and updating.

We are getting Workfront (which will dovetail with Jira) in my current company. In a previous company, I used Clarity in concert with MS Project. Same principle.

This isn't all bad. Over time, how you use Jira, and the information that portfolio managers need/want in order to best make decisions, will both evolve. It's a good place to allow the PM or SM to make decisions and customize what needs to be represented in Workflow and how. More generally, think of how differently individual scrum teams run (the same work done at similarly consistent velocity might use entirely different story points; user stories might reflect very different teams, etc.), and then consider the need for a way to inform management of how work is progressing without giving up the ability to continue to allow your team to self-organize productively. This can be a major sanity enhancer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.