managing technology projects
Post on 12-Apr-2017
Embed Size (px)
Managing Technology Projects
Managing Technology ProjectsHow should assessment technology projects be managed to ensure they deliver real benefits to all stakeholders?
Asking the question1
ManagingIndividuals and interactionsCustomer collaborationResponse to changeContract negotiationFollowing the plan
Individuals and interactions at the end of the day, its people designing, developing, testing, supporting, and using the technology; peoples needs have to come first, and they will inform how and why its used and therefore what the requirements for the system are. Managing their interactions over the course of a project will be key.
Customer collaborations everyones 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 its 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
DeliveringWorking softwareProcesses & toolsComprehensive documentation
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.
TransparencyGathering requirementsIdentifying stakeholdersNegotiating and documenting scope
[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.
Key aspectsIdentifying resourcesBalancing Time, Cost, and Quality
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.
Requirements from Stakeholders
Identify key stages of process under reviewIdentify key stakeholders at every stageGather requirements from stakeholder representatives for each stageManage areas of requirement outside budget and of conflicting requirements
Speaks for itself a constantly-updating process; a cycle of development.
Focus on technological benefitsHow is this going to be better than current practice?What would be needed to best demonstrate value?Ideal scenarios (user stories)
Its 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.
Key StagesAuthoring TestsBooking SessionsDelivering TestsDelivering Results
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
Thank you very much!Do you have any queries or comments?
Realise that this was a short time to go through something usually covered in two-day-long courses!