Why you can’t always have what you want Simon Hutchinson – Reckon Product Management.

Tomatoes – Don’t need those!

Overview The development cycle A few scenarios that regularly occur What about a patch? PSG tells me they sent it on to development but I never hear back The typical Reckon development cycle Things that can really make things tough

We’re on your side We understand the frustration that occurs when you find issues in our software If we could fix absolutely everything we would We do take your feedback on board, as you will see later in this presentation We take pride in the software we produce and ‘bugs’ hurt

A few scenarios

Compliance Changes Each year we sit down to determine what will go into the product this year These decisions are generally around features that we want to add to improve the product As you may know we regularly attend ATO meetings to discuss changes. We are also in close contact with the IRD on changes. Often these ATO meetings change our development priorities due to upcoming compliance. The IRD can also throw a spanner in the works. Compliance is and always will be the number one priority

Government Rules Regularly when the developers are working on compliance changes they have questions There is a hotline and address setup to deal with these questions from developers However they are not allowed to answer questions on draft laws Regularly we are working with draft legislation and have to interpret it We have to do this to deliver compliance on time to our users

Government dissolving One of the more recent problems occurred when the Federal Election was announced This leads to the Government moving into caretaker mode In caretaker mode the ATO/IRD is not allowed to answer or talk about any questions directly related to Government policy and law which has not been passed parliament yet This caused delays into interpretations of Paid Parental Leave in Australia last year

External Factors As some of you are aware Reckon develops for international markets such as New Zealand and Asia Recently the NZ Government has given indications that it is flagging a number of changes to its taxation and revenue systems Like in Australia, compliance is the number one priority If we had a dollar for each time Australian compliance has cost NZ a feature, we’d be pretty rich by now.

What happens when I tell PSG about a problem This has been one of the issues of angst from the AC/AP network this year PSG does tell us of an issue and it gets logged in our bug tracking system It is then attempted to be replicated and if it can be, risk assessed Sometimes we don’t get enough information to look at the issues

Information we need Operating system and Service Pack What version of QuickBooks and if there is a patch installed Can you get it to happen over and over again or is it intermittent Is it running through Terminal Services Brand of computer where applicable

Reckon Development Process Product Management build a draft scope of the features to be included in the product Escalations meeting then occurs to decide what needs to be looked at. Draft scope is taken to Senior Management and then signed off Scope is then presented to the AP Council for feedback Discussion about the feedback from AP Council

Reckon Development Process (cont.) Scope is finalised and documents written for development QA and Development are shown the documents and ideas for their feedback QA and Development are shown the design and changes tweaked based on feedback Product is developed and tested Beta Test Occurs. Live data fed back to Reckon

Reckon Development Process (cont.) Bug reports are analysed and we try to replicate the issues Final testing Occurs Product release

Terms you may hear when dealing with us Alpha Phase – Initial development and testing phase Feature Complete – The day we lock the products features down BETA Phase – A beta test of the Feature Complete product Regression – The second last phase. We test that new features have not broken old features.

QA Processes Each defect (bug) with the product is entered with a rating system of tweak through to block. A block is something that completely breaks the product. The developers have to fix this issue by the end of the day if possible. Examples of block defects include program won’t open, old file not found and payroll won’t calculate any tax. The whole office knows when we find a block

QA Processes (cont.) Other bugs are entered into the system with a rating system and priority Due to time lines tough decisions need to be made. Frequently towards the end a major becomes a block to ensure that we fix it. Some defects are lowered after more research. In general a defect with an acceptable workaround is less likely to be fixed then one where a workaround exists.

A few other things that affect decisions User guides Boxes and marketing pamphlets Legislation changes

Why do we not release patches that often? Some of you may have noticed the US has in the past released around 20 patches a year It is a huge strain on development and has an impact on the business. Cost/Benefit analysis. Releasing a patch for issues with a workaround can lead to more issues It has an impact on future products

Patch process Gather data from users about operating systems, versions and the issue itself Perform an analysis on the risk and the potential impact of the fix Determine the scope of the patch process. Confirm that we have the correct fix specified in a document. Usual software development life cycle then kicks in.

AC Council – Your Voice As of 2008 we meet with a selected number of AP’s every 3 or so months in Australia to discuss issues. We want to start hearing from NZ AC’s. If you have issues, and they are raised via the AC Council, they are discussed with the Reckon departments affected. The AP Council in Australia has had significant impact on the release of our products and has been very positive. We hope to do the same in NZ. Don’t be afraid to raise problems with them

Reporting an issue Give as much information as possible to us. Operating system, multiuser, what version, what computer system etc Submit via PSG The more information we have the easier it will be to trigger it in the office.

BETA Testing Most important phase of our development cycle. Giving it to you to try. We hear your voices about it breaks my old quickbooks, I don’t have time etc and are improving things All future QuickBooks BETA’s will be conducted via the Online Infrastructure. Those who want the actually install files can request them.

Questions!