Planview Enterprise One Review

Robust in terms of flexibility but they should make a little more headway into how agile delivery works

What is our primary use case?

We not only use Planview for resource allocation but also for tracking financials towards the projects that we have set up. We also have financials and resource allocation and we also use the project planning piece of it.

How has it helped my organization?

We use Planview quite a bit to articulate and tell the story around where we're at, whether a project's at risk, whether it is on track, whether or not we need to either extend the timeline or add additional resources.

What is most valuable?

I just took it over about four or five months ago, as part of my responsibilities. But from what I can tell it's pretty robust in terms of flexibility.

It maps back to our SDLC process pretty well. I'm able to see the stage of where things are at. We also use Azure DevOps for all of our requirements and our coding. 

The work is in Azure DevOps but the planning aspect of that work, the financials, and the resource allocation are done through Planview. I'm trying to figure out how to connect the dots. Meaning, if I have a project where I've burned through 50% of my financials, and I've done all my resource allocation inside of Azure DevOps, I'm able to visualize and see the data that says, "Hey, I'm 50% through the development work of the project. I have this work that I currently have in flight, and I have this much planned for the remaining amount of time, which represents the remaining 50%." And then I want to see how that then maps to Planview. Because Planview could say, "Hey, you know what, we burned through 80% of our money." How do I then use the data coming out of Azure DevOps to then either go ask for more money and more funding or to do something to make decisions?

Resource capacity helps me to ensure that I have the individuals needed to complete the work. We basically go in at a high level. We know we have a project and we know we might need around 500 hours of a cloud engineer. And so we'll go out, we'll make the request, and the allocation is done for it. Then you have a person that's allocated for those 500 hours. The only thing I don't have is when they've burned through those 500 hours, I understand that they're burning it against the project, but I don't know how to tick and tie that to the features that they burning it against. 

It provides end-to-end work management for the full spectrum of the types of work. From a project view, I'm able to see where things are at by the financials, the allocation of resources, as well as the lifecycle of the project.

It also provides a variety of types of resources assignments for assigning work to people. It's pretty flexible. We could set up a variety of different rules within Planview across organizations. Each team sometimes has different roles that they need to pull in for the project or for the team. And so having the flexibility of adding roles is good.

Another thing that it has helped us with is our burn rate of dollars, more than anything else. We're able to look at things and say, "If we're coming towards the end of this year, we know our burn rates higher than it should be." And we can look at certain projects and say, "Let's remove certain work streams that we don't want to work on."

What needs improvement?

As more and more organizations are adopting agile as a framework of how to deliver work, they should build in some flexibility within Planview of connecting the work to the teams.

For example, right now the old waterfall methodology of planning was to say "Hey, I need an allocation of a resource." Normally with other tools I've seen, it's if I need an allocation of 18, I know Planview has that. We, unfortunately, made some modifications, we didn't go that route, we're on fast forward. That is an example where I think Planview has done that. 

When you think of planning at a PI level, roadmap planning, or release planning, I think they should make a little more headway into how agile delivery works, tying it back into the financials and the planning to Planview. I think it would be good.

For how long have I used the solution?

We have been using Enterprise One for four to five years. 

What do I think about the stability of the solution?

The stability is good. I have not seen a lag time and we haven't been down when I've had to use it.

What do I think about the scalability of the solution?

The scalability is good. We have 20 to 25 project managers that use Planview, a couple of team leaders, and then we do our time cards in Planview, so really the entire organization uses it, at least in IT, so it's probably around 400 to 600 people.

I would like to see us use it more. When we use Planview I would like to use it at senior level leadership planning where we can see forecasted spend, my allocation for the budget, my resources, and all of those things. I want to be able to tie that to detail work that's in Azure DevOps.

How was the initial setup?

The initial setup went smoothly. It was straightforward. I don't think we had a whole lot of tickets.

We do a lot of upgrades. It's usually overnight and it doesn't take long. We had a major reconfiguration about two months ago and it went pretty smoothly.

From our side, I think we had about four or five analysts involved.

For the management, we have two people that help support and manage Planview.

What about the implementation team?

We only worked with Planview, not third-party integrators. 

What other advice do I have?

It's pretty easy to use. It's not that difficult.

I would rate Enterprise One a seven out of ten. 

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More Planview Enterprise One reviews from users
...who work at a Financial Services Firm
...who compared it with Microsoft Project Server
Add a Comment