Understanding user needs: the first first step towards IT clarity
The users may be only 20% of the stakeholder
interest group and they can be the least willing to fight their
corner. Start right and put the project on the right track with some consultation.
If you want good software written for your business, you have to start somewhere. In my experience, most clients start with big aspirations, a budget for some programming and an open-ended time frame. What they tend to need is a list of requirements, a small budget to get advice on those requirements and a good design specification written, and some contact time with the actual users, leading to a phased, time-limited project of design, testing and development.
Even a very small software project with a protected budget of £1000 collects many, many stakeholder groups. Firstly, there are the users, but with smaller systems, they are outnumbered by the firm's other staff, managers, the software development team and in some cases, customers, business partners, remote suppliers and even creditors who have an interest in the success of the project. In matters of finance and data storage it would not be uncommon for the bank require access for compliance reasons. It does not take much before the users are only 20% of the stakeholder interest group and they can be the least willing to fight their corner.
You see, investing in software development should not be a purely upper-managerial exercise in blue-sky thinking and shamanistic guessing, even if it is the ivory tower where the buck stops, the budget is approved and the cheques are signed. Good software development starts and ends with users. What do they need? What are the itches that need scratching? What business processes waste time? And the management are rarely the best people to ask those questions. Office politics and oneupmanship even in the most culturally sound businesses can subtly colour those kinds of knowledge exchange. "If John knew that sales reporting takes me four hours on a Friday, he'd hit the roof!" - yet without that crucial information the process cannot be optimised or even automated, and those four hours will be burned every week for ever more.
It pains me to say it (because I see the expression on your face) - it is time to call in a consultant. People like us transcend office politics, ask the telling questions and can get staff to relate honestly, without fear or favour. Technology consultants have those analytical skills which allow us to break requirements down into a language that a programmer understands whilst simultaneously talking at a technical level that will not bamboozle your staff. Give one of us a desk, a phone and a sandwich and we won't stop until we know your business, your market and most importantly your staff - they will become the users (collectively, the "userbase") of the software product you order. Some of the information that allow us to make an informed analysis of your needs include:
- What your users expect the software to do
- How much change users will tolerate
- What they expect to supply by means of data, and in what format
- What kind of output would be most beneficial
- How users will employ the output
- The design of the user interface - can we "match" or extend the interface of another program they use?
- What other systems must be interfaced with
- How the program fits into larger business context
- Peripheral reporting and maintenance requirements
Done right, this kind of questioning has two results; one obvious one, and one ancillary benefit:
- The software specification will be more focussed and requirements-lead
- Your staff will feel valued and... consulted - effects we call "buy-in" and "ownership"
The converse, which we try to avoid at all costs occurs when new working procedures and software systems are imposed without sufficient user consultation:
- Change management failure and user resistance
- Steep productivity dip with slow recovery
- Higher cost of software development due to unspecified changes after roll-out
Work with Kohera and be insulated from spiralling costs and interminable development cycles. And remember: to protect your budget, avoid skimping on that all important aspect of software design: the requirements of your users.
Write a comment