Archive for the ‘ Process Mapping ’ Category

Reflections on Project Management Methodologies

Written by tsparc
September 6th, 2011

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.


We recently received a reply to our last post on ‘Adapting Process Models to work for your Project’ which has got me thinking again this afternoon…..

It was suggested that a good piece of software to get the process (excuse the pun) of process mapping started is MS Visio 2010 – something I’m looking to getting installed later this afternoon hopefully!

I’ve previously blogged about how we used a version of UML, that has elements of BPMN within it. We arranged it so as the swim lanes were coming down vertically from the top on the page, and the process moved down the page chronologically towards the bottom. This allowed us to integrate some sense timescales into the diagram.

I suppose this first facet of work we undertook was looking specifically at engaging with stakeholders involved in the approval/reapproval process. For this reason we actively looked at making the processes as transparent and easy to understand as possible, to try not to alienate people (looking at the diagram and thinking ‘what the heck is that!)

We held our first engagement day last Friday with members of staff from 2 faculties and found that the diagrams conveyed a manageable volume of information, without overwhelming people – allowing them to comment on where they think systems and processes could be streamlined and/or improved.

After another 3 engagement sessions in the coming weeks, we will be in a better position to gauge staff attitudes towards these processes, and to make informed suggestions about which directions and areas of programme design we should be seeking to develop and evolve in line with the T-SPARC rationale.

Another point you may like to take into consideration is that when you look at translating a business process model into a useable workflow diagram make sure that the you are designing it in a form that the end user will be able to understand. What I mean by this is that if you design a level 3 BPMN model, and pass this on to your CICT dept to translate into a MS SharePoint site, and they don’t have a clue what BPMN is, then it may become obsolete fairly quickly. This may not be an issue that you come across, and hopefully one we won’t encounter either, but give it some consideration early on in the process and it could save you some considerable effort later on down the line.

We will be uploading our V1.0 workflow models onto Circle at some point in the near future, so keep your eye on our blog for more info, it would be nice to hear your comments.

Also, please share any progress updates that you have in relation to process modelling, anything that you find that you think may be of use to share with us. I’m keen to look further into ‘upgrading’ our process models to BPMN in the near future, as long as that’s the best way of conveying the relevant information!


Adapting Process Models to work for your Project.

Written by tsparc
April 8th, 2010

I’ve recently blogged on this website about the issues involved with designing a Business Process Modelling language that meets the requirements of your specific project (when looking into the approval/reapproval processes).

T-SPARC’s workflow diagrams started with a basic flowchart, but as the intricacies of the process began to reveal themselves, we soon realised we were going to need something that had the ability to convey more information than just the processes involved and the links between these processes.

We looked into studying a UML Business Process Modelling course here at Birmingham City University, to better equip ourselves with the knowledge to undertake the process, but unfortunately the course was orientated towards a Software Modelling perspective rather than Business Process Modelling. With time ticking on, and after reading sections of several textbooks, I decided to continue with the process and look at designing a bespoke process language that would use elements of UML to encapsulate all the information that our CICT department would require to turn a workflow diagram into a working MS SharePoint site.

After a brief meeting with CICT, they agreed that the system we’re in the process of developing should be in a form that will eventually allow them to convert the workflow diagrams we produce into a working MS SharePoint site. We are looking at conducting a brief trial study to ensure that the information is conveyed to the programmers as effectively as possible, to which we will receive feedback. Regular contact with our Academic Registry has also provided some positive feedback on these ideas, and several members of their staff have helped with the process of collating the relevant information on the different workflows/processes etc, commenting positively on both the depth of the work we are undertaking, and the clarity and user-friendly nature of the workflow diagrams.

So far, we have not mapped the whole current approval/reapproval process using the new modelling language, as it is in the process of going through some changes at the moment anyway. Once these have been finalised we will be moving full steam ahead and I will upload any workflow diagrams that I think may be of interest for other institutions conducting similar work, in Design Cluster B or otherwise on to Circle for your persual.

We received a Tweet from Sheila MacNeill from JISC CETIS yesterday afternoon. After a conversation this morning about modelling languages/modelling approaches, Sheila clarified that the approach of designing a language that is fit for purpose is totally acceptable, and sometimes a necessity when looking at workflow processes. One of the problems I highlighted to Sheila is that if we did a very ‘high end’ UML business process map, to convey the processes involved to our CICT department, they would have to be trained to the same extent in UML that we had been, and this would create a huge accessibility barrier to nearly all of our other stakeholders, and also possibly some of our CICT programmers. With our system, they have already had some input at an early stage into how the workflows will be designed, and we will continue to keep them engaged in the process as it evolves.

Over the coming weeks I’ll keep you updated on progress, and any information I think you may find useful or relevant. Please let me know if you have any questions, or would like to make any suggestions.

A couple of questions to conclude:

If you have already completed this process, or something along similar lines involving Business Process Modelling, what modelling languages did you use, if any? How did your IT departments find the process of turning a workflow diagram into a working SharePoint system – did it convey all of the appropriate information?

If you haven’t completed this process yet but are looking to undertake something similar in the coming months, what modelling languages do you intend to use? Have you picked one specific language? Have you considered adapting it to suit the need of your institution (convey the right information) and the end users? Will the people using it, find it useful?


Building a process model that works

Written by tsparc
March 31st, 2010

I had a really positive meeting with the Head of CICT Project Management yesterday here at Birmingham City University. I wanted to ensure that the work we’re currently conducting in the area of process mapping is going to be in a form that will easily (!) translate into a transferable workflow that can be mapped onto MS SharePoint.

The first series of documentation we’re producing are fairly detailed flowchart diagrams, detailing the processes involved, and the way they interact with each other. However this information alone will not be enough to enable CICT to be able to map the new SharePoint site with the workflows we’ll be looking to implement.

In order for CICT to be able to complete the SharePoint site they will also need to know (amongst other things) what documentation will be involved at every point in the process, and exactly who will be involved at each stage in the process.

This in itself is not a particularly arduous task, we have looked at a number of different modelling languages, and after speaking with CICT believe we now have a hybrid (using aspects of UML) that will detail exactly what we need to convey to the SharePoint programmers. We are looking at creating some test diagrams in the coming weeks that CICT will pass on to the programmers who will eventually be working on the T-SPARC SharePoint project. The feedback they supply will enable us to tweak any issues they may have in translating the workflows into a workable SharePoint site before the main stakeholder engagement sessions begin, defining the way the new workflows will be deployed.

One issue we have thought of is that the more complex the diagrams become, the less accessible they become to a general audience (other stakeholders). The last thing we want to do is to alienate any groups involved in the process, and the mapping will inevitably become an intrinsic part of documenting and streamlining the approval and re-approval processes. For this reason there is a possibility that we may look at producing two separate sets of documentation, one very detailed set for CICT, and a more generic set that will be easier to interpret and pass on to other stakeholders.

This process seems to be quite organic at the moment in the way that information on processes is gradually coming to light, things are definitely moving in the right direction.


Programme Design and Approval Workflows

Written by tsparc
March 17th, 2010

The the past week I’ve started working on Programme Design and Approval Workflows, mapping the approval/re-approval processes here at Birmingham City University. One post that I have found particularly interesting so far was posted recently by Claire Eustance, manager of the UG-Flex project at the University of Greenwich. It details several examples of project outputs that may be considered ‘project assets’. One I found particularly relevant to our current phase of work is detailed below.

Members of CIRCLE, go to Claire Eustances post from 15/03/2010 titled: UG-Flex Project Assets January 2010, and select – ‘Validation & Review Process Review Summary’ from the menu on the right hand side of the page.