Blog

The latest news and insights from the HarmonyPSA team

Project planning using Work Breakdown Structure

This post deals with a concept called the Work Breakdown Structure (WBS) a way of logically and hierarchically decomposing a project to help plan, manage and control delivery.

The first message is that a WBS is not a random sub-division. Each level of the hierarchy matters, it has a role to perform and this should be maintained both in the plan and also during reporting cycles.

The second message is that a WBS is also applicable to Agile development projects, though I guess many Agile purists may dispute this.

Read More

Climbing the Capability Maturity Model (CMM) ladder

CMM is a concept that dates back to the US Department of Defence assessing their software contractors and developing a maturity model that enabled the contractor’s process maturity to be compared.

You sometimes see outsourced companies advertising themselves as CMM level 5 (the highest) with direct reference to this model.

There is significant debate about whether CMM Level 5 even makes sense as an operating model, in particular for innovative software development. However as a lens through which to review your processes, it has good applicability and is a stepping stone to ISO accreditation.

Read More

PSA for ISVs

We’ve been writing a lot recently about MSPs and the uspecific requirements they have from PSA platforms.  So, to change tack, we thought we’d discuss the niche functionality ISVs require, in particular those selling their software as a service from the cloud.

Read More

Developing a channel distribution model

Are you developing a partner-based channel distribution model? If so, there are some operational aspects that you should be considering.

Most product companies start their life with direct sales and there are many  PSA systems on the market that support this sales model.  However, once the ISV moves into a channel sales operation, there are a number of system considerations that must be tackled to make this work effectively.

Read More

Does deferred revenue matter to MSPs?

Deferred revenue, for those not familiar with the phrase, refers to revenue you have invoiced but not earned yet, basically you haven’t completed the work but you have raised the invoice. Now, ISV’s know all about deferred revenue as they frequently invoice software support fees for multiple accounting periods in advance.  They know it is important not to show income spikes when raising invoices that may cover a year’s support fees.

Read More

What lies at the heart of your business?

Whether you’re part of a managed service provider (MSP), an independent software vendor (ISV) or a pure professional services business it’s good to consider what lies at the heart of your business so you can focus on making it better.

When asked, most technology related businesses would probably claim that knowledge lies at their heart.  They are passionate about what they do and rightly proud of the expertise they are able to bring to bear to solve customer problems and deliver results.

Read More

Why ISVs need PSA software

We talk to a lot of technology companies, different ones every day, both here, in the US and as far afield as Australia.  Since we began this journey with Harmony, a discernable pattern is emerging that seemed worth sharing.

Many of the companies contacting us are MSPs, they know they need software to run their businesses and, more importantly perhaps, they realise that they neither have the time nor the desire to write their own software.

Read More

Ticket Configuration Ideas for Harmony PSA - The ISV

We are running a few blog posts over time describing typical ticket configurations for different types of business, so stay tuned and you may see something relevant to you! This week we will be looking at a typical ticketing setup for ISVs (Independent Software Vendors). Please bear in mind this is only an example of how you might use Harmony; created  for your convenience and reference. You will almost certainly want to customize your set up to a less or greater extent.

A typical ISV ticket configuration

ISVs typically use ticketing for three broad areas of work:
  • Helpdesk - where customers call up for help or with a problem and their 'issue' needs to be tracked and resolved
  • Project Work - where a customer has paid for some work to be done, and there are many tasks, features, bugs etc etc related to that work that need to be tracked
  • Capital Expenditure Work - this would typically be R&D type work building on your intellectual property and usually funneled into some sort of software product sold to many customers
Using Harmony ticketing we can model all three of these types and ticket and actually make these different types of interact with each other. This is very useful!
At the heart of Harmony ticketing is the concept of Ticket Types and Workflows. We will start with the main Ticket Types you will create.

The 'Call' type of ticket

This type of ticket represents a customer facing issue. The customer has called or emailed you to let you know of a problem, concern or question.
The key aspect of this type of ticket is that is should probably be tracked against an SLA. You can define these within Harmony to match either internal or customer contractual SLAs. SLAs are satisfied by your ticket reaching certain Statuses in your Workflow within specified timescales.
Also, these tickets will be tied to a customer, a contact and possibly to a contractual agreement with the customer.
A typical workflow for this type of ticket might include:
  • Unassigned
  • Assigned
  • Responded To
  • Resolved
  • Requires Development
  • Awaiting Customer Feedback
You can imagine what these statuses represent, however the Requires Development status is interesting as it implies the use has created a second type of ticket, on which this ticket is dependent for closure. This would typically be a Bug or Feature type ticket.

The 'Bug' and 'Feature' types of ticket

These types of ticket are used to actually do development work and are not customer facing (ie the customer would not see this in their portal and they cannot raise them directly)
The reason that these are a separate ticket is because they have their own workflow, and a Bug may actually close a number of 'Calls' which may be with different customers.
The user responsible for the Call with the customer can see any related Bugs or Features they are waiting on to close the Call.
These Bugs and Features can be prioritised along with all other Capital Expenditure work and sent to different teams etc.
A typical Bug or Feature workflow might include the following statuses:
  • Unapproved
  • Approval
  • Under Development
  • Code Complete
  • In Testing
  • Scheduled For Release
  • Released
  • Rejected
Typically a Feature type workflow would include the approval steps whereas the Bug might not.
These types of tickets can be used for Project Work both before and after delivery.

The 'Release' type of ticket

A Release typically goes through a test cycle and would release a number of Bugs and Features into production. As you build up a release, you would be looking for Bugs and Features which are in a status of Code Complete, make them dependent upon the Release and change their status to In Testing.
The best part of this process is that when you close the Release, the system will close all the Bugs and Features and also any of the Calls which are dependent upon these! A real time saver!
A typical Release type ticket would include the following statuses:
  • Created
  • In UAT
  • Awaiting Release
  • Released
We hope these examples have given you some ideas. As always, we welcome any feedback or scenarios of your own. Good luck!
Read More

Categories

Recent posts

Subscribe to our blog