Stakeholder interview - Project team
Members of the project team were asked a few questions about their involvement with the workload model and system.
Questions and answers
Project Manager - WLM-SAPI
How did you get involved with the workload model?
"In April 2012, I was asked to be Project Manager for the project known as WLM-SAPI (Workload Model – System And Process Improvement).
"The key project deliverable was to implement a web enabled database solution to support the UWE Workload Model, in order to eliminate the limitations of the existing spreadsheet system. The new system was called WAMS (Workload Allocation Management Service)."
What was the WLM-SAPI's project aim?
The aim of the project was:
“By April 2013, the UWE Academic Workload Model is supported by an adaptable, single, web-based, multi-user software solution that can be accessed by all UWE academic staff on national academic role profiles up to and including NARP5."
I was responsible for :
- Defining the DSDM (Dynamic Systems Development Methodology) project approach
- Planning the project (in conjunction with the project team)
- Monitoring progress against plan
- Producing the Project Initiation Document (PID)
- Preparing incremental Timebox plans
- Creating and maintaining a project Risk Register and Issues Log
- Creating project status reports as required
What was the project approach?
The project approach was:
"The WLM-SAPI Project Board agreed to adopting a DSDM project approach.
"Academic user involvement was agreed, planned, costed and documented in the PID. The academic user commitment and agreed participation was critical to the project success, since these roles provided the lowest-level detail and prioritisation of the requirements during development timeboxes. These representatives became the Faculty/Academic Ambassadors for the duration of the project. The Faculty/Academic ambassadors were asked to:
- Represent their faculty user community during the system prototyping and development iterations
- Provide help and guidance to the developers during the system prototyping and development iterations
- Represent the faculty for business readiness prior to system deployment
"The DSDM lifecycle is iterative and incremental. WAMS was delivered in a series of increments with increasing functionality. Urgent business needs were addressed early while less important functionality was delivered later. The iterative nature of DSDM enabled users to see work under construction and provide feedback to the developers. Using Agile Project Management within a DSDM framework enabled the on-time, on-budget delivery of the WAMS functionality required at the go-live date, by constantly reviewing and flexing the system features (scope) throughout the project.
"Regular weekly WAMS progress review sessions with the developers and Faculty Ambassadors were held throughout the project in the IT training room. Good use was also made by the team of other collaboration tools eg SharePoint, videoconferencing (Lync), virtual whiteboards (Scrumblr), Wireframing etc."
What communication tools did you and your team use?
- Regular weekly WAMS progress review sessions with the developers and Faculty Ambassadors were held throughout the project
- Weekly project status reporting to Project Board and Project Team was initiated to keep all stakeholders aware of progress against plan
- Meetings (online and face-to-face) with the Project Board were held at key milestones and decision points
- A dedicated “Business Readiness and Communication” sub-group was formed to define and direct the comms to the wider UWE community so there were “no surprises” for stakeholders outside the project team during the system implementation
What lessons learned would you like to share about the experience?
"DSDM and Agile Project Management tools and techniques can deliver a project on time and on budget as long as all stakeholders accept the DSDM philosophy. On-time delivery of an acceptable solution is the primary measure of success for the project."
For DSDM to work:
- The development must have a clearly defined timescale
- Requirements are able to be prioritised and there is flexibility to accept that not all requirements are "must have"
- Appropriate resources (business and technical) are committed and assigned to the project for the duration
- The solution delivery team are empowered to make decisions on the depth of scope
See additional UWE lessons learned on the UWE workload model experience.
Business Analyst - WLM-SAPI
What was your involvement in the workload model and system/tool (WAMS)?
"As a Business Analyst on the UWE WAMS project, my main role was to help users think about the requirements of the system and how it might work for their day to day roles."
How did you/do you still support the implementation of the model and system? (including techniques applied)
"We started with about 100 high level requirements which were collated from various sources including the existing spreadsheet system, users of the workload model and other stakeholders. The first thing we did was to agree with the Project team what business roles the system would require and what those different roles would need to do. We then designed the system around these roles and used a wireframing tool to show users what it might look like.
"As the project progressed using DSDM development techniques, we were able to build and test the system incrementally making sure that we reviewed the prioritisation of the business requirements at each stage. This enabled us to incorporate some significant changes during the system’s development and resulted in delivering the business users a solution which more closely meets their needs."