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.

How to engage a software development company – Part 1 – Introduction

If there’s one thing that rings true for most organisations investigating custom software development, it’s that engaging with vendors can be a daunting process – you’re committed to your project and want the best possible outcome, so how do you select a vendor that understands your needs and that you will have confidence in to deliver? I’d like to share a couple of guidelines that will assist you in answering these questions and achieving successful outcomes.  The guidelines I’m presenting in this mini-series are designed to give you an insight into the ‘how, when and what’ to ask of vendors to ensure you have consistent, relevant information to compare so you can make an informed choice.

Topics I’ll cover over the coming weeks include:

  1. Being ready to go to market
  2. Selecting suppliers that play in your ballpark
  3. Understanding the software suppliers process
  4. How to specify requirements

In covering the above I’m making an assumption that you’re going to approach a number of suppliers in order to get an idea of their capability and experience in achieving your goal, an idea of what your project will cost to realise, and the timeframe within which it can be achieved.

If you:

  • Are tasked with sourcing a software solution for your business or;
  • Have an idea for a software application, but don’t know where to start or;
  • Are writing an expression of interest (EOI), request for tender (RFT) or any variant of these that involves a formal, structured invitation to suppliers

Then these guidelines will help, and are relevant to you.