What is our primary use case?
We've been using Enterprise One for a long time and we mainly used it largely for a lot of traditional waterfall, project management, resource management, and things like that. We were just about ready to pull the plug on them but we had a renewed effort in using it.
Over the last months or so we've re-engineered it a little so that we can hopefully get a little bit more of the agile use out of it. Being able to balance the old traditional resource management, costing, and stuff like that, with the new agile way of doing things as they were. We do have integration between Enterprise One and JIRA and we're trying to pull over as much of that information as we can from JIRA so that the people, the frontline folk, are doing their day-to-day work in JIRA and we have more of the product owners, project managers, program managers doing the high-level planning work in Enterprise One.
What is most valuable?
In terms of the most valuable features, the strategy view is something we never really did in the past. It shows us what all of our strategies are, what programs we have under those strategies, what work is happening, and what the current status of that work is. It's all at varying degrees, whether percentage complete, effort complete, hours expended, those types of things. From an overall corporate perspective, so far I've seen a high-level strategy program view into the data.
When it comes to managing project plans, Enterprise One is awesome at enabling us to see what stage work is at. I've always thought it was awesome because it's good whether we're doing a traditional WBS or we're linking in epics into projects that are supporting the programs and the strategies, I've always thought it was an excellent tool. We do want to try to capitalize a little bit more on some automation. Percent complete is the high-level metric that we're really trying to drive to. So if we have a large effort, we can see how far along in the process we are based on a high-level plan that we think is going to run from August to December, we can see where we are in the process. We can't have a plan unless we work it. And so we're struggling with that just a little bit, but from an overall status of things, I think it's great.
The Enterprise One view into resource capacity and availability does not help us to manage work because we don't know how to work it. It absolutely cuold and that is one of the things in our current use case that we're really struggling with because the pure Agile folks say, "You don't plan. You don't estimate. You just do." And management, managers, VPs, and above are saying, "Okay, what is our capacity to make all this work?" So we're struggling with that just a little bit. I think once we settle on something that Planview does give us a view into what our capacity is and how much work can we really take on.
Its ability to create summary reports across multiple projects is pretty good. Planview has invested a lot of years and a lot of money in creating a lot of out-of-the-box reports. It's just us trying to learn them again and really trying to find out what's available. We've been providing reports and information to our upper management, and our CIO said, "That's too much information." We're trying to find that balance between a one-page summary of everything going on versus providing all the details that might be needed. So overall, Planview is very good at providing whatever level of information we want.
In terms of sharing the big picture with management, this feature has really helped because there are certain strategy reports or certain work reports that do provide a one-page overview of everything. It's just that management is trying to decide what information they want to see. Then, in turn, can we from an administration perspective, modify the report enough to be able to provide that information.
It provides end-to-end work management for the full spectrum of types of work in one tool. Admittedly, when we're looking at all the different products that Planview provides, whether it be LeanKit, PPM Pro, or whatever, they do bend toward a certain type of methodology. Obviously, Enterprise One has been very traditional work and resource management focused, but I think over the years that we've been with Planview, and especially with the introduction of the Enterprise One model, they're really trying to make it to where you can have different types of projects. Whether they be traditional waterfall, Agile, Lean, SAFe, etc. Planview Enterprise One does a good job at all of that. It may not give you the capabilities of everything that you want, but that's why they've introduced these integrations with other tools like Azure DevOps, JIRA, Micro Focus, and those types of things. So that you can get that overall big picture of what's going on.
Another example of how it's been able to improve the way your organization functions is that we can now look at the strategy view to say, "Okay, what do we all have?" Because you've got this group doing something, another group doing something, and another group doing something, but overall what is everything we're doing? And as we mature in the use of the tool, not only from how much work we have out there, what can what our capacity is to do everything. But looking at the ICP portion, the investment and capacity planning portion of it to say, "Okay, we think it's going to cost us this much to do this work," but "Oh, by the way, we need to shift something around." What does that mean from mainly from the way we use it, from a capacity perspective? Because we're completely internal. We don't draw revenue directly from the internal work we do. But hopefully, we can get the benefit perspective where something may be big work, small benefits, whereas something else is small work, big benefits, and we can see where we need to re-adjust our priorities there. Overall, I think it'll help.
We're not doing direct assignments but if we were, I think it is a very flexible tool. Probably the only thing that I really struggle with is doing allocations at a certain level. And you have to do it at what they call the lowest leaf level. That's probably the only drawback I see. I'd like to be able to see allocations happen at a higher level and to where we're dealing with Epics.
In fact, I had a scenario this morning come up where we had an Epic that was created. Some allocations were put on the Epic, and when somebody tried to put a story or a task up underneath that Epic and we couldn't. And so that's the only feedback on the whole resource assignments, how I'd like to stay flexible enough to where I can go at a higher level to where I don't have to do that. A developer is going to be working on this story and we're allocating X number of hours to that particular story. I'd like to know that, I know Jane and Joe are working on a project or this work. And I think over a course of two, three sprints, months, whatever, I think they're going to be working about 75% of the time. So it is flexible, but it's not flexible.
There are pros that we're seeing from being able to draw down and see the resource demands and costs at a consolidated level. I'm a product owner and when I look at an overall endeavor and I know that I've got five Epics and 10 stories across that, from an investment perspective or a cost/benefit perspective, they say, "Okay, Epics are like features. Which feature is going to cost me more to provide?" And then hopefully I've got an idea in my brain if I'm a product owner of "Alright, this Epic is going to give us more value than then another Epic and Epic A is only going to take five story points, whereas Epic B, isn't going to give as much value is going to take us 30 story points or something like that."
What needs improvement?
I've personally been using Planview for going on 17 years now, and I think they have made some great improvements in it. I've used it both as a Resource Manager and Project Manager, and now I've been using it from an admin perspective for quite a while. I think some of the administrative aspects of it could be a little easier, especially when it comes to designing reports. The reporting coming out of it could be a little bit better.
There are some small things that are troublesome to me as far as assigning resources, setting people up, trying to configure resource structures, and stuff like that. But those are just small nibs. I think overall from a usability perspective, it's really good. It's huge. Planview's the Microsoft of project planning and PPM. There's a lot to it and people just need to take the time to learn it.
For how long have I used the solution?
I have been using Enterprise One for about 25 years. We use the latest version, Enterprise One, PPM release. We're on the continuous cloud.
What do I think about the stability of the solution?
I think the stability is great. Planview had some issues about, three or four weeks ago. But I think they've gotten over that, as far as the technical stability. It has pretty good functional stability. I think it's really good there. There's just a lot of stuff we don't know. Everybody working from home has had a big stress on internet service providers and big companies like ours are using a VPN solution. And so if I'm on VPN and I get on, try to get into Planview, there are some issues there, but overall, I think it's pretty good.
What do I think about the scalability of the solution?
From a number of users perspective, it's how many licenses you purchased from the amount of data. I'm not worried about that since we don't have it on-premise we could probably go as big as they want it to it's just until Planview says, "Hey, their cut back" or something like that.
We are looking at expanding the ICP usage specifically. I know that's integral into it and we're trying to go a little bit more enterprise maybe. That's specific to Enterprise One, but a little bit from a cross-tool perspective, we are looking at the capability and technology management offering for our enterprise architecture group. I think we're going to start looking at LeanKit.
How are customer service and technical support?
Technical support is very good if they know what's going on. The reason I say that is because we have introduced a Tasktop as the integration between JIRA and Planview. And so the support model is we have to go through Planview to get all of our support. I have found it a little difficult to get answers based on some recent questions that I've had with regards to the Tasktop Integration Tool. That's my only complaint, but I think it's fairly new, I know task integration with Tasktop is a little bit more than a year old.
I think the whole integrations team is fairly young and, they've got a lot of different tools that they have to support, but maybe the support model for Tasktop and the integrations could be a little bit better.
How was the initial setup?
The initial setup is complex but it's huge. There's a lot to configure and there's a lot to consider and when we reengaged with Planview to get us to reset back up, we spent from March to June and beyond getting things configured. I look at trying to set up Microsoft Outlook or Microsoft teams. There's a lot to it. Is it impossible? Absolutely not. But would it change my mind on going with Planview? Absolutely not.
In terms of strategy, we were trying to re-initiate and figure out how we can mix the traditional sense of what we've used Planview for in the old waterfall method, timesheets, and all that. How we can blend it into this new, Agile methodology they were using. And we still have some teams that are very Kanban-oriented work comes in where it goes out, that type of thing. So that was our strategy to how can we mold all this together and be able to get the necessary information out of the tool that we want for upper management. We have a reset goal yet.
If it was up to management, we'd have it yesterday. We're getting back into some traditional project status things like what's the current health of the project, what's the current red, yellow, green status? We're trying to financially cost things out through the financial planning details and stuff like that. Our goal at least for projects data thing is hopefully by the end of this month with hopefully some more customized reporting, hopefully by the end of October.
We brought together a good cross-functional team between our PMO, which we have five people that write five or six people on the PMO. We brought in some scrum masters and product owners. In our core team we have about 10 employees working on it from a day to day maintenance perspective. There's one that would be me from a data maintenance perspective. It's falling mainly currently on the PMO members, which is to get to three contractors. There are seven or eight of us on the PMO.
In terms of how many people use this solution, we have all of our contractors entering timesheets, so we can do timesheet reconciliation, which is about 50 or 60. The number of people that are in it week to week are around 30 or so. That's going to increase as we're trying to move our project status thing back into the program manager, product owner space as well.
We have time reporters, team member roles, program manager roles, mostly most of the users that we have set up are in the program manager role for being able to see statuses and updates statuses, we have about 10 people that are in what's called the requester role or more the executive I just need to be able to see the information. I don't need to be in the weeds entering data or anything like that.
What was our ROI?
In the past, we have seen ROI. Again, we're still trying to figure out who, where, what, why and how. And so, I think the ROI calculation may come about a year from now.
What's my experience with pricing, setup cost, and licensing?
It's kind of expensive, but I don't write the check. As long as the bosses will pay, we'll write the check. That's fine. Pricing isn't really part of my concern, per se. And again, not knowing what other solutions are out there and how they compare from a licensing perspective, I couldn't give you opinion either way.
There's the SaaS cost and there was a cost for the Tasktop Integration as well, but that's to be expected. We use JIRA and anytime we want to bolt on something new, we need to spend some money to make it happen. I don't think it's unreasonable.
What other advice do I have?
The biggest lesson I've learned is that there's a lot to it. There's a lot of information, and the big thing is trying to interpret what the information is telling us. I can look at one report one day, and the same report another day and get a different picture. It's just really understanding, especially week to week, what the numbers mean.
My advice would be to be ready to work hard, understand your needs, understand your requirements, and understand what information you want to get out of Enterprise One. So that, in working with Planview on a solution, they can tell you what information you will need to put into Planview, or the Enterprise One application to get that information. That's something I think that we didn't do very well. We thought we knew what we wanted, but then we'd get a month down the road, and we'd say, "Okay, I'm not getting this information." Planview was right to say, "You didn't ask for that information." So again, it totally goes against Agile methodologies, but you've got to really set a good base of what you want, so that you don't have to continually shift, on a week to week basis. Thankfully Planview has been very gracious to us and has reacted to our needs and our changes in requirements.
I'd rate Planview an eight out of ten. It's a really good tool, very powerful, and very robust but very complex.