Reflections on Project Management Methodologies

In previous posts you will have heard how our approach to project management and business analysis has changed over the past 18 months. This post aims to give an update to readers about current T-SPARC project management methodologies.

When I initially started with T-SPARC I felt that it was important to make process mapping work for the relevant stakeholders groups. At the time that meant internal staff that we were consulting with on their views of current process, the hurdles they face through the lived experience of curriculum design any their opinions on how processes could be improved. Convoluting university processes with complex system diagrams didn’t seem appropriate, so we opted for a softer, user-friendly approach with relatively simple swim-lane diagrams. These were purposely designed to be easily interpreted by members of staff being consulted. It was during this process that we realised the process maps weren’t there just to communicate processes, but to encourage dialogue between stakeholders.

The next stage was defining the business requirements for the proposed new processes. From the information gathered during the stakeholder engagement events (including the multimedia review that was conducted during 2009), a vision of the new processes was developed that detailed how Microsoft SharePoint would be used to augment the new course design and approval processes.

The project then employed a SharePoint software developer as a contractor to work on the project alongside existing university staff to add capacity. At this point we had used PRINCE2 as a project management methodology with varying levels of success. Things such as the management structure, risk register, issue log and work package protocol were defined to PRINCE2 standards, but our CICT department felt that this project management style would not suit the [rapid] development of the new SharePoint infrastructure. Collectively, CICT and T-SPARC felt that a new approach should be sought to allow the iterative and ongoing development of the workflows. Agile (Scrum) methodology had been looked at by our CICT department in the past and used by members of their team and a decision was made to manage the T-SPARC SharePoint development using Agile methodology.

Agile allows for regular ‘Sprint’ meetings where developers, business analysts and project manager(s) evaluate previous Sprints, and define the next ones. A Sprint is a series of objectives that must be achieved to produce the next iteration of the software (or product). This approach allows a series of prototypes to be designed and tested on an ongoing basis, this in turn allows functionality to be defined iteratively and gives project teams the ability to test each iteration of the software with users and feed back to developers to add to the next Sprint for implementation and then further testing.

In addition to the regular Sprint meetings, Agile allows for daily ‘Scrum’ meetings where developers and BA’s (business analysts) meet to discuss the previous days progress, and targets for the current day. This approach has led to the rapid development and rapid integration of new features into the system.

Something thing that has been noted is that the Agile approach can lead to a lack of definitive project documentation! The nature of the rapid development means that rather than the product specification being designed and defined during the initiation of the project – post requirements gathering and analysis, the specification is defined with input from stakeholders on an ongoing basis. This leads to a Sprint log being developed, to be used as a set of Sprint deliverables, which can be updated at the end of each Sprint to define the next set of deliverables. However to counteract this lack of documentation, with Agile, you do get a series of prototypes that are developed and tested by stakeholders which ensures that the end product is fit for purpose.

We realised that two key aspects of Agile are communication between and commitment from developers and project staff. We started using the Sprint and Scrum meetings but then realised that ongoing and more responsive dialogue was needed and for this we decided to use Skype as it allows for ‘share screen’ functionality which has been extremely useful for answering quick queries without having to leave our desks.

Another observation that we have made; tightly constrained project management methodologies can restrain competent and confident members of staff. Certain staff need to be empowered with the freedom to make decisions, project teams need the need ability to be able to relax the constraints of the methodologies and be creative and to encourage the ‘doing’. Project managers need to be able to relax the constraints of particular project management methodologies to allow this, especially when using the more fluid and dynamic Agile methods. The flip side is that less competent and confident members of staff may rely on more tightly defined project management methodologies to define processes and work packages. You need buy-in from all members of a project team, and all involved need to be practiced in Agile methodologies for it to work properly.

For more information on Agile project management methodologies click here.

Oliver