6. Requirements from Stakeholders
• Identify key stages of process under
review
• Identify key stakeholders at every stage
• Gather requirements from stakeholder
representatives for each stage
• Manage areas of requirement outside
budget and of conflicting requirements
7. Focus on technological benefits
• How is this going to be better than current
practice?
• What would be needed to best
demonstrate value?
• Ideal scenarios (user stories)
9. Thank you very much!
Do you have any queries or comments?
Editor's Notes
Asking the question…
Individuals and interactions – at the end of the day, it’s people designing, developing, testing, supporting, and using the technology; people’s needs have to come first, and they will inform how and why it’s used and therefore what the requirements for the system are. Managing their interactions over the course of a project will be key.
Customer collaborations – everyone’s a customer… every stakeholder needs to be treated with the same courtesy and respect; the opinions of coalface users need to have similar weight to that of the project sponsor.
Response to change – most people find change a difficult thing to handle, and good communication is key if people are to adapt to change well. This includes taking into account opinion and need before the project, ensuring that the changes are necessary, as opposed to for the sake of change itself (although that can have a place), and putting in place proper training, documentation and development. [will return to documentation theme again…]
Contract negotiation – it’s key for managing a project that the scope of what will be delivered is agreed and documented, and is beneficial and feasible for all parties.
Follow the plan – while there may be necessary deviations along the way, a proper plan will help us stay on target and reach our goal. A good plan will also have redundancies built in…
Working software – obviously, what you want at the end of the day is something that works. This means defining what you wanted in the first place, but also being able to make compromises on nice-to-haves.
Processes and tools – at the end of the day, the technology is there to provide a function, and to make the organisation more efficient/ more competitive. It is a tool that should be informed by needs and shortest path through necessary steps of the process rather than forcing a technology based solution that is equally or more unwieldy than the current/ non-tech process.
Comprehensive documentation – whether this is electronic or hard, this needs to be held centrally, accessible to and updateable by all stakeholders, controlled and versioned correctly, etc.
[more on next page...]
Transparency – all communication, documentation, decision-making, etc., should be transparent and accountable.
Gathering requirements – the project manager/ team should gather together all aspects of what is needed by the system at the beginning of the process, using tools such as process maps, user stories, etc.
Identifying stakeholders – finding out who all the relevant parties are, from project sponsor, through designers, developers, testers, end users, and those who will support the system when it goes live.
Negotiating and documenting scope – it is important to know what is within the scope of the project – agreed deliverables – and what is without it. Those requirements within scope also need to be prioritised so that, if there are any unforeseen resources constraints later in the project, we will know what can ‘give’ There is the middle ground also of nice-to-have which can shift into future deployments, etc. Scope creep can happen to any project where the manager/ team is not sufficiently assertive and thorough at the beginning of the process.
Identifying resources – finding out what resources are available (time, money, people, premises, tools, etc.) and negotiating availability of these.
Balancing TCQ – the classic triangle of project management: all have their own pulls on the scope and the success of the project, and need to be managed. For each individual stage and stakeholder, these will differ, and need to be negotiated, kept track of, and balanced.
Speaks for itself – a constantly-updating process; a cycle of development.
It’s a tool, and not as important as the people involved or the end goal to be achieved. Need to take into account integrations with existing (hard or soft) systems, and whether the technology will actually improve efficiency (this includes usability). This can be captured using process maps and user stories – demonstrating the “happy path” through the process.
Can see where improvements could be made using technology – centralising/ amalgamating current practices, money/ time-saving, etc.
Authoring (item writers, administrators) – requires library technology and set “types”
[via publishing to tests]
[via scheduling to sessions]
Booking sessions (administrators, candidates, institution) – requires timetable, venues, payment system, integration
Delivering and test-day administering (administrators, invigilators, candidates, institution) – requires materials, venue, viewing/ hearing, and answering system.
[via response delivery to responses] – requires collection system
[via marking to results] (examiners, validation team) – requires automarker, live examiners, validation, etc.
Delivering Results (candidates, institution) – requires production method (paper/ screen) and delivery method (post/ site/ email)
All to be delivered securely, with an easy-to-access support system (support staff) – requires training and documentation
Realise that this was a short time to go through something usually covered in two-day-long courses…!
