Software is Defining Business

Right now, today, and for the foreseeable future, software is defining business. The way in which successful businesses provide services and connect with customers is through apps, websites and APIs backed by sophisticated algorithms and analytics. Profit margins are defined by how efficient the apps are, and market growth is a function of highly personalised user experiences. This is evidenced by the growing ‘app economy’ which is disrupting sectors across the board: retail, finance, education, health, government and manufacturing.

Consumers are connected and demanding 24/7 access to services. Your customer’s first point of contact, and in many cases their only point of contact, will be via your apps rather than through personal contact. While we can thank Apple for the proliferation and general understanding of what an ‘app’ is, the definition is undergoing a transformation. Apps now encompass any software a user (or any other piece of software) may interact with. No longer constrained to just smart phones, websites are now apps that can be served on a variety of devices, as are traditional desktop applications and services provided via API’s (Application Programming Interface) over the Internet.

Never before have consumers been able to self-service needs to such a wide extent. Access to the world’s knowledge and businesses offering a staggering array of services is a few clicks away and consumer demand for apps has never been greater. This is evidenced by the announcement from Apple that the IOS app economy has created nearly 4 million developer jobs worldwide.

Business leaders must be savvy to this trend and understand the future it paints. According to CA Technologies President and General Manager for APJ, Kenneth Arredondo, “Only the strongest and most innovative companies will survive in today’s increasingly digital world”. He suggests that organisations must focus on matching the pace of innovation with the pace of disruption and capitalise on the opportunities to transform and grow during challenging times. As Marc Andreessen predicted in 2011 in his famous ‘Why Software is Eating the World’ article, innovations often emerge in the moments when it looks like everything has been changed and we’ve reached a new normal.

The message is clear: demand for app delivered services is rising, and businesses need to adapt or risk obsolescence.

Why apps are so important

Software is infinitely flexible and it’s an inherent part of our everyday lives. Our cars, coffee machines, credit cards and the expanding Internet of Things are all controlled by software. Growth is exponential – as the number of connected devices increase, the number of devices with which to connect increases, providing ever expanding opportunity. The speed and efficiency with which data can be exchanged by software is analogous to the difference between sending a text message and posting a handwritten letter.

Apps are the emerging face of business because:

  • They greatly reduce friction, increasing your capacity and allowing you to focus on other initiatives
  • Apps promote automation of repeatable, testable processes
  • An app can be crafted to provide a tailored user experience
  • They build customer and brand loyalty
  • Apps allow you to quickly and cheaply test and react to changing market conditions
  • Apps have reach: they are open for business 24/7, in any country.

The biggest keyword here is friction. For example, people will spend more when purchasing with a credit card over cash because the use of a credit card reduces friction; by separating the purchase from the cost, which has been delayed. Because of this, we foresee an upswing in credit usage with the introduction of NFC based payment options such as Android, Samsung and Apple Pay. Apps have the ability to perform the same function as the credit card in this example – they reduce friction between the consumer and supplier, resulting in increased usage, or purchases.


For existing products and services, apps provide massive opportunity for increased efficiency through automation. Recently, Kiandra was engaged by a large multi-disciplinary engineering company to undertake a complete IT transformation, starting with taking their aging but extensive customer-facing solution to a platform that:

  • Allows them to scale nationally by moving towards an API driven platform, connecting disparate systems behind a single programmable interface
  • Provides continuity of service by handling poor or occasional connectivity.
  • Leverages a responsive design to work where evidence shows their customers increasingly are – on mobile and tablet devices
  • Provides public APIs to facilitate B2B automation, increasing customer engagement and tie in
  • This investment has greatly reduced the manual effort required to process work, resulting in a faster turnaround for customers, reduced costs and increased capacity and market reach – all significant competitive advantages.

User Experience

Apps provide an immersive user experience. A beautiful example of this is the Typeform home page. Through the use fullscreen background videos and minimal web pages, Typeform engages the user, relates to the ‘human’ element and demonstrates the software. In the 15 seconds it takes to view this, Typeform have articulated their brand, connected with the user and demonstrated value in how engaging their product is, and what it can do for you. When viewed against traditional marketing activities like radio, TV and print, Typeform’s approach and ability to convert you to a customer is far superior and certainly more far reaching.

It would appear that the fundamental attraction for users to apps is that apps are self-centric. The app is there to serve you, on your schedule, in a way that works for you. Apps appeal to the inner child in us who loves to be delighted and engaged, which goes a long way to explain the frustration we feel towards poorly designed or buggy software. Apps connect directly with users on a personal level and like any relationship, should be treated with mutual respect.

Innovative Products and Services

Apps provide ground for new and innovative products and services. This is a result of affordable and portable technology, ubiquitous connectivity provided by cellular, wireless and fixed broadband, and location awareness.

New sales channels, market opportunities and ways to monetise intellectual property are frequent additions to the app landscape. Recently, we worked on a project for a large financial services company with a massive amount of intellectual property in their complex financial modelling and historical data. Having established a market exists, we were able to create a new revenue stream by wrapping their financial services up in an API and selling access to second tier providers. A second benefit was that the API could be used internally, ensuring consistency across teams – as it seemed individual teams had been creating their own spreadsheets, each which functioned differently.

Customer Trust and Brand Loyalty

Apps build trust, brand loyalty and an unprecedented ability to personalise. Personalisation is a fine line to walk between creepy and useful, especially in a post-Snowden world where consumers are becoming more privacy conscious and less tolerant of ad tracking networks in their everyday browsing. Our personal rule of thumb is this:

Delight me with a recommendation or incentive based on information I’ve explicitly given you – my browsing and purchase history on your site, and we’re good. Track me outside of your domain, and I’m no longer your customer.

It’s also important to be transparent, disclosing exactly what information is recorded, and giving customers an option to opt out, or have their information removed. Online ecommerce platform Shopify’s feature for allowing a ‘guest checkout’, without first having to create an account is an excellent example of providing customers a choice relating to having their purchases tracked.

Who’s Investing in Custom Development

At Kiandra, we engage with companies across a number of industry verticals and find our customers have a number of elements in common. It starts at the executive level with a clear business goal and a strategic directive to use software products and digital solutions to reduce effort, automate processes, provide timely information and drive profits.

We’re seeing a large amount of interest in B2B companies looking to automate through the development of consumable APIs. Providing an option for B2B customers to directly integrate in-house systems with their supplier is an attractive proposition on both ends. The supplier creates dependency through entanglement and the consumer gains access to the raw information and is able to integrate it directly into their business process and systems – often greatly reducing manual effort in the process.

The Engineering Industry

Engineering has a large number of complex problems that are time consuming to solve and critical in nature. Engineering companies are recognising that automation tools and software can do a large amount of the ‘grunt work’, which is improving overall accuracy and helping reduce timelines in large project schedules.


Education is currently being revolutionised through software and app development, with courses being delivered online via edXKhan Academy and iTunes U. Education institutions have adopted learning management systems for delivering course work, connecting teachers and students, and accepting work submissions. There are also education apps for people of all ages.


Government has always been keen to adopt technologies that save money. Peak bodies are embracing apps as a way to cost effectively develop and deploy standards and processes across their member organisations.

There are three key factors that result in myriad opportunities for Government right now:

  • Cloud providers Amazon Web Services, Microsoft Azure and Rackspace all have data centres on Australian soil, addressing the most often quoted barriers of latency and data sovereignty. Access to commodity compute and storage resources, security, logging and auditing is fundamental to supplying to Government and as a Cloud concern, these aspects are all standardised and supplied out of the box.
  • We’re seeing more Government departments embracing Agile methodologies. Agile focuses on delivering business value based on prioritised needs. A significant aspect of Agile is about forging client relationships and developing trust through customer collaboration.
  • Governments collect massive amount of data with which they have limited resources to leverage. Appification or enhancing Government services with their own information (check out is a great opportunity.

The federal government’s launch of a Digital Service Standard is an encouraging indicator that opens the door for state and local government to embrace the digital app economy.


Financial service providers are also investing in custom development. As discussed earlier, we’re seeing monetisation of intellectual property through the creation of subscription based APIs. We’re also seeing a large amount of self-service consumer facing apps – automated, small loans being the most common. Finance companies typically have well defined processes and a ton of paperwork. Digitisation of the data collection and evaluation processes is a major opportunity for increasing business agility, insight through data analysis and reducing manual effort.

Regardless of sector, any company that has the following concerns would benefit from investing in application development:

  • Getting the right information into the hands of users in a timely fashion.
  • Automating a process, or the collection of information.
  • Having complex problems solved.
  • Improving customer service.
  • Having more resources working on their core business, rather expending effort on repetitive tasks that have little value.

Barriers to Investing in Apps

The top five obstacles to investing in application development include:

  • Budget constraints
  • Security concerns
  • Lack of resources
  • Lack of knowledge and/or skills
  • Lack of executive management understanding benefits.

The reason budget constraints tops the list is that custom development can be expensive and the historical failure rate of IT projects does little to inspire confidence. Here’s a couple of tips on how to help approach the expense issue:

  • Establish the monetary benefit of your goal first. You want to understand the cost/benefit as quickly as possible. If a mobile app initiative is worth an extra $500,000 in sales each year, then that informs your maximum viable budget.
  •  Reframe the project from being an ‘IT Project’ to a ‘Business Project’. The goal should always be to deliver business value. When establishing scope, it’s easy to get carried away with ‘cool to haves’. Measuring each feature against the business value gives you a control mechanism with which to cut scope, reducing the size of the budget you require.
  • Start small and demonstrate value with a smaller project, building confidence to tackle larger initiatives.
  • Application development is a capital investment. You’re investing in an asset that will add value to your business. Consider financing development like you would any other capital purchase.
  • You will likely have monthly support, hosting and maintenance costs so include an operational budget as well. Like any other asset, software requires maintenance and upkeep to stop it from deteriorating.
  • Measure return from derived value. I recently scoped a mobile application for a supplier of safety equipment. The application provided a number of quick calculators for determining the loads that the company’s equipment could bear. The purpose was not to make a profit from the app, but rather to put the equivalent of a branded slide rule in the pocket of every one of the company’s customers. From a marketing perspective, the derived value exceeded the cost of development.


There’s an average of 4 million data records lost or stolen every day, so it’s no wonder security is a major concern for many people. Opening one’s virtual doors increases the number of vectors available for attack, therefore it makes sense to:

  • Include security testing as part of your application development process.
  • Conduct regular security audits across your organisation.
  • Keep security policies updated to reflect current recommended practices.

The best way to increase your in-house teams skills, knowledge and capacity is to bring in a supplier for a specific project, especially if you’re under resourced. Software development practices and technologies advance very quickly and it’s likely that, in order to stay relevant, you’ll need to be learning at least one new major technology every two years. Software development houses have to do this to stay competitive. Some of the most enjoyable projects we’ve worked on involved augmenting in-house development teams with hired project teams – which was a great way to cross train, modernise practices and ensured a shared knowledge base. The in-house team were confident in their ability to support the app once the project team had left.

The Costs of Not Investing in Custom Development

Unless you have a captive market, the biggest risk of not investing in application development is dwindling market share though the ability of competitors to deliver better and more cost effective services.

It’s no longer enough to just have a pretty website, businesses need to demonstrate value and innovation.

Tips on How to Select the Right Supplier

If you’re considering investing in application development and want to bring in a project team to assist, here are few tips to help select the right supplier. Before you start, establish the following:

  • An outline of what the business problems are and what success would look like. Don’t worry about technology (unless you have specific constraints) or how you will achieve success yet.
  • An estimated budget. If you don’t have this, engage your supplier to help you ascertain one and be prepared to pay for it. For an estimate to have any degree of relevance it will require discovery, data collection and knowledge transfer. Whether you go ahead with your project or not, this information has value and requires effort to achieve. Free quotes are great for curtains, and useless for knowledge work.
  • Decision makers have scheduled availability to attend meetings with suppliers. You’re trusting a company with your business, judge their value and competence in person.

Ask the questions ‘What would I get for my budget, and how would you achieve it? How would this differ if we had twice the budget, or half the budget?’ Remember, you’re establishing cost benefit, and with software, there is typically more than one way to skin a cat. Varying your budget allows you to understand the trade-offs and helps determine what the minimum viable product should look like before committing your entire budget.

The right supplier should engage with you on a business level. Application development is not commodity work that can be thrown over the fence. If you want a quality outcome, be prepared to invest your time and seek out suppliers who question ‘why’ as they’re demonstrating a willingness to understand your business drivers.

Finally, look for a supplier with established practices in a number of disciplines:

  • User Experience (UX) Design
  • Project Management
  • Development
  • Quality Assurance
  • Security
  • Analysis
  • DevOps
  • Infrastructure.

Building a successful app is a team effort and having access to pool of talented and skilled professionals will be highly beneficial.

Opinionated Software


Enterprise > Medium to Large Business > Small business

As a product’s target market moves from right to left in the above diagram, its configuration and customisation options grow and become more sophisticated and complex. This makes sense, as an organisation becomes larger, it’s more cost effective to change the software than it is to change the people and the process, so the software must be customisable to meet Enterprise needs.

This also has the effect that to the right of the diagram the software can afford to be opinionated. That is, the software can say ‘this is the methodology and process that we follow and support, and to get the best results, you should too’. Opinionated software will still provide configuration options (everyone needs something a little different) but the underlying philosophy is that it’s cheaper to change the process and people to the meet the software. As software moves towards the Enterprise end of the continuum, it becomes less opinionated and more generic as it’s required to cater to a wider degree of needs – relying on configuration and customisation to allow the enterprise to enforce its opinions on the software.

Both approaches have implications worth considering when choosing off the shelf (or custom) software for your business. The question to ask is, is it more economical to change my processes, or change the software?

Single or multitenant for your SaaS?

Often we need to make a call between architecting for single or multitenant instances when designing Software as a Service (SaaS) products.  Under a single tenant solution you deploy one instance per customer and under a multitenant solution many customers share a single deployed instance (where ‘an instance’ is all of the server resources you need to make the product available, e.g. web server, database, email server). It’s costly to change architecture once an application has been developed, deployed into production and has live users – so picking the most appropriate architectural approach from the outset is important to ensure longevity and maintainable costs. The following offers a number of considerations in helping decide which approach is appropriate for you.

 Single Instance considerations:

  • Physically ‘more’ secure – as each customer has a separate instance (likely including database, web servers, and storage) the risk of leaking data between instances is significantly reduced
  • Performance can be tuned on a per customer basis. Have a client with heavy loads? Scale up, or out. A load intensive customer won’t affect the performance of other clients as the resources are not shared. Got a light work load? Scale down, reducing cost.
  • Deploying to an on-premise, or hybrid cloud location is an easier story if you’re already set up to deploy as  single instance model. The nature of single instances means that an instance can be created and deployed as a single package – assuming the target deployment environment supports the required services and any other dependencies, e.g. web server, database server, virtualisation and / or network services (SMTP, DNS routing), runtimes (.NET, PHP)
  • Instances can be deployed in different regions to reduce latency (increasing performance by moving the instance closer to users), or to meet local compliance laws, e.g. data sovereignty
  • Calculating per customer hosting costs is simple as it’s based on exact, actual resource usage
  • Per customer [instance] customisation can be achieved if required. For that customer who just has to have that specific feature. Note: this will complicate your source control and deployment models, and can lead to a fragmented nightmare if not managed effectively, or avoided all together. Just because you *could* customise a solution per customer doesn’t necessarily mean you should!
  • Monitoring, maintenance, backups and new version and/or patch deployments and/or data migrations need to be managed on a per instance level, increasing costs proportional to the number of instances.  Need to back up instance databases, or roll out an update? Consider how will this be managed, and the cost for 1, 10, 100, 1000, 10,000 instances.  This is a significant cost, and should be evaluated against the necessity and likely usage of the other benefits of this model
  • Have a clear picture of how new instance provisioning will be managed, and how long it will take. Most cloud platforms allow for automated provisioning via API’s, and you may need additional steps like registering or configuring external services like DNS and authentication mechanisms (e.g. AD accounts)
  • Some resources can be shared, e.g. worker queues for background processes and SMTP servers. Plan which resources need to be ‘per instance’, and which make sense to share across instances

Single instance is typically suitable for:

  • Applications that store highly commercially sensitive, or personally identifying information of a private nature
  • Customers with specific, and varying workloads
  • Customers who need to adhere to local compliance laws
  • Customers willing to pay a premium for these features as they incur a higher cost to provide and manage


Multitenant considerations:

  • Careful consideration needs to be made to ensure data is not leaked across clients. This isn’t difficult, and should be managed with suitable design and sufficient testing
  • Deployments are much simpler, everyone can always be on the latest version. This approach lends itself to providing an ‘evergreen’ product
  • Reporting across all your instances is much simpler when they are in the same place (or all the data is in the same database)
  • On-boarding new customer is typically simple as it doesn’t require the provisioning of underlying resources (servers, database, storage)
  • An outage will effect *all* of your customers, design for redundancy
  • Requires a single monitoring, maintenance, backup and deployment approach. Costs will increase with the number of tenants, though much lower that a per instance approach. It’s probably the biggest benefit to this approach
  • There could be a point where you need to scale up, or out – or have *very* large data and need to consider how to partition. This could be one multitenancy per region.


Multitenancy is typically suitable for:

  • ‘Self Service’ products scaling up to and greater than 1000’s of customers
  • Reducing costs of deploying, hosting and maintaining your service

Shared tenancy with individual database and/or storage

An alternative hybrid approach is to provide shared tenancy of the application, with separate storage per customer. For example your app could be load balanced across a number of web servers which would service all of your customers. Each customer however would have their own separate physical database for data storage. This approach gives you the ability to provide the physical separation of data while having a shared application tier. This approach takes benefits from both single and multitenancy architectures:

  • Physically ‘more’ secure
  • Storage can be located in different geographic regions (though be aware any latency this might introduce in your application)
  • Retains ‘evergreen’ application versioning
  • Overall costs are lower than single instance approach

Calculated Columns using IF and IN operators in Zoho Reports

Filed under #SoIDontForgetHowIDidThis, #Zoho

In Zoho Reports you can’t add lookup or standard columns to data sourced from Zoho CRM. You can however add calculated columns, which is great if you want to transform a list of usernames into a department for future filtering or grouping.

The syntax for this isn’t well documented, and it took a wee bit of fiddling to figure it out. We combine the IF function with the IN operator where:

IF is a function defined as:

if(expr1, expr2, expr3)

Returns expr2 if expr1 is true else it returns expr3

Example: if(5 > 10,100,50) = 50

IN is a list operator defined as: 

<expression1> in <expression2>

It’s also useful to know that lists are enclosed in round brackets (), string literals are enclosed in single quotes ‘’ and column references are  enclosed in double quotes “”.

E.g, to return the department name of a user based on the potential owner, the formula would be:

IF("Potential Owner" IN ('Anthony','Seth', 'Chris'), ‘Technology Infrastructure' , ‘Software Development’)

Which will result in a list similar too:

  • Seth – Technology Infrastructure
  • Bob – Software Development
  • Carol – Software Development
  • Anthony – Technology Infrastructure

For a more explicit result we can nest the IF function, which will be familiar to many Excel users:

IF("Potential Owner" IN ('Anthony','Seth', 'Chris'), 'Technology Infrastructure' , IF("Potential Owner" IN ('Phillip’,'Bob'), 'Software Development' , 'Other’))

Will result in:

  • Seth – Technology Infrastructure
  • Bob – Software Development
  • Carol – Other
  • Anthony – Technology Infrastructure

As Carol isn’t explicitly defined as being in the TI or SD departments, this is more correct.

So how much will that cost?

The most common question I get asked by prospective new clients is ‘How much willMyBigProject cost?’ This is no surprise, as custom software development projects require a reasonable investment and you want to know what the AsLittleAsPossible cost will be so you can justify your business case and return on investment.

References to lengths of twine aside, ‘How much will MyBigProject cost?’ is by far the hardest question to answer. For the most part, because there are multiple ways to implement any solution, and I don’t know what’s important to you. So I ask you a bunch of questions, like whether you value time to market over feature completeness, do you have a specific budget in mind or do you need to scale / support high availability? (This is the modern day equivalent to asking if you want it fast, cheap or reliable, pick 2). What it comes down to is a 30 minute conversation and then I’m going to make an educated guess.

The formulae for my educated guess is pretty simple: scale the size of the team to match the scope of MyBigProject and multiply the result by the number of person weeks I think it will take to achieve. Which I’m hoping you will agree with me in a few moments is a thoroughly stupid way of estimating AsLittleAsPossible.

What’s wrong with this approach is that it is so laden with assumptions that there is no way it could possibly result in value for money.

At one end of the assumption scale is where we assume that only exactly what you asked for is required to be estimated. Most people have little experience with commissioning custom software projects, and it’s unfortunate that this is often taken advantage of by what is commonly known as the race to the bottom.  The theory goes, that by only estimating *exactly* what has been asked for, the work can be won ‘cheaply’, and everything else can be charged as a variation. Imagine building a house and on moving in day you discover it has no internal doors, no plumbing, no floor coverings, and while you specified a loft, you didn’t specify that you wanted a staircase to connect the upstairs with the down. Sound far-fetched? The media is ripe with IT projects that are over budget by orders of magnitude because of ‘race to the bottom’ tendering.

At the other end of the assumption scale is where we over anticipate everything you haven’t specified, and allow provision for it. To my detriment, this is the side of the scale that I tend to lean towards as I hate having to go back and ask for more money. If I give you a price of AsLittleAsPossible, I feel you should have the expectation thatAsLittleAsPossible will be all that is required to complete MyBigProject, and because I’m reasonably conservative, and as a company we value engineering awesomeness, we have on occasion over-provisioned and come in well under-budget.

Which brings me back to why asking ‘how much will it cost’ isn’t in your best interest, and a stupid way for me to estimate MyBigProject. You can get hit with never ending variations, or overspend more than was necessary to actually realise MyBigProject.Both approaches leave you spending more than you had too, and that sucks.

Asking me (or any vendor) ‘how would you achieve project MyBigProject for AsLittleAsPossible’ allows you to measure the value you will get in return for a set amount that you specify. Not only does this make comparing across vendors easier (interestingly it also allows you to measure expected effort, which is a great indicator of the calibre of your vendor), but it allows you to adjust AsLittleAsPossible up or down to understand the trade-offs, or extras involved.

Start with an amount that you would like to spend, I recommend 10% to 20% less than your break-even point. I like to do this with car shopping.  What can I buy for $20,000 right now? Well, I could get a 15 year old supercharged Mercedes, or a 3 year old Mazda Rx8. Both meet my criteria for a sports coupe, one I can service myself, and the other is far newer and has more recent technology. From here, I can evaluate the pros and cons of each vehicle, specific to my needs. I can assess the market, adjusting for where I see value and like Goldilocks find what is just right.

By working collaboratively in this manner, we start to break down our assumptions, uncover what we don’t know and shape the approach around the areas that you see as having the most value.  My favourite example of this is an eCommerce solution I architected where the majority of the budget was spent designing a beautiful, intuited shopping experience – while the back end administration was implemented in Microsoft Access. For the client, it was far more cost effective to train 5 people to use Access and far more valuable to provide a market leading online retail experience for her customers than it was to follow conventional wisdom and implement a homogenous solution.

What I really love about this approach is that it challenges us to think creatively to come up with the best solution for you, based on your priorities. We let you know what features can be implemented, and how they will be implemented for AsLittleAsPossible. If that’s not enough to meet your minimum viable product, adjust AsLittleAsPossible to include the bits you want (you kept back that 10% to 20% right?)or if it’s getting a little too fancy, scale AsLittleAsPossible back. You’re now in the driver’s seat, and able to evaluate the merits of a solution against exactly what you wanted to spend in the first place, no sticker shock or awkward negation required.

So for MyBigProject, try starting with AsLittleAsPossible and challenge your provider to design a solution to fit your budget.

Scoping for readability and automatic clean-up with IDisposable()

This is a simple trick that I find makes my code more readable, and reduces the amount of code I need to write to explicitly scope *something*. It avoids the need to have to manually clean up, or reset some state. In the sample below I’ve used this to highlight the output on a console app to a user defined font colour. It’s really simple, DRY, and a great example:

Rather than writing this:

Console.ForegroundColor = ConsoleColor.Yellow;



I can now do this:

using (new ScopedConsoleColour(ConsoleColor.Yellow))
      while (!_server.IsComplete)

Based on a defined class of:

class ScopedConsoleColour : IDisposable
    public ScopedConsoleColour(System.ConsoleColor colour)
        Console.ForegroundColor = colour;

    public void Dispose()

mplementing IDisposable ensures your state gets reset based on your scope. Another common use for this approach is for setting a wait cursor in a Windows form application. I’m sure there are many others great uses!

While this example is trivial, and only really saves 2 lines of code – I find it helps maintain readability as my project size increases, and reduced bugs if I forget to reset state because of an unexpected execution path – like when an exception gets thrown.

How to engage a software development company – Part 5 – How to specify requirements

Following on from what was covered in Parts 12, 3 and 4 we now I’ll look at how to specify requirements.

The clarity with which you can articulate your requirements will directly affect the depth of response your supplier can give you.  With this in mind, I’m going to provide a reusable template that you can use to specify your high level requirements that’s easy to remember, quick to do and will give your supplier a deeper understanding than the clichéd specification scrawled onto a restaurant napkin!

Here’s the template:

As a __________

I want to __________

So that __________

For example a small, online web store selling low volumes of widgets to the public may specify the following high level requirement:

As a store owner

I want to receive an email when a customer submits an order

So that I can print the order, so it’s ready to be filled

Depending on the size of your project, you’re probably going to end up with several dozen of these, so it’s advisable to start with a table:

The reason this template is so effective is that:

–          It identifies the roles present in your project. Understanding the different roles builds a picture of the different people that will interact with your solution, the concerns that they have and the actions they are likely to take.

–          It provides detail to the abstract. Stating ‘I want an online store’ is open to a wide range of interpretation. Specifying who can do what in your online store is measurable and can therefore be estimated.

–          It provides an opportunity for you to review your project within the context of your vision. For every item you should be able to answer the question, ‘How does this contribute to my project vision?’ If the item doesn’t contribute to your vision you’ve either identified a reason to refine your vision, or identified a feature for which the cost to implement should be evaluated against the actual value it brings to your project.

–          It provides an opportunity for a third party to review your project within the context of delivering it as a solution. An experienced supplier will be able to review your requirements and discuss recommendations on technical and implementation approaches, highlight items requiring clarity or additional detail (in the above example, how does the customer pay for the order of widgets?)

In essence, to solve a problem you first need to understand it. Following a systematic research approach allows you to establish the facts and expose the underlying goals and tasks which will support the development of a solution that is fundamentally focused on the needs of users.

How to engage a software development company – Part 4 – Understanding the software supplier’s process

Following on from what was covered in Parts 1, 2 and 3 we now I’ll look at understanding the software supplier’s process.

Understanding the supplier’s engagement process allows you to prepare in advance, quickly moving past the ‘sales’ and on to what they can actually do for you.  If you’re ready to get straight into it – these tips are for you.

The first thing a supplier is going to do is qualify you.  The supplier wants to know 3 things:

1. Do we have the capability to meet this client’s needs?

By capability I’m referring to the proficiency required to realise the project goals.  Typically suppliers work in ‘stacks’ – a number of technologies that can be leveraged to deliver a solution.  What they want to know is can they achieve your outcomes with their particular choice of technology stack?  A ‘no’ here is a show stopper, and it’s best to discover this as early as possible.

2. Do we have the capacity to meet this client’s needs?

Capacity is elastic in that suppliers’ resource schedules (and inversely, who they have available to work on a project at any given time) vary from month to month – and sometimes week to week due the fluctuating nature of project delivery.  The question being asked here is can we resource this within the client’s required timeframe? Often it’s a ‘probably’ – especially if there is room to be flexible as requirements can be phased and/or additional teams can be resourced to meet short timeframes. No one likes turning away work they can do, and suppliers will often work to design a compromise that works for both parties if capacity is an issue.

3. Has the client secured funding sufficient to meet their need?

Funding is a chicken and egg scenario because clients will often use a supplier’s estimate to inform their project budget, whereas a supplier will often tailor an approach to meet a specified budget. I like to have this conversation candidly and upfront.  I talk about our process, the various stages of a project and what sort of orders of magnitude other clients with similar requirements have had. This is a great approach that balances the supplier’s need to manage client expectations, with the client’s need to know what sort of money they will need to invest. 

The second thing a supplier will want to know is where you’re up to in the buying process, as this will determine what happens next. What happens next is about refining what is known and understood by both parties so as to achieve a reasonable degree of certainty about what can be delivered within a given time frame and for a specific budget.

Suppliers deal with hundreds of enquiries a year and need to make a judgement call about how much time they can afford to invest pursuing each lead. Preparing an estimate is a detailed exercise, often involving a number of people including business analysts, graphic designers, solution architects and the sales team.  Do not under-estimate the amount of work it takes to produce a quality, informed estimate. A supplier will need to stand by their estimate, so they will invest a large amount of effort in ensuring a reasonable amount of accuracy.  This underlines the importance of qualifying a budget, and where you’re at in the buying process – as it’s a reasonable expectation that if you ask a supplier to spend x days of work costing something for you, then it’s something you’re in a position to be able to go ahead with.

The next step is about determining to what level you and the supplier want to ‘de-risk’ your project. The level scale (from most to less risk) looks something like this:

Order of magnitude – Establishing a ball park can be achieved in a conversation and should be free.  It provides a rough indication of cost, and can span a range +/- 60% between a low and high figure.

Estimate – An estimate is more informed and typically accurate to +/- 30%.  Spending some money upfront to address perceived risks and confirm implementation assumptions can reduce this to a variance more palatable to you, and your suppliers, risk preferences.

Fixed price quotation – Producing a fixed price quotation requires the creation of one or more detailed specifications (akin to an engineer’s blueprints), which may be undertaken as an initial engagement. This is a substantiative piece of work and the outputs of such an engagement should be detailed enough that should you choose to, a second supplier can provide an estimate based on the created documentation.

Depending on the nature of your project and the number of unknowns – your supplier may require a level of certainty before agreeing to take on your project.  I’ve met with various responses to this – including righteous indignation and flat out refusal (it’s uncommon to pay for estimates in some industries). What’s often missed is that you’re not paying for an estimate – you’re paying for something to be discovered, defined and documented, which is a creative and collaborative process that you’re going to want to be involved in.

Don’t be afraid to spend a portion of your budget upfront to achieve this – as more becomes known, the supplier can be more accurate with their estimates, and you can control your level of investment and certainty with regards to deliverables.

So how can you leverage this information to start shortlisting, or engaging with a supplier?

  1. Be ready to go to market, this lets the supplier qualify you quickly – so you can take things to the next step, or cross a supplier off your list.
  2. Have a ball park discussion about budget. A ball park discussion will let you know if you’re talking to the right people or not.
  3. Let the supplier know where you are in the buying process.  It’s ok if you’re just gathering information at this point, but it’s important to let the supplier know that. Being up front about where you’re at is always appreciated and lets the supplier know how much information you need.
  4. Agree on what happens next. If the supplier makes your short list, I’d recommend a face to face meeting with the team that would be working on your project to discuss the level of detail required next.
  5. Remember, the supplier is evaluating you as a potential client as well.

How to engage a software development company – Part 3 – Select suppliers that play in your ball park

Following on from what was covered in Part 1 and Part 2, now I’ll look at selecting a supplier that plays in your ball park.

Shopping for suppliers is no different than shopping for anything else – you want to select a supplier that’s geared towards providing the best service available, within your budget.

Custom software suppliers, like most industries are organised into tiers based on which end of the market they serve, and what you pay for those services.

The entry level tier is mostly independent contractors, small development shops and offshore suppliers. At this end of the market suppliers tend to have fewer established processes, quality controls and lower rates, so can turn projects around quickly and cheaply.  It’s my experience that suppliers at this tier are capable of working in a more ad-hoc manner, with less emphasis on specification and more on outputs – which can be a good or a bad thing depending on your needs and requirements.  It’s typical to find that individuals at this level often wear many hats – your developer may also be your business analysis and your project manager.

When to consider entry tier suppliers:

  • If you have a very clear understanding of what you want to achieve, and are able to document it clearly, and with a high level of detail
  • Your budget is in the tens of thousands
  • You are prepared to accept potential quality issues, and a longer timeframe to have these resolved

At the other end, the top of the pyramid (tier 1) is dominated by a handful of major enterprise players (think Microsoft, Fujitsu, IBM), who often come with their own platforms attached.  Clients with a need for enterprise suppliers fall outside the scope of this series, as engagement is typically handled in house, by an experienced procurement and projects team.

The vast majority of custom software suppliers fall in the mid-tier.  At this level most suppliers aim to strike a balance between affordability and appropriate levels of process, management and quality control – with each supplier varying the degree of importance placed on each subject to their particular business focus and market approach. Any reputable mid-tier supplier should provide dedicated development, business analysis and project management staff.

You should be considering mid-tier suppliers if:

  • Longevity, relevant experience and a proven track record is important to you
  • Quality assurance, accountability and solid project management are priorities
  • Your budget starts at about $100,000

Differentiating between mid-tier suppliers is difficult.  Narrow down the field by asking the following 5 questions:

1. Do you have established and documented project governance, development methodology and quality control systems?

Having established processes is a sign of business maturity in a supplier and a great insight into how the supplier works. Most suppliers will have a standard process that they vary according to the project being undertaken. Project artefacts (the documentation produced), governance and level of testing will be scaled to meet your requirements.  What should remain constant is a strategy for periodic review points between yourself and your supplier, a stated escalation process and what’s expected of you in terms of your input and responsibilities.

2. Do you offer a warranty period?

A warranty period gives you piece of mind that bugs will be addressed in a timely manner. I strongly encourage clients to make full use of their warranty by stressing their software as much as possible during this period.  Be aware that suppliers will often classify a bug as something that doesn’t work as they expect and a variation as something that doesn’t work as you expect. Differentiating between the two underlines the importance of having a clearly defined specification.

3. Do you have any industry awards?

If you’ve never built custom software before it’s difficult to judge the qualitative aspects of a supplier. Industry awards are fantastic in that they are judged by people who do know. Recent industry awards are fantastic indicators of how a supplier is viewed by its peers.

4. Who owns the intellectual property created for my project?

Suppliers typically approach IP ownership by either giving you a perpetual license to use what is produced, by releasing all IP to you – or a hybrid of both when the supplier uses frameworks and accelerators developed in house in the realisation of your project.  Anything considered ‘common’ is licensed for your use, and anything created specifically for you is considered your IP. Avoid suppliers who state that they must retain the IP – that means they clearly plan to sell it to your competitors.

5. Who do you see as your main two competitors?

When shortlisting suppliers it’s important to be able to make an ‘apples to apples’ comparison – and the easiest way to achieve this is to ask the supplier who they see as their primary competitors. Approaching a number of competing suppliers is a fantastic way to validate the size and scope of your project and the expected resources it will take to complete. I’d recommend disclosing your intention to approach a supplier’s competitors as this transparency is appreciated and tends to be reciprocal.

Mid-tier suppliers often have a breadth of experience they can draw on and are typically happy to act as trusted advisors, and this is what you should be looking for with your questions.  You’re about to invest a large sum of money in a project, and you want a supplier that can act as a partner and advise on available courses of action and the ramifications and impact of each. Don’t underestimate the importance of relationship – ask yourself, “Is this a company that I want to have a close working relationship with for the duration (and beyond) of my project? Do they truly value the partnership, or are they only in it for this project with little investment in the future relationship?”

Comparing suppliers across different tiers offers little value as the suppliers’ process and overheads reflect their target market and thus the cost of engagement of a supplier outside ‘your’ tier is disproportionate to the value you obtain.




How to engage a software development company – Part 2 – Be ready to go to market

Following on from what was covered in Part 1, now I’ll look at being ready to go to market.

First and foremost you want to ascertain whether or not a custom software development company is right for you.  Custom software development addresses the problem where there is no pre-existing software that you can licence to enable you achieve what you require….or, you are looking to build something completely unique to sell in its own right. So researching readily available pre-existing options is my first recommendation. It’s typically cheaper and easier to change a business process to match an existing product than it is to create something from scratch. That being said, there are a myriad of reasons why custom software development will deliver a greater ROI for your business. For start-ups with an application idea – the process is similar.  Before you invest thousands of dollars into a venture, you want to ensure you have a strong market available for success, therefore competitive analysis and determining your key differentiator is very important.

This raises a dilemma commonly faced by start-ups – that is – how to balance the need to protect your idea, versus the benefits obtained from discussing your idea. I strongly encourage start-ups to discuss their idea with as many people as possible.Communicating your idea to others solidifies your own understanding of what it is you want to achieve. Additionally, you open yourself to insight and experiences that others may have, which can contribute to improving your idea, or killing it off early before you’ve invested heavily in it. Don’t let the fear that someone will steal your idea get in the way of taking action that will cause your idea to become a reality.

Having established custom software development is right for you, the more clarity with which you can present your vision, the more information a supplier has to work with, and the more detailed a response they can provide.  Before calling a supplier, you should be able to:

1. Articulate your vision in 3 sentences or less

Your vision provides the context for what you want to achieve.  Discussing this with a supplier gives you both a shared idea of what it is you actually want to achieve.  Your vision also becomes the yardstick for later in the process when you’re prioritising features, defining goals and establishing a minimum viable offering.  When discussing any features, you should be able to answer the question ‘how does this fulfil my vision?’  If you can’t, you’ve identified cruft to be eliminated or a reason to revise your vision.

Your vision should be specific, measurable and quantifiable – avoid abstractions and hyperbole.

2. Don’t mix how with what

I love the ‘who can do what’ discussion because it keeps things at a high level and forces people to think about the actual business requirement, rather than the implementation.  As an example, ‘a customer can place an order’ is far more informative than ‘the user picks products from a list then clicks a button that submits an order’.  In the second example – the business requirement of having customers place orders is lost within the client’s interpretation of how the feature should be implemented.  This detail is important later in the process, but for ensuring engagement readiness, having a high level list of ‘who can do what’ is enough to build a picture of the number and complexity of the features you want to implement.

3. Define the scope

Defining scope provides the boundaries within which the vision and ‘who can do what’ exist.  Ideally you want to provide numbers on expected levels of use, e.g. the number of users, amount of data stored, number of web pages etc.  It’s ok to estimate – but be realistic as designing for high capacity scenarios gets expensive, quickly.

If your solution is intended for use outside Australia specify if localisation and globalisation (e.g. multi language, time zone and non-Australian currency) is a requirement.

Include what platforms you are targeting.  Typically this is as simple as web or mobile (iOS, Android and Windows Phone being the most common mobile platforms), but can be more detailed when integrating with third parties, extending existing applications or designing applications for the enterprise.

Being able to passionately articulate your vision, ‘who can do what’ and scope is a fantastic start to engaging with suppliers. I strongly encourage clients to discuss this with as many people as possible – discussion solidifies personal understanding and will often draw out new and exciting ideas you may not have considered previously. Passionate discussion is infectious – and if you can share that with your supplier, all the better.

If you’re not ready to engage a supplier, that’s ok – there are still things you can do. AtKiandra we often deal with visionaries who don’t know where to start, start-ups who are unsure about what’s technically possible, and businesses with a requirement that outweighs their budget.  In these scenarios I advocate a project workshop.

A project workshop is a short, paid engagement that gathers the project stakeholders and a team of experts – typically a business analyst, solution architect and designer with the purpose of eliciting a vision, feature set and scope in a collaborative manner.  The experts provide insight and direction as to what’s possible, the impact and trade off of various approaches, and ball park figures regarding cost and timeframes.  On conclusion of the project workshop the aim is to leave you with a clear vision, some indicative figures, and a clear direction of where to go next.