Enterprise-wide GRC made more powerful *and* simple with our new list fields!

By now, you likely are aware that policyIQ is a flexible GRC platform that can be easily configured and customized into various GRC and other solutions. One of policyIQ’s strengths is the ability to tailor security at a broad and granular level allowing organizations to implement policyIQ in many areas without stepping on each other’s toes, so to speak. Because of this security capability, with our user-based pricing (rather than the common software model of pushing multiple products or add-on modules), our clients have long been able to leverage policyIQ throughout the organization for multiple initiatives at a reasonable cost.

The latest release of policyIQ includes features that support robust enterprise-wide applications of policyIQ for a range of initiatives. In the past, users in different areas of the organization would create a folder, manual, dropdown or multi-select list to track different critical pieces of information pertinent for their documentation. And while this setup could have been perfect for the audit team’s testing documentation, the same location list, for example, would have to be recreated by the technical accountants performing ASC 606 contract reviews. That was then. Clients leveraging policyIQ’s version 7.8 are able to create and manage Global Lists that can be shared across the organization. If your list of Field Offices is leveraged in various types of content throughout the organization, it can now be centrally maintained and updated rather than having to be updated in several department-specific templates.

Similarly, clients historically had to create independent dropdown fields to track people or responsibilities in their content (i.e. Control Owners, testers, contract reviewers). Now, the lists of users created under Groups and Users and established as a part of user profiles can be leveraged as fields within templates. Once and done.

Here are more examples of where this might be pertinent to you. If you have fields or folders tracking these things and would like to save time and sanity managing them, we recommend looking into the new shared fields (Global Lists, Users Lists):

  • Currency
  • Location
  • Revenue Stream
  • Process Area
  • Business Unit
  • Control Owners
  • Significant Accounts
  • System Applications
  • Relevant Compliance Area
  • Prepared By

Of course, reach out to us if you have questions on how to make the adjustments to your policyIQ site.

Using policyIQ to manage Scrum (Part 2 of 2)

In our last blog post, we talked a little bit about how we started to use the Scrum methodology to manage all of the projects that go into supporting policyIQ.  We found ourselves in need of a tool, and set about using policyIQ to manage our new Scrum process.

Scrum in policyIQ for policyIQ

We can’t tell you what the best policyIQ configuration will be for managing the Scrum methodology for your business.  Every team is going to be different.  But we’re happy to tell you a little more about what we’re doing.

I mentioned in the last blog post that we started with user stories and then we went back to goals.  Essentially, we currently have two primary Templates that are a part of our Scrum process.

  • Goals
  • User Stories



On our Goal templates, we capture the following:

  • Description of Goal
  • Area of the business (sales, marketing, product, support, etc)
  • Priority

Each Goal is linked to User Stories that will support the goal.  The fields here are much more detailed, and include:

  • User Story Statement
  • Business Value (or “Impact”)
  • Effort
  • Status
  • Blocked By
  • Currently Worked On By

We meet bi-weekly to review our last sprint – were there items that didn’t get finished?  Why? – and to plan for our next sprint.  As we plan, we move User Stories from the Backlog into individual sprint folders.  (If something doesn’t get finished in a single sprint, we keep it in both the older and the newer sprint folders.  It’s a lesson learned for us that we planned imperfectly – either we didn’t break our user story down into enough detail or there was a block that we couldn’t overcome in the given sprint.)


And of course, we use the policyIQ reports to plan, update our sprint items and to evaluate our progress.  For the purposes of our scrum process, I personally almost never find myself in Create And Edit – but rather stick to the reports to take care of all of my updates and planning.

Flexibility?  Yeah, we’re gonna need that.

We find ourselves telling clients frequently that one of the benefits that policyIQ brings to the table is the flexibility to change the configuration or the process if you find that something isn’t quite working for you.  In our last blog post you read about how we ended up going back and changing the way we set priorities a bit, by going back to high level goals to prioritize.  That doesn’t really tell the whole story – as the truth is that we’ve really gone back and revisited the process with almost every sprint to make small adjustments.  New fields, new values, new Folders and new Templates.  Lucky for us, policyIQ has allowed us to do that without having to make any significant changes to the original documentation.

Are you using Agile or Scrum in your daily work?  We’d love to chat and learn what best practices you’ve found – and share some of our lessons learned.  Of course, if you are interested in using policyIQ to  manage your projects, let us know and we’d be happy to show you more of what we’ve done!

Using Scrum to manage policyIQ (Part 1 of 2)

If your role in any way touches the world of technology, it’s likely that you’ve heard of “Agile Methodology” as a way to manage software development.  The concept is pretty simple (and I’m going to simplify it even further): build, test, and get feedback in short iterations.

A specific method of implementing Agile Development is Scrum, a method by which a team works together in short “sprints” to complete specific goals.  (The folks at scrum.org do a fabulous job of summarizing the method – and it has very little to do with rugby.)  Our product development team has been using Scrum to develop policyIQ for awhile now.  The short (typically 2 week) sprints allow the team to complete the development on a feature, test it and get feedback – sometimes directly from customers and sometimes from our policyIQ account management team.

scrumThe enthusiasm around Scrum was infectious – and the whole team caught the bug

As the development team started to really smooth out their Scrum process, it was clear that the methodology kept things on track.  And the enthusiasm for it was infectious.  While “Agile” and “Scrum” are typically words associated with the actual software development, we started to ask, “Why can’t these same principles be applied to everything else that the policyIQ team is working on?”  So we set about applying Scrum to the entire team – and we needed the help of our internal policyIQ application to do it.

I should point out that I am NOT a trained Scrum professional.  Our Senior Manager of Technology is trained; with his guidance, we’ve taken some liberties with the “official” methodology to apply it to our work.

How do you get started?  You just start.

scrumstartedquoteOne of the lessons that our trained “scrum master” (ie our Senior Director of Technology) taught us was that you can’t get too caught up in starting off perfectly.  You just have to get started.  So we did.

We started by taking all of the project plans and “boy wouldn’t it be nice” lists, and translated those into User Stories – descriptions of the project or task that focus on what the impact of those projects might be.  For example, we wanted to issue a Client Survey.  The user story read:  “The policyIQ team wants to craft a Client Survey, so that we can better understand the needs and desires of our current client base as it relates to product features, support and training.”

The Scrum method suggests that you determine the length of time for each “Sprint” – no longer than 30 days – and then break your projects down into pieces, so that you can complete those pieces within the sprint.  So, the Client Survey User Story had to be revised to become multiple user stories in order to be able to accomplish parts of it within a sprint, starting with the draft of questions, all the way through follow-ups and long-term goal planning.  Scrum also requires that you prioritize each item so that you can pick out those items that will have the most value (weighted for how much effort it requires).

We incorporated 5 – 10 minute daily morning meetings into our routine, so that we could keep everyone up to date on what was accomplished, what was on the agenda for the day, and what issues were causing delays or “blocks”.

Revisiting, revising, rethinking

We had gotten started, but the first few sprints just didn’t go so smoothly.  Other things kept popping up and we weren’t getting those sprint items completed – but those “things that kept popping up” were really important tasks that couldn’t be delayed.  We realized that we really had to rethink and better prioritize what we actually put into our sprints and we had to leave room in our sprint schedules to address last minute priorities.  So we took a step back and documented our high level goals, and prioritized THOSE, as well.  Then we referenced the high level Goal in each User Story, so that we could better focus on the goals that were our top priority.

But how are we going to track our progress?

All of these user stories and goals have to be managed – and it won’t surprise you to learn that we chose policyIQ to manage the information.  In our follow-up blog post later this week (Using policyIQ to manage Scrum), we’ll show you how we implemented our Scrum process using policyIQ!

Some of you may also remember that our friends at Equinox co-presented with us last year to show our policyIQ clients how they manage their software development and IT projects using policyIQ and Agile.  Check out this recording to learn more about their process!