From our Supreme Tech Nerd (aka Senior Director of Technology) to Yours

Introducing Matthew Krummert, Senior Director of Technology at RGP, policyIQ. Matt was asked to share his thoughts on some of the common concerns of IT professionals related to cloud applications—and to tell us what some of those concerns are. Matt noted that there are a lot of applications that don’t always fit the customer’s needs, implementation of new products often takes months or years, it seems there are always hurdles to getting your information back from them, you’re never totally comfortable that your content is secure, you have a long wait for support departments to address your concerns, and you’re not sure if anyone on the other end is listening. Following are Matt’s thoughts on how policyIQ stacks up against these concerns.

Especially utilized for small to medium sized businesses, the cloud is transforming the way software works through its reduction of IT risks and ongoing support costs.  Through utilizing these benefits, and those from Web2.0, policyIQ continues to transform the way that businesses handle their content and GRC needs.

Cloud delivery is less risky: Easy to turn on…and to turn off.

Purchasing software can be a complex process as you are never entirely sure what you are getting. Because policyIQ works on demand, organizations are able to mitigate that by testing the software out prior to purchase in a 30-day free trial site. Because policyIQ uses web2.0 features, you can customize the site to fit your needs to ensure that each installation is an optimal package for you and your organization. This means that companies are also able to have a site up and running in a couple of hours and configured for everyday use in a matter of days or weeks rather than typical months-long implementations. If you are not completely satisfied, policyIQ allows you to disconnect at any time and receive a direct delivery of your content to your designated contact.

Is the content really secure? Yes!

Seamless security is also a concern for most departments. Upon creating a site, policyIQ offers three options for authentication: single sign on, custom authentication using SHA1, and LDAP (or Active Directory) security. Once you are in the site, you are able to set security down to the granular item level (a Page, File, or Weblink) or folder in a user or group based fashion which allows multiple departments of an organization to use the site concurrently and securely without knowing that the others exist.

Power at your fingertips and Support to back you up!

Mistakes are always a possibility:

“I deleted something that I need after all.”
“I made changes to the wrong content.”

For these instances, policyIQ utilizes a simple recycling bin, and also offers snapshots which you can schedule at will. Through utilizing either of these processes, policyIQ empowers an individual to fix most potential problems that come up directly within the application. You can also ask any of our existing clients or refer to our recent survey results to rest assured that our Support department is top notch! They address any questions that you have quickly and thoroughly…and you will get to see your ideas for future development come to fruition! We’re actually listening.

Speaking of listening, we’d love to hear from you! If you haven’t already seen a demonstration of policyIQ, go to our website to sign up for a personalized demo or to watch our 5 minute video introduction.

Talk to you soon!

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

 

goaluserstory

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.)

sprintfolders

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!