Starting Your project

Castle Software Australia can manage the entire software project lifecycle for you. We can handle the requirements analysis, produce technical specifications and fixed price estimates, write the code, build the database, deploy the system migrate your data, assist with testing and offer complete support afterwards.

But more than that, we will help you understand what it is we are doing, every step of the way. We can break a project down into phases to help get critical parts of a new system online as soon as possible, leaving other parts to be built later. If there are some parts of the project that you are still uncertain about (whether you can’t quite voice your needs, or you need to explore new ways of doing your business, or you just want to experiment with the user interfaces) then we can use prototyping or agile (iterative) project approaches to help pin down the solution that’s best for you.

Developing custom software is never a one-size-fits-all operation. Every project is different, and it should be - after all its your business and no one else’s.

Look at the newspaper and read about large gov’t and private software projects suffering major cost blowouts. In virtually every case the problem will not have been a technology one, it will have been a failure to communicate effectively and a failure to follow basic project management principles at all levels of the team, from senior management down to the programmers. To that end, let us assure you that we understand how to manage a project - lets go over some of the basics now so you understand how we will proceed with you...

Generic placeholder image

Business Requirements Analysis

One of the most critical things we tell all our clients is not to hold back when requesting functionality for their system. Don't attempt to limit what you want, thinking (incorrectly) that it might be expensive or time consuming or just impossible - let us work that out for you - let us know what your dream is. Our clients are frequently surprised that something they thought was hard really isn't and is well within their budget. Similarly if what you want IS expensive, we can often find a partial (80:20) approach that will give you the important bits, and neatly leave out the portion that is the expensive hiccup.

Our team has excellent communication skills, both written and verbal, and have worked with clients in many different professions gathering & documenting business requirements. These include business change consultants, medical researchers, building contractors, medical professionals, HR, Primary Industry (mines, oil) & Government departments.

Documenting requirements using your language and jargon is a crucial step in ensuring that there is complete understanding when developing a custom solution for anyone. This avoids the majority of classic project management goofs and frankly makes for great repeat business.

This is also the time to decide what kind of project management/development methodology will work best for your project.

Technical Analysis/Specification

Taking business requirements and turning them into technical specifications is the critical step in preparing estimates for any project, and ensuring there is complete understanding between all parties. This is where assumptions are tested and technical feasibility of the technologies requested are proven.

The rare occasions where a project stumbles for technology reasons can always be tracked back to not performing this step correctly, or thoroughly.

Key points which must be agreed upon before this phase include essential business requirements about: security, speed, size, transaction limits, bandwith, scalability, platform or anything which you consider a make-or-break issue. This is because the Technical Analysis will make design decisions affecting such things, and something as simple as picking the wrong database, hardware, webhost, control toolkit...etc can have major implications if the wrong choice is made unknowingly.

We excel at this, in particular making sure that technical questions can be directed back to the client in the business terms they understand - not technospeak.


We have extensive experience in software development which has been documented elsewhere on this site. If you have a specific development strategy or tool that you want us to use please let us know - it won't be a problem.

We create well documented applications that have distinct Development, Test and Production cycles. Most of the systems we build are used by the general public in one form or another, and as such have had to be built to a higher standard of stability than typical in-house apps.

We also offer to support and maintain every system we have built.

We have worked for businesses who need a Developer API (integration toolkits) to be designed & documented for their own products. This includes commercial add-ins and wizards for Microsoft Office.

Our long history with PC development goes as far back as MS-DOS systems (anyone remember what Clipper and dBase were?). As such we are ideally suited to help with projects that port from or rebuild old legacy systems, as we have staff who used to work on that stuff when it was considered new and sexy! We aren't fazed by the idosynchrasies of the old systems; we know how to move them to the new, and what questions have to be addressed along the way - BEFORE they become a problem.

Database Administration

We design and build new systems on SQL Server by choice. We cover all aspects of design, writing SQL queries and/or Stored Procedures, optimisation, deployment, and migrating changes and data between Development, Test and Production servers.

This includes systems which require security meeting Australian privacy legislation standards, ensuring data transport and import/export between systems is secure.

Having said that, we have also produced applications running on Microsoft Access, dBase files, XML, Excel, Text (CSV) and other formats. There are often good reasons for considering database products other than SQL Server (eg: NoSQL), and we don't want you to be constrained - let us know what you need to do.

Deployment (DevOps)

We can manage all aspects of deploying new applications and maintenance releases to the Cloud or traditional web host, including maintaining distinct sub-domains and databases for Test and Production. Nowadays, all the operations associated with this are collectively referred to as DevOps.

We have also created commercial Windows applications with commercial grade installers for deploying those programs to our clients and their clients in turn (both other corporations and the general public). These installers are created using a combination of the Installaware and WISE toolkits depending on requirements, and can be run from CD, USB sticks, file downloads or directly from your website. We can even design your application so it checks for updates to itself and manages the entire process automatically like many commercial systems.

Our goal is simple - to install and maintain your software on its final platform transparently, with zero or minimum fuss to you and the end-user.

Team Work

Our staff have worked both individually on projects and within larger teams. We are able to set goals and work to deadlines/estimates. Our staff can also work collaboratively within a team environment, including mentoring or supervising junior staff.

We are experienced in architecting large scale applications so they can be worked on by many programmers independently with minimal opportunities for clashes, using the version management system of your choice.

Prototype Development

Sometimes you will know what you want, but can't put it into words. Sometimes you want to explore an idea that involves cutting edge technology or attempts to solve a business problem in a way you've never tried before, thinking outside-the-box, out in left-field kinda stuff. Businesses that want to keep three steps ahead of the competition do this sort of thing regularly. In these cases its impossible for anyone to produce a quote, since we don't even know what the goal posts are.

But we don't let that stop us.

The solution is something called Prototype based development. In simple terms, you give us a rough idea of what you are thinking, and we build something. You then critique it - along the lines of “that not what I want, but seeing this makes me realise I want something like this over here...”, and we start the process again. The iterations continue until you have an Application or Website that seems to do what you are after.

At that point several options are available to us - but basically we work with you to turn that rough-as-guts app into a polished professional application, as though we’d written it to a fixed specification originally. This last phase can usually be quoted on accurately.

Obviously providing estimates for such a project is difficult, so what we do it break the work down into chunks of time (usually a single iteration of the build/critique cycle), and you authorise each one in turn. If you feel that you are spending too much without getting anywhere then we stop to allow you to spend more time thinking about your needs, and continue at a later date (or not) at your discretion.

Sometimes the end-goal of prototyping is to prove that a particular approach will not work, or to establish the parameters of when it might be possible (eg: what new technology or price point is required for the idea to become useful or practical?).

The Prototyping approach is also useful for small parts of a larger solution, where you know what you want for most of it, but a small part or parts are still hard to pin down or need some technology issues solved. So we set up a small project to answer these questions for you and incorporate the results into the larger project plan. We describe prototyping in this context as a Feasibility Study.

Agile (Iterative, RAD) Development

This methodology has been given different titles over the years, and while each has technical differences they all point to the same basic project management technique - break a large project down into small pieces, treat each as a separate project with its own requirements, specification, development and testing cycles, rinse and repeat. Whether you call each cycle a mini-project, a Sprint or something else is immaterial.

You evaluate how well each cycle went; adjust plans; how estimates are arrived at; whether the technology, database, coding methods or staffing need adjusting and begin the next block of work. Sometimes the next block will even go over the same area because you are trying to fine tune or optimise the user experience (like prototyping, but focussed on a specific feature or screen). In other projects the cycles relate to building pilot systems to evaluate a technology or approach, building the system for a single office/branch/state to verify that it works as expected before scaling it up company wide.

If you are planning a large scale greenfields project that is a bet-the-company operation, we strongly recommend this approach, so you can establish if the new system/approach really does work as expected and can scale up as required before you turn off the old system. It also allows you to keep a firm control on cost & schedule blowouts and minimise the risk of a project failing. It also allows for testing to be conducted in a real environment, but with limited fallout if/when bugs are found - meaning you can hold off doing the company wide rollout until critical metrics are met completely.

The other benefit to this approach is that it allows you to change your priorities as the project progresses, based on real-world needs. This is vital when the new system is something you need to start using ASAP...

Something else to consider, we can use this approach for handing the migration of data from your old system to the new one. Data from one system will often not map exactly to another (different accounting standards, lots of old oddball records that don't fit your new way of categorising things, mismatches between historial records and newer ones...etc). Because of this its important to "practise" the migration of data from your old system while it is still being used, identify every single problem area, and keep repeating this until we get it perfect before we attempt the final go-live migration. This ensures that you do not lose any data, and it also acts as a reality check on the new system's design - as you may not have considered issues relating to old data.

One important point - on paper this approach can look more expensive than just proceeding through a project plan step buy step. But its about risk management. The larger the project, the more of your business that might be affected by its success or failure - the more you can’t afford to not choose this approach.

Project Estimate, Quotes...etc

If there is one area that is still a black art (and has a black reputation to match), its project estimation. We are happy to offer a fixed price service to customers, but there is a catch - you need to know exactly what it is that you require.

If you are able to provide answers to all of our questions during the Business Analysis and then Technical Analysis phases of a project, then its possible to come up with a quote that we are happy to work to. But it does mean that any deviation from this results in extra charges. We can tell you what the most cost effective approach will be in each instance - leave it until the end, or fix it now... But note that if a change request breaks any critical technical design point, the cost could be larger than you might like, because it will involve reworking chunks of the system already delivered to you.

We will work with you for as long as you require to ensure you have confidence in the specifications you helped produce...

The problem of being able to specify exactly what you want (or need - the two can be different) in a changing business landscape should not be underestimated. If you want to redesign a key business operation, often the details of how your own business will operate and respond to each challenge can still be fuzzy. You will naturally rely on the expertise of your staff to navigate any issues that crop up. Over time, the number of unexpected issues drops, and the operation can be easily documented, training updated, regular tasks handed over the junior staff...etc.

But if you are trying to design a website or application to handle the automation while the above is happening (or worse, before you start), the initial vision of the new business operation is all we (the designers/developers) have to go on. But it may be more expensive and time consuming for us to change gears and resign & deliver parts of the system as quickly as your staff can handle the crisis. But hang on - won't you want to have this system mostly developed, setup, tested and ready to go before your big new push?

Prototyping, and Agile Development strategies (as discussed above) are usually what is brought to the table here. But even those methodologies can struggle if your actual needs continue to change over time. At the very least, a new system designed under these circumstances will need to be very flexible:

  • Calculated items may need to allow an override, so your staff can say enter a new shipping calculation manually if your carefully laid plans with a new supplier go awry.
  • Validations (checks that all information has been entered correctly, and in full) may need to be flexible - and allow some details to be omitted or less than perfect. An example here is if you design delivery addresses for one country, and decide to trial selling in another - that has a different standard. Even how phone numbers and dates are crafted will vary from country to country - so its wise to not lock in assumptions early.
  • A related scenario is when you might need to record a single selection (any kind of entry) for something, but very rarely need to record two. In this case just ensure that any number can be recorded, that the user can navigate this complexity easily, and worry about how frequent this is once you've actually done it for several months and can be more certain of the decision. For example: mailing addresses, phone numbers, contact details, names, previous names...
  • Make sure you still track key details, like the number of orders vs your capacity to deliver in a certain timeframe. Customer relationships go south really quickly when you make a limited time offer, and have 10 times the responses expected only to have to inform 90% of them that you can't deliver...
  • Its important to capture feedback from staff at all levels of your operation, especially if some aspect of the system failed to handle a new scenario. In this case you might to add comment or question fields on staff-only areas, so they can annotate almost anything. This provides excellent feedback for when you want to try designing phase 2... (even if its just where you need to focus additional staff training)
  • If a system is hosted in-house, make sure your IT network/infrastructure staff are prepared to monitor performance, and know what to do if there are spikes in system usage.
  • The same applies to cloud based systems - everyone has heard the story of sales sites that worked normally for months, and then promptly imploded under the weight of a black-friday sale. Properly designed cloud systems can grow automatically - or at least extremely quickly if some aspect requires staff to monitor it live.
  • Good reports, particularly those for management, can take a while to bed down - if the business is changing it makes sense that the metrics, KPIs and other regular figures management needs will also be changing. While you will want to have these reports automated (and the layout fixed) eventually, consider just exporting (parts of) the database to say Excel on request (or Access, Power BI - whatever the in-house reporting tool of choice is). Management usually has several staff who can craft the output they need quickly using these tools, and it also means that the iterations of report design and calculations can be done without the developers being involved - you just have to show us at the end what you came up with, and we can write a report in the system that will produce that on demand.
  • If staff need to look at lots of data on screen (particularly in any sort of grid layout), ensure that they can filter and (re)sort this easily. One typical problem as staff respond to odd issues is the need to look at the data in different ways: by date instead of description, or by amount instead of by name, as they try to locate one specific record.
  • A related issue to the above is the ability to locate a customer's details / order by many different values. You may prefer to have an order number, but a bad phone line, language difficulties, or other issues mean that the only thing your staff caught was their surname, and one of the items they ordered. There is a reason Google is the preferred method of searching the internet - they allow you to find anything with a huge variety of search terms. There are practical limits here to be sure, but flexibility is fairly easy if you think of it early.
  • Audit tracking. While normally a security measure, in a new system where staff are flying by the seat of their pants, mistakes can be made, data may be erased accidentally, or updated the wrong way. While recovering data from an audit trail can be messy - it is at least possible. So you can still tell the important client whose order got screwed up thoroughly that you will be able to get them what they asked for (albeit with some running around behind the scenes). This is another area which can backstop training (or the lack of it) in new staff if you had to hire a lot of new people to get through a busy period.
  • Admin, or Team Leader override abilities. This is akin to the ability of a supermarket checkout operator not being able to reverse a sale - but since accidental double scans do happen - they can call over the shift supervisor to enter their password, and delete the item in question from the cart. Maybe you want a number of the flexible things mentioned above, but would like them to only be used when authorised - this is how.

Even if you are happy and confident with a project estimate, it can all come undone when management decides that they like the sound of what you plan, but have realised that the best possible time to release the new system is in sync with some other operation or service, and thus they want it all done 3 months early... And then insist that 100% of the work be done by the new dates...

This utter disjoint between expectations and reality is probably the single biggest clash point on a project between management and the project or technical staff. Dealing with this requires many strategies, most discussed on this site. We've seen this many times before, sadly. Handling it typically requires re-examining the development plans and goals to find the 80:20 possibilities, looking at how (increased) staffing might assist, reducing the function set, replacing some areas with data entry using Excel/word or direct database access by technical staff in the short term, and replacing designed reports with simpler exports (to Excel or other tools).

Most of all, it involves coming up with a plan that can achieve what the real goals are for the new deadline, as well as a revised plan to fill in the functional gaps, including costs and risk estimates of failing to do this. Note I said "Real Goals" - one of the most important tasks here is to find out what part of your original system proposal got management so excited - and what bit do they think will solve the issue they have with the new product, service, operation...etc. If we are very lucky - its a small part of the whole, and can be developed quickly and separaetly, while the main team continues on with a modified version of the original plan.

Its also critical to find out the monetary value of this new thing management is hung up on - just in case the tail is wagging the dog. You may need to politely point out that they are risking a million dollar project at the heart of a billion dollar enterprise for a $100,000 benefit. Similarly, if you know that the new product...etc will make the buiness millions, don't be afraid to tell management that the changes necessary to meet their goals might cost your project an additional say $100,000. Its all about context.