In day-to-day business I have the constant challenge of ensuring our IT systems meet the functional and non-functional requirements set out by stakeholders whilst at the same time ensuring they are delivered on-time, to budget and are useable by all those who need it – the latter being the hardest deliverable of them all because everyone has an opinion and a varied degree of technological intuition…
A badly managed project implementation will over-engineer a system with contradictory change requests and in turn, run over budget. So what are the danger signs and subtle differences between building an intuitive system vs. training the user?
1. Fragmented testing sessions
No testing arena is successful if the testers are constantly interrupted by other matters. Testing is rarely seen as important to a scratch test team of stakeholders and key users of a system. They will have interruptions from emails, phone calls or face-to-face conversations. Set out the rules of the testing session clearly, and ensure people stick to these.
Worse still, having to run the same test session multiple times because people cannot make the same session at the same time. If the test session will be discursive, not everyone will have the benefit of hearing the same topics of discussion and therefore a likely contradiction of change requests could occur and without careful discipline in issuing those change requests, a lot of unnecessary work could be done and therefore a lot of money spent and a finally a deadline not being met.
2. Badly written (or absent) user guides
Any system needs a degree of user education and the first step to this is to write an effective user guide and distribute this to the users. Be mindful – a user guide needs testing too, so a good starting place for end-user testing is to ensure each has read the user guide and had no outside-assistance ahead of the initial testing phase. This is a powerful way to identify ambiguous areas of the user guide, or indeed gaps in the guide completely.
Expecting users to understand the philosophy and functionality of a system without the necessary literature available is akin to expecting a blind man to walk to the shops without a guide.
Ensure users actually read the user guide – ask them to refer to it when they get stuck. All too often do people rely on asking for an answer, when in reality, after a system goes live, this benefit might not be available.
3. Ineffective test scripts
A test script that is too open ended will not be effective, for users will not know the required inputs and outcomes of a particular test. For example, wording a test item as “Fill in a timesheet” could lead to an array of different tasks undertaken – do the users need to add in any tasks to their timesheet? Is there a set number of hours they need to fill in? What happens after entering the time – do they need to save it?
A better test item would read “Navigate to the current timesheet period and enter 8 hours of work to any existing tasks in the timesheet screen and submit the timesheet for approval.” This is a much more solidified approach – the test’s purpose is to ensure the filling in of time and submission mechanism are functioning correctly – the time is entered, saved and submitted to a supervisor.
Of course, test scripts require more than a simple instruction – each needs a test number, a purpose and an expected outcome. There needs to be room for a user to write the actual outcome and any difficulties they uncovered along the way.
The test environments need to be managed too – all too often today, we see incompatibilities between web browsers and web-based systems. Test the browsers and make it known to your users which ones work and which ones don’t. Users today all have their favourite browser and most of the time, it depends which ones are trending.
Under-budgeting is a real issue with system development. Many-an-occasion have I witnessed a budget that fits perfectly well with the cost of the initial design and development but fails to identify the need for post-testing development. The common reason for this is denial by financial teams. It makes a project far less likely to be given a green light if the budget comes out unjustifiably high. The budget-writer need to factor in the realistic costs, with justification, to the financial teams. If pitched incorrectly, their project is likely to be turned away.
Someone with a track record of over-spending is less likely to have a project accepted later down the line.
In the case with an existing project, it is also far better to get things right. If there is a limited pot of funds to complete a project, be upfront about the costs. After all, there seems little point in spending £10,000 on a system that is 80% complete when you could have budgeted £13,000 for one that is a polished, complete solution.
5. Management time
How many of you have heard the excuses about management time? I’d expect we all have, and we’d all be retired early, if we were given a pound for every time we were given lack of management time as an excuse.
Unfortunately, whilst frustrating, this is a reality and perhaps management need to be encouraged to pass a responsibility to a different member of their team, relinquishing control but at the same time request regular feedback. Management are there to oversee the business and not to get involved with the day-to-day details.
6. Mismanagement of expectations
The most important lesson in system development is perhaps managing expectations – a system is not going to be perfect, slick and bug-free on the first day of release for general use. The amount of testing involved would be unjustifiable. This is not only the case for internal corporations but for systems exposed to public use too.
Most of you will have experienced a store for mobile device applications – most commonly of course, Apple’s ‘App Store’. Apps are released, people purchase or download them and then a level of feedback is given to the vendors either through fanatics getting in touch directly or the more-destructive form of public reviews.
Even apps are subject to product updates -so certainly internal systems will be as well. The best way to handle this is to be upfront about the fact. Say: “This is the first working version of this and despite testing, we expect to uncover a number of areas to improve. Therefore we value your feedback.” A phrase like this not only tunes users into channeling their frustrations into useful comments but also makes it easier for the development team and project managers to swallow their pride and accept the imperfections and feedback.
7. Scope creep
A guilty habit of stakeholders when analysing systems is to get carried away with what the system is doing and verbally sprouting new ideas and concepts that the system could do. A really difficult trick to master is reining in of those who are doing this. Be aware of this trend and constantly bring the discussion back to one based on the initial requirements as set out in the pre-design analysis.
Over-engineering of a system will only lead to not only yet more money being spent on a system unnecessarily but also only a core group of people understanding the motive behind half of the functionality (and therefore finding it harder to use).
The scope of a system can be extended at a later date, of course – once there is money in the pot to spend, and the initial system has met it’s delivery deadline.
It leads us into the final point quite nicely…
8. Rome wasn’t built in a day – start off simple!
Tying in with the above comments about scope creep – remind those who are constantly trying to change the functionality of a system that Rome wasn’t built in a day – it’s a cliché phrase, but its one we all appreciate.
Bombarding a user group with a new system, especially if it is replacing an existing but equivalent tool is daunting enough. Now making that tool a lot more complex (because functionality and complexity are directly proportional) is going to make the acceptance and compliance with a new tool fairly unsuccessful.
It would be far better to create a simple, well rounded solution that the intended user groups can relate to and understand. By all means release a document outlining the future of the system – highlight identified needs and wants but don’t make the first draft of a system overly complicated. The system will fail!
These are 8 handy hints when it comes to managing the development and implementation of a system. I hope some of you can relate to these points and take something from them in order to make you next projects a more successful experience.