The capacity planning is great. I love the ability to forecast resource usage and to work for as long a period as I want to track. That's a really big, important aspect of resource management, and, specifically for companies that have contractors in which those contractors might only be funded due to a project. If you don't have project dates in and you don't have funding, then you don't have validation for why you have a resource. It makes it so that there's some accountability there.
I love that using this tool gives you the ability to plan work out three, six, or even 12 months in advance very successfully. It gives us a real picture of what our organization really thinks it wants to do, what our organization is really doing, and then what our people are really doing, and reveals who's not working on anything.
When it comes to managing project plans, it works. I had this discussion yesterday with someone who's in more of a senior leadership position than I'm in. One of their concerns was the inability for project managers (PMs) to manage work in Microsoft Project and then sync that data to Enterprise One, and I said, "Well, then, if they're going to do managing the work in Project, they might as well manage it in Enterprise One," as MS Project only offers the PM visibility, unless it's cloud-based, which means it's hidden, not transparent. Enterprise One is transparent which makes it the perfect place to manage work and tasks.
I love the forecasting. It's a great tool. One of the things I'd say about Enterprise One that I love the most is it provides transparency. There's nothing to hide when an organization uses Enterprise One. You will find out what resource managers are really not managing resources. You will find out what resources are really not working, and then you will find out what PMs are not working and are working, and then you'll find out what work is relevant.
The functionality of Enterprise One, by default, is that if you request a resource to a resource manager for your project, if you're a PM, one of the actions you have to take is to submit the utilization and the effort required by that resource. Therefore, if I said I needed this person, and I just left it and submitted it to their manager, the manager would see you come across as a 100% request. If I already know the person is working on other projects on support, I’m not going to allow them to be 100% because I'm not giving that resource. It requires a PM to align the requirement for a resource, as an example, with what the budget forecasts. You only have resources based on budget.
The accountability piece that I like about Enterprise One is that it forces the actions that PMs are supposed to do. They are supposed to manage budget time and resources. If you just arbitrarily say, "Give me 10 resources at 100%," that's not managing the budget. That's not creating an effective timeline. That's not creating a realistic schedule of when you think proposed work can be done. It forces the PM to do a little work. It forces that resource manager to sit down and say, "Do I really know what my people are doing, and do I really want to give up this person for 50% of his time for the next eight months?" It forces those questions so that PMs actually know what their team is doing.
Enterprise One's view into resource capacity and availability help us manage work from the perspective of I see what my team should be working to, what they're assigned to, and whether or not I'm willing to give up a resource for other work, and kind of puts me in a place to prioritize planning of work. Every request for every resource and every request for every component of work that is entered in Planview Enterprise One requires someone or multiple people to ask themselves real questions of whether or not they know why they're doing it and whether they want to do it.
Enterprise One has the ability to create summary reports across multiple projects. The reporting tool is great. Out-of-the-box, it's just kind of black and white. It's a list of data. It's like an Excel spreadsheet without lines, and it's got sections. It pulls all the data from wherever you want to pull the data, depending on your access. It’s great for data, as the Planview Enterprise One database is huge. There is lots of data being captured. I love that. I love the ability to integrate with, for example, Microsoft's Power BI. When we do that we can take the wonderful data that Planview captures and formulate that into a more visual representation that people want.
The reporting enhances our ability to share the big picture with management. The amount of data that Planview captures for every item of work, whether it's a support bucket, a capacity, or an actual project in the project management world forces conversations. The old-fashioned corporate American model of work leadership, especially executive leadership, is to ask the arbitrary question, "What is the status?" and that's the worst question anyone in leadership can ask as it doesn't mean anything to me. What you're looking for is what you want to know - including the status which may not represent what another department is actually tracking. It's an irrelevant question.
For me, the right question is, "Where do we stand with the money?" or, "How do we look on our timeline?" or, "Will this functionality be delivered by X, Y, or Z?" Those are specific questions, and the tool has that data. It requires a project manager who knows the work, understands the timeline, is really managing the resources and their capacity, leveraging their time, validating the time being submitted in approval to give that picture.
It's more difficult, as it requires more accountability. It's not a simple spreadsheet that says "Oh yeah, we'll have it done by December 1st," without any data to back it up. Planview Enterprise provides data that almost forces the PM to make sure that the "We'll have it done by date," is legitimate based on resources and legitimate based on work. It's a little bit more complex due to the maturity of most organizations. It works well for organizations that have serious thoughtful PMS. It's not for an organization that really just has note-takers tracking tasks on a spreadsheet.
Enterprise One provides end-to-end work management for the full spectrum of types of work in one tool. For all types of work, I’m not 100% sure. Enterprise One captures capabilities or features, deliverables, something that you're enhancing, and then, also, due to its ability to incorporate into tools like LeanKit, you can track that actual work. It tracks traditional projects, what we know to be a start-and-stop funded thing. It tracks support work. If you really think through how you're going to design that model, you can track your day-to-day operations, break/fixes, emergencies, et cetera.
It tracks all types of work that are performed within technology. It's just how you're going to use the tool to track that work that is in question. There’s complexity. It requires an organization to actually sit down, to know what they're doing, know what work is, know what they're delivering, how they deliver it before they start building out their structure within Enterprise One.
Enterprise One helped with the prioritization of projects through alignment with strategic objectives. That’s true in my experience with Planview, however, it’s too early in my position at this new company to really gauge. They're new; they're not there yet. They're not at that universal, "Let's plan work across the board because it's all aligned to an organizational strategy" place yet. At my past organization, we were able to prioritize work just by having snapshots by portfolios of, "What work are we actually delivering? Can we deliver it all?” This forces executive leadership to make a decision and say, "Okay, this is the work I actually want," as opposed to the old-fashioned, "Get it all done because I said so." It really breaks that model, and I love that.
The solution provides a variety of types of resource assignments for assigning work to people. It allows you to reserve a person so that they have access to submit time to work items, but not necessarily have to work in those items. It assigns you the ability to allocate a resource for a specific work assignment which they will be doing. It also allows you the ability to reserve a role type based on function and role, not necessarily a named person.
In terms of the flexibility of configuring assignments, from a tool usage perspective, it's easy. It's the click of a button. From the person clicking the button, the perspective of that user, the complexity comes into play in terms of whether or not you can understand the definition between what is a requirement, what is a reservation, what is an allocation, and you can memorize that and remember that every day, and know where to click a button. other than that, it’s simple.
The flexibility allows us to plan ahead for work that we aren't sure is going to be fully funded or not. We can plan a type of resource without actually knowing who would potentially do the work, which allows us to forecast a resource. The forecasting model gives us the ability to say, "Will our team that's presently in use be able to fulfill that prioritized work, or do we have to begin a process of obtaining additional headcount?"
The solution allows program managers to group work together and see resource demands and costs at a consolidated level. For example, at one of the other companies that I've worked in, they had the mindset of, "Our organization keeps our work, and you don't need to see what we're doing, and I don't need to see what you're doing." However, with this mindset, they're going to run into the constraint of, "Oh no, you need someone from my team to help you deliver that work, and now we need open visibility." This product impacts the mindset and the model of, "Who owns work? What is collaboration? Do we still remain in silos? Or is the organization the main objective?" If delivering work for the organization is the main objective, Planview delivers due to the fact that it's transparent and open to everyone.
We are mostly able to drill down into details underlying the consolidated information using Enterprise One. As an example, you can have a work item called Cool Project. With it, you can see when it's supposed to start and when it's proposed to finish. You can see the resources allocated to it. In there, you can see work items, like features or deliverables, epochs, or milestones. You can see that in a Gantt chart. You can see the start and stop dates for all of that. Planview does have the ability to let you actually see the tasks, or what Enterprise One calls the action items, for every one of those. That may not necessarily answer the bigger picture, as there's always going to be that human component that has to speak to the work, which is why a lot of teams use secondary tools, like CA's Rally tool, or Planview's new LeanKit tool, or Jira, to really give the full picture of what each individual respective work item is. Therefore, while it does give us a visual, it may not speak fully to it without the help of a secondary app.
Enterprise One has not increased our on-time completion rate. The reason is due to the fact that Enterprise One leverages true resource ability and capability as far as effort and available effort. If you leverage the tool that way, and you keep governance that reflects that, you’ll be better off. As an example, my contractors are not legally allowed to work past 40 hours, so I forecast them that way. I can see if somebody's over. I need to deal with that, due to contracts. That said, if you track outside of Enterprise One, there are organizations that may say "Hey, you're a contractor. I need you to finish the work. Sorry. You'll be doing 50 hours.” It's on a spreadsheet and no one sees it.
The ability to scale Enterprise One is great as you can integrate with tools like Power BI and then tools like Planview's LeanKit. Therefore, I consider that scalability to be great. We're building a working model right now.
We have executive leaders using Enterprise One. Overall users might be close to 4,000. I say that as that's how many users are in IT, and this is presently an IT tool for timesheet reporting. It's a pretty significant footprint, and the roles range from executive viewers, executives who just want to see reports, senior leadership, senior management, management, project managers, program managers, timesheet reporters, contractors, and then finance people who just need read-only rights to be able to see stuff. There are quite a bit of different roles that are using it.
The solution is being used daily by up to, plus or minus, 4,000 people. The organization is using it right now as it's an IT tool, however, there are other organizations that are not IT including HR, training, accounting, and other business units within the organization that are already seeing the value to it from a project management perspective. That footprint can grow and we may increase usage.
There are conversations within the company with others that want to use it, and that would turn the IT team, who owns it, into trainers for building out new administrative groups and coaching. There's just no one yet who has actually been implementing it as we're all new to the product.
I was not part of either implementation of a product instance of Enterprise One for either of the two organizations that I've worked in.
However, I can say that, with both of them, I have heard after-the-fact statements such as "We should have considered this. We should have considered that." Both organizations did not know the full scope. As an example, one of the organizations I have worked with didn't want to track at a strategic level. They wanted to track at team levels due to the traditional silos surrounding work. However, now that they're getting a taste of the tool, understanding that there is cross-collaboration, they want to manage at a program level. That said, you can't manage at the program level without using the strategy functionality within Enterprise One. When you get into strategy, it's no longer siloed work. It's organizational work. That it requires planning.
We have approximately 20 people that are classified as Planview admins, and some of those are global admins. Global admins include probably five or fewer personnel. Planview admins are probably 25 or less, and those all function together as a team. It is a collaborative effort to maintain the solution. To administrator Planview properly requires a representative from every organization and/or department that will use it to act as a liaison/admin/coach. That rolls up to a global administrative group which is about 25 people at least.
Most of the maintenance is governance. It's not maintenance for the application. It's maintenance for usage, roles, access, that type of stuff. From the application perspective, the maintenance is low. Once it's implemented, it's global, it's across the board, and it's in use. That said, there is administration for governance, usage, visibility, rights, minimal rights, and that type of stuff.
I'd advise those considering the solution that it requires planning. If there was some CEO or senior IT leader that said, "Hey, we're thinking of using it," this is where I would go. I would say: You need to understand what is the work that you deliver. You need to understand how all of that work that you deliver rolls up into organizational goals and vision. You need to understand that and understand what type of work you deliver, being able to compartmentalize your work into either support work, operational work, or actual project or program work, or intake work for requests, or emergency break/fix-type work. You have to be able to quantify the type of work you deliver before you use a tool like this, and then understand the hierarchy of work so it can be prioritized across the organization before you implement it, and then understand what are the roles of people, like people who submit time, what is a project manager, what is a resource manager.
In IT, a resource manager is basically the engineer who can do more tickets but can't deal with people. Planview actually does the reverse. You are managing people more than you're delivering work, and that's a big, big pain point for a lot of organizations. Those things would have to be considered. Really ask those types of questions and get examples before implementing.
One of the reasons why I love Enterprise One so much is due to the fact that, when I first started using it in 2014, when I was given the role to help administrators, there was an assumption that this tool was too complex. The company was struggling and fighting to use it. I interviewed people, including probably 30 managers, every week for several months. These were just generalized questions to help build a method for helping them use the tool, and coaching them to actually start using it. The universal answer was, "We have a lot of work. We're extremely busy, but I don't know what we're doing." Planview gives that visibility, and answers the question "What are we actually doing?" and then that leads to the, "Why are we actually doing it?" And that's extremely helpful.
I'd rate the solution at a ten out of ten.
