Sometimes an off-the-shelf solution will suit an organisation’s needs perfectly. However, more often, some type of customisation or software development will be needed. When deciding how much software development is appropriate, it is vital to ask questions and challenge current business processes and systems.
Sometimes an off-the-shelf solution will suit an organisation’s needs perfectly. However, more often, some type of customisation or software development will be needed. When deciding how much software development is appropriate, it is vital to ask questions and challenge current business processes and systems. We sat down with Tim Lawrence to find out how to bridge the gap between the business needs and software development spheres.
Core business analysis is the first, and perhaps most important step. It’s also the primary focus of my role. Time and time again, I’ve seen organisations run off the blocks trying to figure out how they’re going to implement or develop software, without firstly taking a step back and asking themselves “what do we want to achieve?” Make sure you know exactly what the organisation needs are before you even start thinking about software development. Rather than focusing on what a system can do, start off by discussing your overarching goals and your client’s requirements. By figuring out what it is the organisation really needs, you’ll be able to effectively communicate those needs to the software development team.
While it’s definitely possible to communicate without any knowledge in the area, I find that having a background in software development really helps. It makes it so much easier to understand any challenges the software team is experiencing, and allows me to really help them through those challenges. I did a combined Economics and IT degree at university, and I’ve also dipped my hands in a bit of software development, so I’ve got a good understanding of both sides. That middle ground between working with technical teams to actually develop things myself, and working on the business side, has enabled me to build skills in managing technical teams. Over the years, I’ve learnt how to communicate with them effectively to get the outcomes I need, without necessarily understanding the technical detail of everything they’re doing.
Requirements gathering is a relatively core skill in the business consulting world. Typically, this involves tasks such as looking at their current business, identifying problem areas, mapping out processes and pinpointing specific problems. What we find, and what the client finds, may or may not be the same things. It’s important to maintain that balance between listening to the client and the things they want to target, and doing your job and looking beyond what the client sees.
It’s hard to say if there’s a standard because every market is different. But what I’ve found is that lots of people struggle with understanding their own organisation, which can be counter-intuitive. Sometimes you work with organisations that have been built from the ground up, having done things a certain way and going by feel. When they eventually develop into large organisations, they’ve been in their routine for so long that they don’t necessarily have that introspective capability, or access to data that would allow them to self-examine. This can happen in a commercial environment where you have a small company and, of course, in government where you have small teams that might have been set up for a particular purpose.
In the reporting space, what you’re really trying to find out is what has happened. Before you start asking more interesting questions, you need to know the numbers of what’s been happening, and where. This will help identify your norms, which will allow you to start looking at trends and the impact of certain business decisions on those figures. You really need to focus on the core questions first.
Much of the work I’ve done has been in the business intelligence and reporting space, which is something that doesn’t always get considered in a software project. In an ideal world, organisations would take into consideration the things they want to measure at the end of the process, as they develop their systems. However, it’s very typical with a software project that the priority is getting the system there. Often this means making reporting the secondary priority, and sometimes you have to come in and figure out what you can count. It’s always something you try and keep in mind and try and push but it is one of the challenges.
It’s important to look back at the core concepts – don’t lose sight of the organisation’s needs. There is always the temptation to look at the shiny new toys and figure out how you can use them rather than figuring out whether there’s a real need to use them. You need to make sure you’ve got a strong business case about what you’re going to try and do.
Apis Partner, Dr Nigel Nutt, recently presented at the Science in Australia Gender Equity (SAGE) Annual Symposium
Canberra firms Yellow Edge and the Apis Group are delighted to announce the launch of a joint scholarship for participation on the 2017 Global Leadership Practices China (GLP) Program.
It is with great pleasure that Apis announces a number of recent staff promotions to support the growth of its Canberra based professional services team.
Apis has come on board as a Territory Breakfast Sponsor for the Rosie Batty Roadshow Breakfast in Canberra, reflecting its commitment towards active community involvement.
It has been a busy first half of the 17/18 FY for the AITC team and generous Apis staff
Flexibility comes in many forms and is a fundamental part of the modern workforce.
Hassan Adhami provides an insight into the type of work that Apis does through discussing the work that we undertook in partnership with the Clean Energy Regulator.
Annya gives her insights into Apis and what it means to her to work with us: