How igeek like to work

If you've taken the plunge and decided on a new app for your business or organisation, then this is the sort of thing that happens before we write a single line of code!

1. We talk to the users.

In the case of most small to medium businesses, first contact with a development company will be from a director, the MD or the business owner. But often, the people who'll use the FileMaker solution every day aren't involved with the development process and may not even be aware the boss has called us. It's absolutely vital that we engage with the people who'll be actually tapping away at a screen every day.

2. We talk to all the users. Really, all of them.

If the system will have anything to do with financial matters, we'll need to talk to the finance department. If warehouse staff will use the system, we'll come and see how they work. If office staff will be using a CRM facility, we'll sit down with them and find out what they need and how they work. And of course, we'll talk to the business owner and see what reporting is required and what he or she would like the system to achieve.

3. We find out how things are done.

Every business is clearly different, but there's usually a business narrative that can be written down or drawn up, often as a service or product moves through the organisation. It may not be strictly chronological, but the chances are, it'll be there. We'll study what processes are carried out at what step. What tech is being used at the moment (Excel sheets ahoy!), and what pieces of paper or emails move where? It's often that when we're documenting this, that's when data structures start evolving in our minds. But if so, we'll be sure to be careful and won't commit to a development method just yet.

4. Set some goals.

We'll also need to make sure that our client is clear about what they actually want to achieve with their new system. Most of time, that's about freeing up peoples' time. That may be from having to enter data twice, or having to constantly sift and send standard emails. If time saving isn't what's required, what is? No-one is going to spend money on a database that may cost thousands without some idea of what it needs to achieve. We'll need to establish what the desired outcomes are.

5. We may walk away before we start!

If on examination, we don't feel we can develop what's needed, we won't try. It may be that we don't have the skill set in our company or that what we offer really isn't the best technology to serve the a client's purpose. FileMaker and the web provide a broad range of tools, ample for most scenarios, but it isn't always the answer. We'll only make problems for ourselves and annoy our clients if there's a square peg and a round hole.

6. Do it all again.

The scoping exercise will comprise of multiple contacts with the our client. People forget to give us details, or not mention a particular instance in the workflow that might trigger a different action. That's normal and human. It's important for us to revisit each user, just to make sure there is nothing (or as little as possible) that we've missed. Our customers and their staff will enjoy talking about what they do all day and apart from anything else, it's a welcome break from the daily routine!

7. Agree.

After we've pulled together all the information, we'll tell you, the client, what you already know! Or rather, we'll tell you what we think we've been told. This author was once told by a wise woman (hi mum!) that the best way to see if you knew something was try to teach it to someone else. If we can't, we'll need to ask some more questions. Then, we can agree what the you, the customer wants, not what we think you need. We can also agree timeframes. This segues nicely into…

8. Our retreat to have a team meeting.

We'll work out how to approach the project with our technical and ancillary staff. We create a viable timeline, with way points, and agree on a method of monitoring progress. Different developers will want to do things in different ways, and if possible, there should be an agreement on technical issues that are apparent at this stage. If necessary, we would refer back to you with any red flags thrown up by this process.

9. Explain our method.

We'll explain to you how you're going to work and how that will involve you. We'll make sure we have an agreement that what we propose is acceptable. There may well be a project manager in our customer's organisation, which is very helpful, but all end users will need to be involved in the development process and that there'll therefore need to be a time commitment from all. We'll agree communication methods and channels. If we're phasing the project in, piece by piece, we'll make sure that you, the client, knows what's happening and when.

I hope this blog post has been useful you as a potential customer of igeek. It's born of many years experience!

 Add a Review of this item