What is our primary use case?
We were doing projections. I happen to work in an IT organization for the past couple of assignments, however, at the end of the day, my background is in finance, internal controls, and business operations. We were also using the tool for forward-looking projections, to kind of get our head around where we think spending is going to be at the project level, and where there might be holes, either financially or in the need of certain kinds of human resources type kinds of things, just classic project missions.
How has it helped my organization?
Sometimes you get applications where there might only be one user, or five users, or a very, very small group. Maybe we could migrate them from a little-used application to something that we could bring to the attention that might be better suited for them. There was a variety of things, why we gathered information and collected it inside Clarity. The more important and heavier use of the tool was program management.
What is most valuable?
There was a need to keep better track of hours spent by employee type and how their times were allocated to given projects, or if not on a project, if it was just like a general administrative type kind of thing, how were we using our time. Of course, at the employee level, they would have their profiles. There were a variety of data fields that were made use of in order to identify the person by name, their skill sets, their charge-out rate, whether they were assigned full-time, or part-time, or not at all to a particular project or projects, plural. It was, of course, like a lot of things in life, it could be as simple or as complex as you want.
One of the things that we found out very quickly was when we went from kind of dabbling in program management and using Clarity, where management at the highest levels of our IT community, it was decided that this right here is our tool of choice. We're not going to be making use of any other tools. Everyone needs to make use of this project management. What they did is, they swung one way and then went to the other extreme. It was everybody who had to log their time. This was done at the highest level. Whether you were a contract employee, whether you were a full-time badged employee, whether you were part of supervisory, or management, or even a member of our senior leadership team, our executive management team, everyone had to account for their time.
There was tremendous pushback in doing this. The counterargument was, well, there's a lot of companies, high tech, defense industry, et cetera, et cetera, they always do this. This is nothing new. If we're a "high-tech" company, we should follow suit and get on board with doing this. This is actually fairly common practice. Inside of the tool, there were performance metrics, things that could be tracked, graphed, and what have you. I began distributing to my internal customers at the management level where we were relative to other family groups if you will, or sub-organizations within the IT community. Where we were relative to entering our time sheets on a weekly basis on time.
We could follow what was the quality of the input, et cetera. There were probably about five or six metrics that we used. As a result, the groups that I supported were consistently ranked at the absolute top of the organization, as we were leveraging these built-in tools for tracking.
There were some groups that were laggards or not performing very well at all. It almost became some kind of internal competition. Whether it was program management, or just metrics and entering data, or keeping records up to date, because people would go out of the organization, there were tools that were inherent or built into Clarity that we leveraged.
I'm just an analyst at heart, I can take data from disparate systems. I can correlate them and provide management with what they need in order to make decisions and affect change in the organization or what have you. I did not have any issues with the system. The whole interface would fit on the inside of the screen of a laptop computer. I wouldn't say at 100%. Let's say the screen was brought down to like 80 or 90%, the entire interface would fit on the screen. At the top of being where the true interface was, where you were able to do your filter selections, things like that, that's where you were able to, an individual, depending on their access that they've been granted. I was actually given almost administrator access, where you could see all the options that you could drill down into.
I did create custom reports. Some people had great difficulty with that. To me, it was, what data fields do you need, and dragged them into the report that you want to create and save it. That, to me, was always a very simple thing. Some people have to be spoon-fed. Other people are naturally curious or inquisitive and will look at second-level, third-level options for a given application interface. That's what I did.
What needs improvement?
Whenever that second instance of Clarity came about, it was overwhelming even to people who were accustomed to working with program management tools. There were so many data fields that could potentially be leveraged, so many kinds of internal metrics. They actually brought in an outside consulting team.
I can't recall the name of the team, and where they were from. I remember they were from down South. They were actually on-premises for a week or so. Then, they came back periodically just to fine-tune things. I interacted with them on some occasions, as they wanted to pick my brain on how I was leveraging it to track applications and to run high level reporting for management on just basic metrics and also initially on just program management.
Overall, I found the tool to be fairly straightforward. That said, for people who did want to create their own reports, whatever instance we had, a lot of people found it difficult, and what they typically ended up doing is getting training.
They're very, very smart, certainly smarter than me, where they would come to me as a resource and say, "Hey, you seem to have a knack for this tool. Can you create a report that kind of sort of does this?" I would say, "Sure." Then, I would knock it out and they would say, "Great." Then, they would have a customized report that met their needs, where they could kind of fire at will and run the report whenever they wanted it to. However, many people didn't find it as easy as I did.
Many roles that I've had was the role of a financial analyst. There's been a number of sales organizations, sales organizations that I've supported over time. These are organizations that'll have anywhere from a couple hundred to as many as almost several thousand salespeople, the people who support them, et cetera. One of the organizations that I supported was the main sales force. These are like your rank and file sales representatives who go out and just sell equipment, that sells services, et cetera. It's everything from your entry-level sales reps, all the way to your highest-performing sales reps, all the supervisory management, and all the industry VPs and sales VPs, et cetera, right up to the highest levels of the sales organization for the United States. They had a variety of almost competing tools that were used to consolidate their prospects, and with their pipelines, et cetera. Salesforce had already been installed in Europe with great success.
There, you have, obviously, different languages, you have different management styles, organizational structures, et cetera, and yet they were able to install and make use of, Salesforce quite successfully. They actually did it fairly quickly. For us, Europe included Eastern Europe, Russia, all of North Africa, and the Middle East - they all installed Salesforce and did so fairly quickly and successfully. However, there was great resistance in North America. The primary reason was that Salesforce was a cloud-based technology. There was tremendous resistance in both the Canadian and the US communities to have anything other than something that was internal inside of our firewall.
The Salesforce people were saying, "We work with governments. We work with everything from defense contractors, to military organizations, to intelligence organizations. There's nothing to fear. This is the future." Yet there was tremendous resistance. It wasn't until someone at the highest levels of the corporation said, "We’ve got Europe covered. We got developing markets covered. North America, get together and get on board with Salesforce. That way, we have unified technology worldwide." Meanwhile, I was actually taking these two competing systems, where the sales reps focused on equipment and then secondarily services, as opposed to another sales organization that would focus on services and then would periodically think about selling equipment.
There were competing philosophies and their prospects resided in two different systems. What I would do is developed a knack for taking these two data sets, exporting them out of the two systems, smashing them together, removing the overlapping or duplicate records, then being able to present to management, "You have anywhere between an $8 to $9 billion pipeline for the next nine months. Assuming that you close 20% to 25% of your deals, this is what this might be. You're in striking distance of achieving these types kinds of services, signings, or equipment signings." Management got really, really excited about this. Then, what I did after that was that became the basis, the underlying data, that smashed together data, became the data that we ultimately fed into Salesforce.
The reason why I'm giving this background is one of the things that Salesforce did that was very, very clever, is allowed just four people to take data and create a shell. What they did is they said, when they were doing the introduction to our team, they said, "There are literally hundreds and hundreds and hundreds of data fields that are used by our clients all over the globe, but what we're going to do, based upon the data set that you have in the present, we're only going to create this shell or this instance of Salesforce, and we're only going to use 75 data fields." That, to me, was very, very powerful. Even if they were data fields that were using different nomenclature, it was considered a standard naming convention that Salesforce was familiar with. As time went by, we began expanding, making use of a greater and greater quantity of data fields, and being able to slice and dice, if you will, data in greater levels of detail and complexity. It was easier for rank and file, whether you were finance, or information technology people, or salespeople, sales reps, management, whatever, everybody was able to get their heads around a tool that was becoming more and more sophisticated as the months went by as opposed to starting off with saying, "There are 300 possible data fields, and metrics, and calculations, or whatever, but we're only going to use 35 of them, or 50 of them, or whatever." The fact that everybody can see them is very, very intimidating. That was one of the reasons for the pushback in our organization when Clarity was rolled out. People could see all these data fields. Either the implementation wasn't good or the consultants that we were dealing with weren't very thoughtful. However, when people saw all the possible data fields that they had, it was overwhelming.
That was consistent feedback that I heard through a variety of channels and there was resistance due to that. If there's any feedback that I would give is that it's one thing to say, "Here are all the possibilities." However, then, when the salespeople marry up with the folks who are going to do the implementation, they need to be able to say, "So what are your immediate needs? Maybe we'll throw some additional data fields in there to kind of spice things up." Then, as time goes by, reveal additional data entry options, either for people who are making the actual entries or what have you. That's something that I observed firsthand.
I have seen interfaces that are much hipper, and much more intuitive. The layouts might have a more modern or current touch and feel. With the instance that we had, it seemed like it was just a little outdated. When you were clicking on hypertext links, as opposed to a button. Now, these are nuanced differences, however, having a menu where you'd see a header, underneath the header, you would see a blue font that was a hypertext link. Then, depending on whether you wanted to look at application data, whether you wanted to enter your time, or you wanted to look up specific projects and dig into those projects, into the sub-elements that make up all the different views within a given project, or you wanted to get to a data export function, or whatever, it was all a function of finding your overall category and then find underneath that the appropriate link.
I don't know how old that interface was. Maybe it's still like that now, or a bit more modern, however, from my experience, a more modern interface would be a bonus.
For how long have I used the solution?
I was using Clarity, I would say, from August 2018 or 2019. I was using it right up until January 2022. I would say I used it solidly for three years.
What do I think about the scalability of the solution?
At my organization, in my last couple of assignments, I worked inside IT. It's the global IT organization. Inside of that organization, there, of course, are subgroups. One of which was our program management office. There were also areas within the IT organization that tracked things other than projects. They tracked applications. For example, on a worldwide basis, we had about 1,500 applications worldwide approximately.
At its peak, I don't believe it exceeded 500 users. I don't know what the actual licensure arrangement or agreement or contract was with Broadcom CA, but what I do know is that as time went by, the number of users declined. There were trade-offs, and decisions were made. Some of the biggest complainers about doing the data entry were the most senior managers.
In time, the more like mid-level managers would say, "Well, if our bosses don't have to make their time entries, why should we? All we really care about are the worker bees." Eventually, things became more diluted.
Getting back to our ability to track applications within the corporation, to this day, it is still the official source of record for tracking the number of applications. There's a constant need to simplify our business and start making greater and greater use of better technology, et cetera. I know from that standpoint, the tool is still being used for that. They're still using it for program management, to understand and track project management costs, et cetera. That said, right now, I just don't know how many people are actually logging into the tool.
There were rumors that they were going to stop requiring people to enter their time into the tool. Unless of course, you are actually working on a project. If you're a resource that's assigned to project management, then you're obligated to track your time. For people who have nothing to do with project management, and you're just pure overhead, that's where things began kind of winding down, especially towards year-end last year. I know it's come down substantially since its peak of 500.
How are customer service and support?
I personally don't recall dealing with technical support. Very, very early on, I did, as there were questions that weren't answered internally, so I actually had to call support. I was able to get things resolved. There was some kind of a quirk, I can't recall what it was, however, it was beyond our understanding of the application. I did have to call a support number. My recollection was, that whatever it was, I was able to get it resolved.
Which solution did I use previously and why did I switch?
It's incumbent upon the information technology group to be aware of those systems, to help maintain them, to keep track of them. Then, in addition to that, to the extent that they can be eliminated, in other words, consolidated, so that we have ultimately fewer applications where more people can make use of them, it just helps simplify the business, et cetera, cut costs. We used Clarity as a tool to keep track of all the applications worldwide. There used to be a tool that was used, some other tool. I don't know if it was homegrown. It could have been a Microsoft access database for all I know. I just don't recall what it was, however, I know that it was problematic. Trying to scale up and it was problematic. They actually created a sub-element within Clarity to help the corporation keep track of all of its applications. I was actually a very heavy user of that particular element within Clarity. One of the problems was that a lot of folks didn't know just how many applications there were within the corporation. By using a variety of technology, sending out surveys, et cetera, we were able to find out that we didn't have 1,000 applications. We didn't have 1,200 applications. We actually had 1,500 applications. The reason is obvious why we would need to know whether they are maintaining internal standards or generally accepted standards relative to the IT community.
What's my experience with pricing, setup cost, and licensing?
I did not directly deal with technical support.
What other advice do I have?
I know that our company, worldwide, does business with about 300 vendors for its information technology needs, whether it's manpower, equipment, or services. Inside that list of 300 vendors, I know for a fact that Broadcom is one of the top vendors relative to our company worldwide. We're not just a customer. If you look at it from a dollar standpoint, there are some vendors that maybe we spend $20,000 a year or $100,000 a year, and not $1 million a year.
For companies where we spend hundreds of thousands of dollars a year, or multiple millions of dollars a year, Broadcom, in general, has a more elevated status on the list of vendors. It's probably in the top 30, or top 50, vendors, which, for me qualifies it as a partner.
It meets the definition of being enterprise-wide. I don't know if it was on a company server or if it was some kind of a cloud-based service that we were ascribing to. What I do know is there was an initial instance where I know for a fact it was installed on a company server somewhere and that there was a transition, maybe to a newer version, or a newer instance, which may have changed the deployment. I never really had a need to know that. All I know is can I access it and get the data that I need.
I'd recommend the solution. I didn't find any reasons why I would not want to use it. If somebody were to say, "Are you familiar with this tool in technology?" I would say, "Yes." I don't know what version or instance of it was of what I made use of, however, I would say, based on my use of the tool, my ability to look at data in the interface itself, or to get data out of it, export data to do additional manipulations and digging, or what have you, I would say, "To me, it was not difficult to use. It was straightforward. It was logical." I wouldn't have anything negative to say about it.
I'd rate the solution eight out of ten.
